RE: Comments on Profiles Ontology from the standpoint of ShEx

Hi Tom, Kat, Eric & Andra,

Thanks for the comments below. We appreciate the considered response from the related ShEx group. Some short answers to points you raise and links to GitHub Issues created to address 3 further and potentially make changes to the Ontology doc. We'd welcome your further thoughts within the GitHub Issues as well as any responses to this addressing the text answers here.

Regards,

Nick



> We wonder whether generic properties such as "hasExpression" or "documentedIn" might suffice to cover the simplest use cases for clustering profile-related resources. [as opposed to the hasResource -> ResourceDescriptor -> hasRole]

This idea has come up in lots of discussion and it's one we've not rejects. The reason for the association object pattern we've used of course is that we're more comfortable providing a generic mechanism in the ontology and delegating roles to the ResourceRoles vocab, which can be grown after PROF is finalised. This ontology + vocab pattern's pretty common and, we think, necessary here as we have a very large and diverse set of potential users who may think of many more roles that we can for Resources within a Profile.

One compromise, not ruled out, is to have both: some direct properties for common resource roles linked axiomatically to association pattern constructs and also the vocab to support additional roles. Another is to declare a few (expected to be) common roles in the ontology and then to leave the vocab open-ended for further roles.

This issue is raised for further discussion here: https://github.com/w3c/dxwg/issues/747


> Typically, one reifies a relation when one needs to make extra assertions about the relation itself, but the media type is actually a property of the related artifact, not the relation.

Yes it's a tricky use of `dct:format` that you pick up on too but this has precedence in DCAT with `Distribution` making use of `dct:format` in this way and our `Profile` -> `ResourceDescriptor` mirrors DCAT's `Dataset` -> `Distribution` pattern. So if we were to change, we would need to recommend that DCAT does too and likely they won't as the pattern's in wide use there.


> ...when namespaces simply provide just a handful of their terms to a profile, it seems like a stretch to say that the profile is "profiling" each of the namespaces.

But they are! If you use 3 DC terms in an ontology, you are, to the definitions we have, profiling DC, albeit in a small way we think.

Certainly what is profiling is very hard to work out due to different communities and practices and we have a large amount of effort going into the Guidance document [1] to sort that out. So far in the development of this ontology we have determined that constraining/extending/reusing any part of a standard (or other profile) is profiling. This is because we are aiming for broad applicability of the ontology over specific detailed use (the same motivation for the association pattern discussed above). We want to see wide use of *something* to bring some consistency of description to profile description generally.


> ...one could infer that any profile profiled by another profile is, ipso facto, also a standard...

We've typically, informally, referred to something profiled by a Profile as a base specification which, in relation to the Profile is the role that the thing is playing. This is compatible with the DCT definition of `dct:Standard`: "A basis for comparison; a reference point against which other things can be evaluated.". So that definition's not calling for the Standard to be published by W3C etc. With that softer definition of Standard, our definition of a Profile would work for "a vocabulary I just invented".


> Given the diversity of opinions and perspectives on the distinction in natural language, we would expect diverse interpretations of its use in the Profile Ontology as well.

Indeed, hence our reluctance to do much more than just provide a structured way to relate profiles to things they profile (themselves softly defined) and to parts within the profile (also softly defined and not restricted due to the use of associations for descriptions and extensible roles).


> ...the Profiles Ontology feels less like an ontology and more like an Application Profile, albeit a profile that happens to be about application profiles.

We've struggled with the use of 'ontology' v. 'vocabulary' etc. Would we be better off with Profiles Vocabulary perhaps? 


> A full application profile about profiles might include information about the creator of the profile, its topic, versioning, or its relationship to datasets designed using the profile.

Agreed, and we've been criticised by not making it clear what PROF expects here. To clear this up, we've added examples of PROF in use that indicates how we expect such properties to be used, e.g. the new initial example "A full example described using the Profiles Ontology in RDF (turtle)" (see up-coming edit [3]) includes "# common metadata for the Profile" such as rdfs:label & dct:publisher so it's out expectation that common metadata be used with profiles, likely from DCT, RDFS, likely DCAT and perhaps PROV & PAV too for versioning etc.

So we've tried to restrict PROF to only modelling new concepts like the Standard/Profile relationship, not previously modelled things like titles. We, at least I, disagree strongly with recreating, in a single namespace, all of the properties one might want to use in the total task of profile definition & annotation given the best practice of importing and reusing other ontologies.


> We were unsure what to make of "inheritance", as we are not aware of any generalized notion of inheritance that would make sense across implementation technologies. 

We have only defined things being profiles of other things (isProfileOf) and haven't defined axioms for inheritance due to restrictions this might place on the use of the property (and ontology) when we are going for broad use. We also haven't made isProfileOf a sub property of things such as prov:wasDerivedFrom or other ontology's properties that contain/imply some notion of inheritance, not that wasDerivedFrom gives you too much to work with in this way.

We do have one round-about what of allowing Profiles to directly inherit Resources from things they profile, see the example use of the isInheritedFrom property [4]. We expect to do more work here and on inheritance generally as consideration of the roles (or direct properties) continues and the Guidance document grows.

> It would be helpful to motivate this with a testable use case, e.g., a server implementation which responds to Accept-Profile by calculating the "best" response for processing a Profile Ontology description. 

Do you suggest adding something to this document though there is the Content Negotiation by Profile document [5]? If so, this might be useful. In the Conneg doc, the specification and examples there show that Clients would specify a preference order for profiles that a Server might support for a resource (see e.g. 3 [6]). I think you are suggesting that if a Client asks for a resource according to Profile X and the server doesn't support that but does support Profile Y that Profile X profiles (perhaps transitively) it could return that. Conversely, if a Client asks for a resource according to Standard X and the Server supports Profile Y, a profile of Standard X, it could return that. 

GitHub Issue to introduce such an example to the Ontology doc: https://github.com/w3c/dxwg/issues/748. To satisfy this, we may have to introduce new logic or examples into the Conneg doc also.


> The single most important suggestion we can offer, aside from addressing the issues and ambiguities outlined above, would be to ground this specification in a use case, or use cases, illustrating its concepts.

We've got that in the UCR doc [7], which has now been updated, but clearly we've not indicated that well as this has been raised by others. We've only linked to a few individual Use Cases / Requirements in the Appendix 2: Requirements but not in the main text of the ontology doc or examples or even mentioned the URC doc officially.

GitHub Issue to mention UCR doc in the main ontology doc: https://github.com/w3c/dxwg/issues/749 


[1] https://w3c.github.io/dxwg/profiles/ 
[2] https://www.w3.org/TR/owl-time/ 
[3] https://raw.githack.com/w3c/dxwg/paper-reviews/profilesont/index.html#example-1-a-full-example-described-using-the-profiles-ontology-in-rdf-turtle 
[4] https://raw.githack.com/w3c/dxwg/paper-reviews/profilesont/index.html#example-2-property-isinheritedfrom-in-use 
[5] https://www.w3.org/TR/dx-prof-conneg/ 
[6] https://w3c.github.io/dxwg/conneg-by-ap/#example-3-requesting-a-representation-conforming-to-a-specific-profile-using-http-headers 
[7] https://w3c.github.io/dxwg/ucr/ 






-----Original Message-----
From: Thomas Baker <tom@tombaker.org> 
Sent: Friday, 8 February 2019 2:56 AM
To: public-dxwg-comments <public-dxwg-comments@w3.org>
Cc: Kat Thornton <katherine.thornton@yale.edu>; Eric Prudhommeaux <eric@w3.org>; Andra Waagmeester <andra@micelio.be>
Subject: Comments on Profiles Ontology from the standpoint of ShEx

As requested, we have reviewed the Profiles Ontology, first public working draft of 18 December 2018 [1], from the standpoint of Shapes Expression Language (ShEx).

A ShEx Schema describes the "shape" of known (or potential) RDF data in terms of validatable constraints on things such as type of resources described, properties used, and values.  A ShEx Schema is related to a given RDF dataset by means of a ShEx shape map. 

We understand the Application Profile to be a construct that typically draws properties and classes from multiple namespaces (themselves defined outside of the profile) to express the "shape" of data in a more general sense, possibly even just in natural language.  In this sense, a ShEx Schema can be seen as one (or potentially, in some cases, the only) expression of an Application Profile.

ShEx schemas (and shape maps) might be in the cluster of resources around a given application profile that the Profiles Ontology is intended to describe, along with natural-language descriptions embodied in PDF or HTML documents, user guides, code repositories, and other expressions of constraints. All of these are "resource descriptors", the functional roles of which are broadly characterized in the Resource Roles Vocabulary [2]. 

We see the utility of having well-known properties for relating the cluster of resources around a profile.  However, a ShEx schema, or "ShEx application profile" if you will, already relates the terms used in its constraint expressions to their underlying namespaces (in Profiles Ontology terms, "standards"); a ShEx shape map already relates a ShEx schema to a specific RDF dataset; and a ShEx validation result includes the shape map on which it was based, the RDF representation of which is defined in [4].

Application profiles, as described here, consist of a ShEx schema in addition to the JSON-LD @context that will define the result shape map.

While it could be useful to have properties to relate these ShEx artifacts to other types of artifact around a profile, we see that these relations are modeled in Profiles Ontology with `hasResource` pointing to a resource descriptor, which in turn has a role (`hasRole`) named by a SKOS concept (in a construct that resembles an RDF type declaration).  Modeling these as properties would more straightforwardly support scenarios in which a given profile-related resource were related to more than one other profile-related resource, but with different roles.  It is on the other hand not clear to us what would be lost by modeling relationships directly with properties. Typically, one reifies a relation when one needs to make extra assertions about the relation itself, but the media type is actually a property of the related artifact, not the relation. We wonder whether generic properties such as "hasExpression" or "documentedIn" might suffice to cover the simplest use cases for clustering profile-related resources.

It is also unclear to us whether it is helpful to describe the relation of a profile to its underlying namespaces in terms of a relation of Profile to Standard.  The standard-to-profile relation is characterized as one of general-to-specific, but when namespaces simply provide just a handful of their terms to a profile, it seems like a stretch to say that the profile is "profiling" each of the namespaces.

The relation of standard to profile also seems unclear in practice.  Some people consider a specification to be a "standard" when published by a "standards" body such as ISO but not if published by, say, W3C or DCMI.  And yet, because the domain of `prof:hasProfile` is `dct:Standard`, one could infer that any profile profiled by another profile is, ipso facto, also a standard.  Should a vocabulary I just invented for this profile be considered a "standard" with respect to the profile?  Given the diversity of opinions and perspectives on the distinction in natural language, we would expect diverse interpretations of its use in the Profile Ontology as well.

While it may become more common, it is currently unusual to call a collection of terms from multiple ontologies an ontology. (This has been the traditional use of "application profile".) All of the resources listed on a W3C wiki page as "good ontologies" are based on just one namespace [3], while all of the application profiles that come to mind, DCAT included, draw on multiple namespaces.  While we do not think it would be useful to try to pin down this distinction with precision, the Profiles Ontology feels less like an ontology and more like a Application Profile, albeit a profile that happens to be about application profiles.  A full application profile about profiles might include information about the creator of the profile, its topic, versioning, or its relationship to datasets designed using the profile.

We were unsure what to make of "inheritance", as we are not aware of any generalized notion of inheritance that would make sense across implementation technologies. It would be helpful to motivate this with a testable use case, e.g., a server implementation which responds to Accept-Profile by calculating the "best" response for processing a Profile Ontology description. A test of inheritance would include the notion that inheriting imposes further constraints, and that the entity being inherited from may in turn inherit from something else. ShEx shape inheritance has this behavior.

The single most important suggestion we can offer, aside from addressing the issues and ambiguities outlined above, would be to ground this specification in a use case, or use cases, illustrating its concepts.

Tom Baker
Kat Thornton
Eric Prud'hommeaux
Andra Waagmeester

-- 
Tom Baker <tom@tombaker.org>

Received on Sunday, 10 February 2019 13:05:05 UTC