Re: Fwd: Profiles Ontology review by SHACL CG

Dear Irene,

Quite some time ago (January) you provided a series of comments on the profiling work being undertaken in the W3C’s Dataset Exchange Working Group, largely the Profiles Vocabulary, with your email to the public mailing list here:

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

We broke your comments down into a series of GitHub Issues to track work in addressing them:

1. https://github.com/w3c/dxwg/issues/659 - Better description of application profiles, profiles in general and how they may be used
2. https://github.com/w3c/dxwg/issues/660 - Clarify use of dct:conformsTo perhaps with additional properties
3. https://github.com/w3c/dxwg/issues/661 - Simplify ontology by remove inverse and transitive properties
4. https://github.com/w3c/dxwg/issues/799 - From SHACL: profile and "base ontology"
5. https://github.com/w3c/dxwg/issues/800 - From SHACL: profiles based on same ontology

The Issues have long lists of comments in them but I’ll summarise their current state here. These summaries have also been placed into the issues.

For 1.:

Regarding definitions: Since your request for better descriptions of application profiles, profiles in general and how they may be used, we have updated both the definitions used in the profile documents and now the Profiles Vocabulary and the Content Negotiation by Profile document specifically define  profiles, application profiles, specifications and so on, see Section 3. In these Editor’s Drafts:

• https://w3c.github.io/dxwg/conneg-by-ap/#definitions – Content Negotiation by Profile
• https://raw.githack.com/w3c/dxwg/prof-3PWD-candidate/prof/#definitions – The Profiles Vocabulary

Regarding “how their descriptions may be used in practice”: in both of the documents linked to above, we have provided multiple examples of either the vocabulary or content negotiation Internet requests.


For 2.:

Q: “I found the use of dct:conformsTo in the example somewhat confusing. It seems to say that a resource with the role role:ConformanceTest conforms to SHACL.”

A: Within the Conceptual Model (https://raw.githack.com/w3c/dxwg/prof-3PWD-candidate/prof/index.html#conceptualmodel) it now states: “Resource Descriptors must indicate the role they play (to guide, to validate etc.), the formalism they adhere to (dct:format) and any dct:Standard that they themselves conform to (dct:conformsTo).” 

Additionally: "Any rdfs:Resource MAY indicate conformance to a profile as per Example 2 by using dct:conformsTo. Individual communities MAY determine what constitutes an appropriate URI to identify a profile."

So dct:conformsTo, within the Profiles Vocabulary, is always used to indicate a resource's conformance to a dct:Standard or a prof:Profile. Within the Profile Vocabulary's own classes it is suggested for use only once, with the ResourceDescriptor class, but it is expected to be used for instance data (i.e. "outside" the Profiles Vocabulary) referring to profiles/standards characterised by the vocabulary.

A SHACL Resource that is part of a profile should indicate its conformance to SHACL by use of dct:conformsTo and it is likely that such a resource could play the role of either Constraints or Validation, as per the initial Roles vocabulary in the document in Section 9 (https://raw.githack.com/w3c/dxwg/prof-3PWD-candidate/prof/#resource-roles-vocab). See the "Initial Example" in the document (https://raw.githack.com/w3c/dxwg/prof-3PWD-candidate/prof/#eg-initial-example) for this exact scenario. Note that the Role you referenced, ConformanceTest has been replaced with the Validation role, as used in the "Initial Example".


For 3.:
Q: I also wondered why for one object property (prof:isProfileOf), inverse and transitive properties were specified, but not for others.
A: We have removed the inverse property you mentioned. There are now no inverse properties in the Vocabulary.

Q: Personally, I would prefer to see no inverses and no properties intend to hold transitive inferences since the goal here is to improve interoperability.
A: We previously stated that we have motivating use cases for a transitive property, prof:isTransitiveProfileOf, so it remains, however the discussion about it continues. Currently, next to the property in question (https://raw.githack.com/w3c/dxwg/prof-3PWD-candidate/prof/index.html#Property:isTransitiveProfileOf), we have placed a rational for including it based on SKOS' use of similar properties and illustrated potential use with an example (Example 3: https://raw.githack.com/w3c/dxwg/prof-3PWD-candidate/prof/index.html#eg-isTransitiveProfileOf).


For 4.:
Q: Presumably, a profile should not contradict the “base ontology” - it could only further constrain it.
A: Indeed and this is what our definition of profile is, "A specification that constrains, extends, combines, or provides guidance or explanation about the usage of other specifications.". Anything that conforms to the profile must conform to the thing that it profiles. 

Our group has extended your question with these points:
a.: Is there any thought of testing whether a profile is a valid profile? Meaning that it does not contradict the base.
b. How would this be accomplished? 

Answers:
For a.: Testing the profile itself - any schemas it declares for instance - is possible in a system-specific way (e.g. using inference on an ontology) but more useful and easy is to test to see if instance data created conforming to the profile conforms to the base. This could be done by applying any of the base's validators to instance data. If the base is described using the Profiles Vocabulary, finding its validating resources would be straightforward.
For b.: One of the purposes of creating PROF with semantics that allow for the creation of profile hierarchies (isProfileOf) and ways of indicating resources within those profiles that serve certain purposes (hasRole + ResourceRole vocabulary) so that mechanics (code) can be written to do such testing against a profile and all the things it profiles.

Discussion of some related issues continues in Issue https://github.com/w3c/dxwg/issues/698 - Indicate a conventional way to automatically validate data instances of application profiles.

For 5.: 
Q: If two communities use two different profiles of the same base ontology, in order to understand how their data could interoperate, it would be important to be able to assess differences between these profiles. The examples above are all quite common, while at the same time very simple. One could easily list more complex examples. Is the goal of the working group is to provide means for addressing these issues?

A: This sort of mechanics are though by the group to be out-of-scope for the Profiles Vocabulary as they would likely need to be community-specific to be implementable. Having said that, since the Vocabulary presents a set of Roles that can be extended, a community could extend that role list to suit their needs. They could implement a profiles-differences or a differences-form-base resource. A further though: communities could define profiles of the base that the profiles they wish to compare conform to. In this new profile that is intermediate between the base and the ones they are comparing, they could list all the elements that the profiles being compared have in common. This would narrow the task of interpreting their differences.


So, to summarise the responses:

1. we believe is answered in full, 2. also, with specific normative text, 3. Is partly answered as requested (inverse property removal) but partly not (transitive property stays, with motivating examples), 4. Is answered with explanations of potential use but related discussion is happening in another Issue and for 5. The question is rules largely out-of-scope although Profile Vocabulary mechanics may assist as noted.


Please could you respond with any further comments either following up points here or new comments on the profiles documents since they are now greatly updated since you last saw them. If you could even follow up with a small comment in the case that you are happy with these results, that would be greatly appreciated as we would like to indicate responses to issues were received by Issue proponents.

Thanks very much,

Nicholas Car & Rob Atkinson
Editors of the Profiles Vocabulary
On behalf of the Dataset Exchange Working Group

Received on Tuesday, 3 September 2019 14:50:14 UTC