Fwd: Profiles Ontology review by SHACL CG

Forwarding the original response as requested to the DX working group e-mail list.

I have a couple more questions about profiles. From reading the Profile Guidance document, I understood a profile to be a specification of how a community may use one or more ontology. 

For example, FOAF has two properties that may be used to capture a person’s first name (foaf:fistName and foaf:givenName). One community may decide that they will use FOAF and they will always use foaf:firstName only. A similar decision may be taken with respect of the use of SKOS e.g., always require consistently use of skos:broader and not some combination of skos:narrower and broader - to make it, for example, easier for an application to display a taxonomy tree. A profile could further constrain the “base ontology”. For example, to require that each foaf:Person must have at least on first name. Or to say that the range of values for a property must be a string while the base ontology does not restrict the values or says it must be a literal.

Is this a correct understanding? Would this be a metadata profile? What are the application profiles and metadata application profiles? How do they differ?

Presumably, a profile should not contradict the “base ontology” - it could only further constrain it. 

Is this correct? If so, is there any thought of testing whether a profile is a valid profile? Meaning that it does not contradict the base. How would this be accomplished? If profiles we expressed in SHACL and the base ontology was also expressed in SHACL, one could think of ways SHACL could be used to check for validity of a profile. 

Another related thought is about understanding compatibility or even simply differences between different profiles used by different communities. The latter is most likely the main issue with respect to interoperability. 

For example, a profile that mandates the use of fistName and prohibits the use of givenName would be incompatible with a profile that made an opposite decision. This incompatibility could be handled through translation without data loss. Other profiles could be such that even translation could not make them compatible period or not make them compatible without some data loss. For example, one profile may require a single first name and another allows multiple. Or one profile requires a first name and another does not.

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?

Section 3.3 of the document says:

"A profile may be (partially) "implemented" by "schemas" (in OWL, SHACL, XML Schema...) that allow different levels of data validation"

Further, section 4.4 says:

"A profile should have human-readable documentation that expresses for humans the main components of a profile, which can also be available as machine-readable resources (ontology or schema files, SHACL files, etc). This includes listing of elements in the profile, instructions and recommendations on how to use them, constraints that determine what data is valid according to the profile, etc."

What is the difference between 3.3 and 4.4? Do they say the same thing or is there some difference?

What does “partially” mean? What part of a profile could be implemented by schemas and what part could not be implemented by schemas? 

If a profile is implemented by a schema, then what is a difference between the profile implemented as a schema and a resource that plays the role of prof:ConformanceTest? Would this be one and the same?

Regards,

Irene



> Begin forwarded message:
> 
> From: Irene Polikoff <irene@topquadrant.com>
> Subject: Re: Profiles Ontology review by SHACL CG
> Date: January 13, 2019 at 10:40:29 AM EST
> To: "Car, Nicholas (L&W, Dutton Park)" <Nicholas.Car@csiro.au>
> Cc: "public-shacl@w3.org" <public-shacl@w3.org>, Rob Atkinson <rob@metalinkage.com.au>
> 
> Nicholas,
> 
> Personally, I found it hard to provide a meaningful review or answer questions about benefits without understanding what are the application profiles and profiles in general and how their descriptions may be used in practice.
> 
> I looked at https://w3c.github.io/dxwg/profiles/ <https://w3c.github.io/dxwg/profiles/>, but I did not feel it was sufficiently mature to give me the clarity needed to inform the review.
> 
> The examples in the ontology itself are simple statements, identifying a profile and saying that some guidance documents and a conformance test exist. As a human readable information, it is fine. However, the intention, I believe, is more than simply provide reference links to people looking for some artifacts. Is it correct? If so, then I believe more information (as per above) is needed in order to provide feedback.
> 
> If I am to focus only on the human readability, 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. Is this correct? Or is the intention to say that the test is implemented in SHACL to test the conformance of something else (what is that something else? Some dataset?) to this profile. Of course, if a test is implemented in SHACL, then the test should be expected to conform to SHACL specification. However, for me, there was some cognitive overloading or dissonance here in the use of the term ‘conform’. I would prefer to see some other property.
> 
> I also wondered why for one object property (prof:isProfileOf), inverse and transitive properties were specified, but not for others. 
> 
> Personally, I would prefer to see no inverses and no properties intended to materialize transitive inferences since the goal here is to improve interoperability.  If some users will publish information using the inverses, then applications using this information will need to work harder to support the inferencing. This will introduce some obstacles to adoption. Which may be OK if there is some important value to be derived from this, but the value was not clear to me. And if there is an important value, is it limited to just this specific property? Why not inverse for prof:hasRole, for example? Or transitive alternatives for other properties such as prof:isInheritedFrom?
> 
> Regards,
> 
> Irene Polikoff
> 
> On Jan 13, 2019, at 5:44 AM, Car, Nicholas (L&W, Dutton Park) <Nicholas.Car@csiro.au <mailto:Nicholas.Car@csiro.au>> wrote:
> 
>> Dear SHACL Community Group,
>> 
>> The W3C's Dataset eXchange Working Group (DXWG) [1] has published a First Public Working Draft of The Profiles Ontology [2]. The Profiles Ontology is an RDF vocabulary to describe profiles of (one or more) standards for information resources. We believe that this ontology and the profiling work of the DXWG should be of great interest to SHACL CG members generally as profiles and constraints are closely linked.
>> 
>> The DXWG is chartered to provide a guidance document on publishing application profiles of vocabularies and a recommendation for content negotiation by application profile which it is doing. This ontology was not an anticipated output of the DXWG but has been created to allow for formal semantic descriptions of the components of profiles and for relations between profiles and standards. A more complete description of the ontology is given below.
>> 
>> We would greatly appreciate your feedback on this ontology and particularly your group, again, due to constraint/profile interplay. In reviewing the draft, it might be helpful for you to keep in mind the "Use Cases and Requirements" document that we are working to [3]. We would find it most helpful to get feedback on the following lines:
>> 
>> Do you agree with the direction of travel of this ontology?
>> Are there any areas where we could improve what we have done? [please illustrate]
>> Are there any areas where you think the proposal/modelling is wrong or could lead us into describing profiles that are unhelpful? [please give examples and reasons]
>> Are there other use cases for formal profile descriptions that we have not considered? [please illustrate]
>> Also:
>> How do you see constraint languages like SHACL benefiting or not from profile definitions created using the Profiles Ontology?
>> How will profile definitions like this help or hinder people in using SHACL v. ShEx?
>> Please also feel free to make any other comments and suggestions regarding the draft. Note that positive comments or general assent to the work's design are very welcome, as these provide evidence of community acceptance. We would like to receive comments on this draft by January 31, 2019, so that those can inform our next working draft.
>> 
>> Please send comments through GitHub issues (https://github.com/w3c/dxwg/issues <https://github.com/w3c/dxwg/issues> - tag 'profile-description') or through email at public-dxwg-comments@w3.org <mailto:public-dxwg-comments@w3.org>.
>> 
>> Thank you,
>> 
>> Nicholas (on behalf of the W3C DXWG)
>> 
>> [1] https://www.w3.org/2017/dxwg/charter <https://www.w3.org/2017/dxwg/charter>
>> [2] https://www.w3.org/TR/2018/WD-dx-prof-20181218/ <https://www.w3.org/TR/2018/WD-dx-prof-20181218/> although ED latest might be more useful: https://w3c.github.io/dxwg/profilesont/ <https://w3c.github.io/dxwg/profilesont/> 
>> [3] https://www.w3.org/TR/dcat-ucr/ <https://www.w3.org/TR/dcat-ucr/>
>> The Profiles Ontology - description
>> 
>> The Profiles Ontology (PROF) is a small RDF vocabulary to describe profiles of (one or more) data specifications, i.e., a named set of constraints over those specifications. It provides the general pattern of narrowing the scope of a specification with additional, but consistent, constraints. It is particularly relevant to data exchange situations where conformance to profiles is expected and carries additional context. PROF enables profile descriptions to specify the role of resources related to data exchange such as schemas, ontologies, rules about use of controlled vocabularies, validation tools, and guidelines. PROF may, however, be used to describe the role of resources in any situation where constraints are made on the usage of more general specifications, as well as the relationships between profiles.
>> 
>>  
>>  
>> Nicholas Car
>> Senior Experimental Scientist
>> CSIRO Land & Water
>> 41 Boggo Road, Dutton Park, QLD 4102, Australia
>> E nicholas.car@csiro.au <mailto:nicholas.car@csiro.au> M 0477 560 177 P 07 3833 5632