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 Thursday, 7 February 2019 16:56:52 UTC