Scope of Profiles Spec

[nicholascar]

This issue is to discuss the scope of the SHACL 1.1 Profiles Deliverable.

[nicholascar]

In framing communication to Scott H I wrote this week:

There is previous W3C profiling work which may be used to frame this work: The Profiles Vocabulary - https://www.w3.org/TR/dx-prof/

That work struggled with definitions of profiles but established two things that I think we should bear in mind for this work:

1. The property chain axiom dct:conformsTo owl:propertyChainAxiom ( prof:isProfileOf dct:conformsTo )
   • so A prof:isProfileOf B and data conforms to A, it must also conform to B

Profiling doesn't have to be like this, but it sure makes the who thing easier! So I'd rather not break that if possible.

2. A known set of profile resource roles

Profiles, in general, may have specifications, validators, all sorts of parts. If we maintain a list of well described roles that parts can play, we can do things like indicate which part may be used for certain tasks.

In this WG, we will have a narrower mechanic of profiling since we are only dealing with SHACL - no written specifications, OWL or other schema etc. - so I think we can solve an issue that had no solution in The Profiles Vocabulary: what do I claim conformance to, exactly?

If I have data D and I say D dcterms:confromsTo X, what is X? We assume it will be an IRI of "the profile" (or a standard) but looking at well-known standards like SKOS, The Profile Vocabulary work never established if X should be the SKOS namespace, the URL of the Spec (normative), the IRI of a SKOS SHACL validator...

If only dealing with SHACL, we can say D dcterms:confromsTo X where X is some package of SHACL, so we can define how to present packages (we may need a new class for is as people currently just use Ontology which may not cut it) and the whole world is easy. If X is a validator for a broader profile that includes written documents, vocabularies etc., defining how to use those other parts is not this Spec's problem, although we may follow point 2. above and assume that all SHACL within a broader profile fulfils a certain set of defined roles. This spec just needs to show how to package SHACL, how one package can profile another and, following the other notion of profiling: indicate how SHACL packages prifiling SHACL is the same/different to SHACL being used to define profiles of graphs, which it already does of course.

A spinoff from this work might be to help the Content Negotiation By Profile W3C/IETF work proposed specification. That spec defines mechanisms to indicate how the payload of a (web) service may be inidcated as conforming to a standard (or profile). If we formalise how packages of SHACL define profiles of graphs, then we can use the IRIs of those packages in ConnegP headers to indicate the shape of content will be delivered, if that content is in an RDF format.

[nicholascar]

@HolgerKnublauch suggests we can define SHACL profiles like a "SHACL 1.0" that doesn't include new features in SHACL 1.1+.

I do suggest that defined profiles of SHACL could be part of this deliverable: a defined set of profiles and, ideally, a dynamic register of them that can be added too though I note the W3C is not good at (hasn't much demonstrated) managing dynamic registers

[ajnelson-nist]

@nicholascar , a nit for this issue - the deliverable seems like it should be titled the "SHACL 1.2 Profiles" Deliverable, per history notes on #224 .

[nicholascar]

Closing in favour of Issue #546 & #547