Dxwg: Definitions in Profiles Ontology

[makxdekkers]

Definitions that need improving:

• prof:hasProfile: "_A dct:Standard (or a Profile or Base Specification) has a Profile_"
• prof:isProfileOf: "_A Profile is a profile of a dct:Standard (or a Base Specification or another Profile)_"
• prof:hasRole: "_Functional role of a Resource_"
• prof:isInheritedFrom: "_A Profile's Resource Descriptor has been inherited from a Base Specification_"
• and several more.

[kcoyle]

+1 to this, and thanks, @makxdekkers . And more:

prof:hasResource: "A Profile has a Resource Descriptor"
-- The described profile resource
prof:isProfileOf: "The subject of 'is profile of' defines constraints on the object which playes the role of a base specification"
-- A vocabulary or profile that this profile is based on
prof:hasToken: "A property for identifying this Profile for use in APIs"
-- An identifying short name for the profile
prof:hasArtifact: "An rdfs:Resource that implements the Resource Descriptor"
-- The physical resource that is a member of the profile set of resources

etc. We really need to go through both the vocabulary and the set of roles to look at all of the definitions.

[nicholascar]

Discussion of these definitions is now taking place within a Google Doc [1] (read only), edit permissions for which have been sent to main participants here. If anyone else would like edit access, please email @nicholascar

[1] https://docs.google.com/document/d/1q8OTx2FxIapCCuNPIDnGYl_kzvJBLT2eAn4Zp6JHrUI/edit?usp=sharing

[kcoyle]

From Leslie Sikos:

Relationship with standard and de facto standard vocabularies and ontologies, such as Dublin Core, PROV-O, and SKOS, should be defined (more) clearly in the specification and formally in the ontology file itself. For example, the range of :isTransitiveProfileOf is defined to be dct:Standard—much more similar definitions would be needed.

https://lists.w3.org/Archives/Public/public-dxwg-comments/2019Jan/0020.html

[rob-metalinkage]

Not sure I would agree - making Profile a subclass os dct:Standard means its substituable as the range of any dct:conformsTo predicate. I dont think any other axioms are actually required. The relationship to other vocabularies is otherwise simply OWA - we dont redefine anything that exists, and we dont need to specify what else may be useful.

[nicholascar]

@kcoyle: this Issue is about textual definitions and the Google Doc was set up to address this. The comment from Leslie Sikos is off topic here as we have other issues dealing with relations to other ontologies such as Issue https://github.com/w3c/dxwg/issues/485 and also we are considering stronger links to DCAT now but not SKOS etc. Mappings from PROF to SKOS, PROV-O etc. are contained in a series of additional mapping files and the section on mappings in the document needs completion.

[kcoyle]

"making Profile a subclass os dct:Standard means its substituable as the range of any dct:conformsTo predicate." - dct:conformsTo was intended to describe conformance to standards, not conformance to anything. Profile should not be declared a subclass of dct:Standard because one wants to use dct:conformsTo - it should only be declared a subclass of dct:Standard if it meets the definition of a standard. I agree with the statement by @agreiner in #792 that not all creators will consider all of their profiles to be standards, and defining profile this way narrows the usability of PROF. It is better to use a minimum semantic commitment and allow users of the vocabulary to add type declaration where they wish.

[kcoyle]

"this Issue is about textual definitions and the Google Doc was set up to address this." I agree that the Google doc was set up to address this, but as we struggle with definitions (e.g. #802) it becomes clear that we first have to understand the meaning, and the meaning of some terms is not clear. Once we understand the meaning we can do wordsmithing.

[makxdekkers]

@kcoyle I don't think that instances of dct:Standard are necessarily formal standards, like W3C Recommendations or ISO Standards. The definition also allows informal sets of rules. You refer to "_the definition of a standard_" but it is not clear whether we all have the same idea of what a 'standard' is. Given the definition at DCMI, I don't see how a profile would not qualify as a dct:Standard.

[kcoyle]

Makx, I realize that dct:Standard does not require formal standards - in fact, the usage board rejected that definition when it was suggested by ISO. But not everyone considers their profile a standard. There can be ad hoc profiles that aren't expected to have any weight on future activity. The main thing is that there is no reason to define profiles as standards (even under a loose dct definition). As we have found with some of the domains and ranges in dct, it's easy to exclude someone else's practice. As always, less is more when it comes to these kinds of restrictions.

[kcoyle]

Re: dct:conformsTo

I think it would be best to reserve dct:conformsTo to conformance to things that are considered standards. These could be profiles, but in general I'm assuming that the point of conformsTo is to alert folks to standards conformance like various ISO standards, community standards like MARC21 or Resource Description and Access (the "other RDA"), etc. It looks to me like the way to say that a profile conforms to another profile is already in the vocabulary as "profileOf". If either is to be of use in machine processing it would be best not to overlap them. That doesn't mean that a profile could not be considered a standard, but if conformsTo will be used expressly to link to profiles then there is likely to be confusion (not to mention redundancy) between conformsTo and profileOf.

conformsTo - a standard
profileOf - a specification or profile

[rob-metalinkage]

mixing up concerns here. Profiles do not conform to other profiles, they specialise (constrain) them in a compatible fashion. We need to keep the concept of a resource and what it conforms to separate.

conformsTo is a relation indicating an arbitrary resource conforms to a standard, (which may be a profile of anther standard)
profileOf is a relation saying that one standard relates to another.

... noting we are still fully compliant with the DC view - there is no formal definition of "considered" to worry about - this is up to the implementers to choose whatever governance regime they want and what specifications they choose to accept as conformance requirements.

There is no change to the model indicated - so please just go back to the issue of getting the definitions as good as we can to minimise red herrings.

[nicholascar]

As a matter of Issue management, I say again that this Issue is about textual definitions and other topics, such as use of dct:Standard are perhaps interesting but off topic so please raise other Issues for them.

I find it very hard to progress the document v. specific Issues if they morph and impossible to close Issues and therefore no progress can be seen to be made.

I'd like to close this Issue when the title topic of textual definitions are dealt with by merging in the word from the Google Doc. If other things come along that require textual definition rethinking, like discussions about dct:conformsTo etc., fine create another Issue!

[kcoyle]

"Profiles do not conform to other profiles, they specialise (constrain) them in a compatible fashion. We need to keep the concept of a resource and what it conforms to separate."

First, we need group agreement on that. But I also think that "profileOf" is not going to mean "constraints" to most potential users of the vocabulary. If it is specific to constraints then it might be best to have that in the property name. Even "prof:constrains".

Nick, if there isn't agreement on what the properties mean you can't hardly have agreement on how they should be worded. The fact that there isn't agreement on the meaning should be a big red flag in terms of publishing the vocabulary. There has to be group consensus on these meanings, and also on the functionality that we expect the vocabulary to support. It looks like we aren't there.

[makxdekkers]

I agree with @kcoyle that if A prof:profileOf B is to convey that A defines constraints on B, it would be clearer to call it prof:constrains.

[nicholascar]

This issue has been superseded by WG discussion with new definitions entered into the 3PWD candidate. We'll take new Issues created about definitions in the document from here onwards.

[aisaac]

@nicholascar I agree that the issue should be closed, in the light of what happened in the past months. But I think that formally it makes sense (in order to close the issue) to let @makxdekkers look at the new definitions, so that he can agree with the approach and start raising new issues on the new definitions, if he thinks this should happen.

[makxdekkers]

Can someone provide a link to the 3PWD candidate please?

[rob-metalinkage]

a 3PWD candidate has not been released.

[aisaac]

I think that for the sake of demonstrating that the definitions have changed a pointer to an editor's draft may be good enough. This is about group discussions, not PWD ones...

[kcoyle]

@makxdekkers The roles are in the 2pwd. The discussion about the roles was in a Google Doc. Those in the discussion were Nick, Rob, Makx, me and @andrea-perego. We have not gone back and reviewed the roles that are in the 2pwd, so that should be a task on our list.

[kcoyle]

@aisaac We do need to review the definitions, and the issue as opened by @makxdekkers was about the content of the definitions, not about group discussions (if I understand your meaning). There was another issue (#536) for getting the definitions into the 2pwd (not looking at the content of the definitions) and that has been closed.

[aisaac]

@kcoyle I agree we need to review definitions, it's just that this issue is about specific wordings that @makxdekkers and you have reviewed a long time ago, and I think that using the same issue to review newer definitions (while it still features old definitions at the top) would be quite cumbersome for us. If the definitions have changed since @makxdekkers have opened the issue, then if Makx (and you!) agree the changes are substantial, we can close the issue and open a new one to discuss the new definitions!

[rob-metalinkage]

This issue is a general one - and definitions for classes have been extensively review against the general concerns which were taken on board.

Agreed that we need to look at the roles in particular and that we should always be open to improving defintions, and we have the luxury of being able to look at object naming too as there is no large installed base and planned implementers are on board to update. (I'm holding off pushing implementations to public resources describing all the OGC profiles waiting on just this)

At this stage we need to close this issue and open new ones for the 3PWD and 4PWD around specific definitions so some consensus can be arrived at clearly for each case. New issues should be opened when a constructive proposal is advanced for consideration of a single definition or a set of interrelated definitions. We also need to improve discipline to keep those issues focussed - which means spitting off new issues if we want to have more general discussions about what various real world practices might mean against the model as a whole.

I also suggest attempting to get the guidance document section on conformance written to improve general understanding of the separation of "logical profiles" (aka "non-information resources") and expressions of part of these ("information resources) - in either text that combines multiple specifications and multiple files using different technologies to support formalism and implementation. If consensus on that wording can be reached then we can probably update the roles vocabulary very quickly to reflect it, and we will have ready-made guidance for this rather complex issue.

[kcoyle]

@aisaac Did you look at the Google doc? There is considerable difference between the Google doc discussion and the 2PWD, and I, for one, (and I believe it is the same for Makx) never signed off on the roles in the 2pwd as being representative of the G-Doc discussion. So I don't know where to take this back up. We could do an issue for each role, but we would still need an issue for the general approach to roles: Which should be included? How much detail should be represented? We could start anew with what's in the 2pwd but it would be quite a loss to not bring along the discussion that took place before and that never achieved consensus.

[rob-metalinkage]

Its also obvious that the google doc didnt get to, or derive from, a common understanding of the separation of documents from conformance requirements. So lets attack it from the guidance perspective first, then we can make sure that we have the roles and matching descriptions needed to support the suggestions on how to describe profiles with different types of artefacts. The Profiles ontology isnt going to dictate all possible roles and artefact types or usage - only provide a place where they can be discovered.

[aisaac]

@kcoyle, all I confess I've not. The discussion continued in this issue after it continued in the Google Doc, so I just didn't know what would be the reference for closing the issue - the Google Doc or the comments in the issue. In any case the definitions that open this issue are outdated now. It seems a good idea to keep the Google doc as reference for future discussion and check of other WDs. But then we should either freeze the Google Doc or have discussions in issues, not both. Especially if we want to have issues that are standing.

And if we want to keep the Google Doc alive then the participants should try to resolve the threads in there: there are many threads that are open with a last comment (either from Karen, Makx or Rob) as if staekholders agreed they would stop answering each others' point. But that was before we put PROF on hold I believe, wasn't it?

[kcoyle]

@aisaac First, I apologize but I pointed to the wrong Google Doc - that one was about definitions for PROF properties and is much more extensive than the one for roles, which is here.

(No, that was the right document; the other one I erroneously posted here was for roles. That discussions is at #535, and has the same issue of resolving differences.)

Both Google Docs stopped being used when the 2pwd was issued without the questions raised there were resolved, as you can see in the document itself, which shows no conclusions. The roles and definitions included in the document do not reflect the discussion in the Google Doc (since the discussion there had obviously not reached a level of agreement). This is why I have been insisting that the definitions question is not resolved because I see this as not following the necessary consensus process - the editors made decisions without getting consensus from the discussants. In my mind that renders the editors' decision moot. So we still need to resolve this question of definitions.

If I voted to allow the 2pwd to be published, I now regret this, because this fact itself should have resulted in a "no" vote due to lack of resolution by consensus. This is one of the substantial areas that must be resolved before any further publication. I do not want others to assume that the definitions as written are the result of consensus.

[kcoyle]

Here's an example of the discussion about definitions (G-Doc):

hasToken:
Definition
Current: A property for identifying this Profile for use in APIs

Karen (Issue 755): An identifying short name for the profile
Andrea (Issue 453 (comment)): The preferred token for identifying a Profile, alternatively to its URI
Makx An alternative identifier for the Profile
Heidi (Issue 723): requesting removal of circularity

Proposed:
A preferred alternative identifier for the Profile

(plus assorted G-Doc comments)

It is not clear in the Google doc who wrote the "proposed" so I can't see how that got there, but that is what was entered into the PWD. I'd have to dig through the G-Doc history but I'm pretty sure that there was no notice to commenters between the writing of the "proposed" versions and the update to the WD, and my recollection is that the time between them was a matter of days. It's pretty clear that this wasn't the wording that anyone in the discussion actually proposed. I discovered the changes somewhat by accident because I returned to the G-Doc to see how things were going - and found that decisions had been made.

Throughout the G-Doc there are comments and questions and generally few closed agreements. There are no +1's on the "proposed" texts. So it is very hard to consider them legitimate. And this is a simple example - the others are often more complex with lots of side comments. (Getting it all into github issues would be a lot of work, so I'm hoping we can figure out a less heavy way to work on this.)

Obviously, having clear definitions is a #1 task for any standards document, so this isn't a trivial issue.

[nicholascar]

This Issue is now duplicated by #1061 however conversation is happening over there so I'm closing this issue in favour of that on.