RE: Use of SHACL for profiles

Note that adding dct:conformsTo to dcat:Distribution is the topic of this PR not yet merged:

https://github.com/w3c/dxwg/pull/297


From: Rob Atkinson [mailto:rob@metalinkage.com.au]
Sent: Wednesday, 18 July, 2018 07:09
To: Svensson, Lars <L.Svensson@dnb.de>
Cc: Rob Atkinson <rob@metalinkage.com.au>; kcoyle@kcoyle.net; public-dxwg-wg@w3.org
Subject: Re: Use of SHACL for profiles

@Lars - by "dcat Contex"  I mean that that for a dcat:Distribution the target of dct:conformsTo may be a profile (supported automatically by profileDesc since a profile is a subclass of  dct:Standard).  They trick is whether the value of this predicate must specify the narrowest profile, or if it should be multi-valued - and what parent more general profiles it can also reference? And if multi-valued - how does a client choose the narrowest?  We need to work through possibilities. - maybe need a subproperty of dct:conformsTo like dct:alsoConformsTo  ...

On Wed, 18 Jul 2018 at 05:34 Svensson, Lars <L.Svensson@dnb.de<mailto:L.Svensson@dnb.de>> wrote:
On Tuesday, July 10, 2018 6:54 AM, Rob Atkinson [mailto:rob@metalinkage.com.au<mailto:rob@metalinkage.com.au>] wrote:

> 1) yes,  and our charter covers the "publication of a profile" including various parts,
> including guidance, validation, form building, axiomitisation and any other components
> felt useful for the target platform (i.e. the nature of thing being profiled)
>
> This is happening already - but using ad-hoc and non-interoperable ways to describe
> how these pieces relate to a profile.

Yes, I agree that this is _one possible way_ of publishing a profile (although I don't quite understand why there are two separate SHACL documents)

> 2) We are not "defining an application profile" - and just listing RDF vocabulary  do not
> seem to reflect practice in defining profiles either.  MUST still feels too strong - maybe
> in some cases it is reasonable to restrict properties to a set of known namespaces
> without further constraint.

Right, we're not "defining an application profile" but we are defining "application profile" (i. e. what an application profile is or at least what we think it is...). And I'd say that a list of what classes and properties a consuming application can expect is enough to make it an application profile. Cardinality constraints would be a kind of icing on the cake and an XML schema or a ShEx document adds whipped cream. (I assume that consuming applications don't count calories).

> 3) Our Use Cases do cover profile specification, but that doesnt mean we have to (or
> could) mandate the particular constraint languages or components used.  IMHO we can
> look at the "data exchange" scope through the lens of DCAT - and think about best
> practices in terms of "fine grained semantics" in DCAT descriptions - and the ability to
> point a user to these components of a profile in a standard way, within an RDF
> environment is a significant gain in interoperability.  We can also apply the same logic
> to profiles of DCAT itself, but the conceptual model of profiles we need for both these
> constitute a more broadly applicable best practice for describing any interoperability
> profile, and description is a key element of publication :-)

> So we seem to have a few strong leads into BP for publishing:
> 1) use of URI for identification and discovery of description
+1

> 2) Description of profile, including relationships and components
+1
* A human readable description of the profile (SHOULD)
* A reference to a base standard (SHOULD if applicable)
* A reference to one or more machine-processable formalisations (XML Schema et al.) (MAY?)
* ...

> 3) Usage in DCAT context
This I don't understand: We're not supposed to write individual profiles...

Best,

Lars

> On Tue, 10 Jul 2018 at 00:30 Karen Coyle <mailto:kcoyle@kcoyle.net<mailto:kcoyle@kcoyle.net>> wrote:
> Ah, thanks Rob - I didn't look closely at the origins. In any case, what
> this brings up for me beyond the interesting curiosity of a two-part
> SHACL solution is:
>
> 1. Are these (taken together) an example of "publication of an AP" as
> defined in our charter? with the emphasis on "publication"
>
> 2. Are we defining "application profile" in a way that an RDF vocabulary
> list alone is not sufficient, or must other constraints (cardinality,
> specific value constraints) must be included?
>
> 3. To what extent should our deliverable enter into the details of the
> content/components of an application profile? meaning: are we being
> asked to describe what are the elements of an application profile? (Our
> use cases tend in this direction.)
>
> kc
>
> On 7/7/18 4:19 PM, Robert Sanderson wrote:
> >
> > I would say that this is the library community, looking at the art world
> > through a very bibliographic lens. Steven Folsom talked about the work
> > at US2TS, notably as a way to build web forms.
> >
> > See: https://twitter.com/sf433/status/968663830451679232  I can ask him
> > for more details if there's interest?
> >
> > Rob
> >
> >
> >
> >
> >
> > On Sat, Jul 7, 2018 at 1:08 PM, Dan Brickley <mailto:danbri@google.com<mailto:danbri@google.com>
> > <mailto:mailto<mailto:mailto>:danbri@google.com<mailto:danbri@google.com>>> wrote:
> >
> >     On Sat, 7 Jul 2018 at 12:47, Karen Coyle <mailto:kcoyle@kcoyle.net<mailto:kcoyle@kcoyle.net>
> >     <mailto:mailto<mailto:mailto>:kcoyle@kcoyle.net<mailto:kcoyle@kcoyle.net>>> wrote:
> >
> >         I ran across an interesting use of SHACL for profiles, done by
> >         the art
> >         and museum community. The profiles are defined in SHACL, such as
> >         this
> >         example[1], and there is a separate SHACL graph for validation[2],
> >         presumably validation of instance data. This is a case I hadn't
> >         considered: separation of profile declaration and instance
> >         validation,
> >         both using SHACL. (There are other examples if you pop up in the
> >         repo.)
> >
> >
> >     Interesting! Is anyone collecting these already into a list (shex
> >     too)? There are a few others on Github
> >     e.g. https://github.com/BlueBrain/nexus-prov

> >     <https://github.com/BlueBrain/nexus-prov> (see
> >     also https://bbp-nexus.epfl.ch/dev/schema-documentation/documentation/shacl-

> schemas.html#namespaces-and-context
> >     <https://bbp-nexus.epfl.ch/dev/schema-documentation/documentation/shacl-

> schemas.html#namespaces-and-context>
> >     ) whose origins were apparently https://github.com/INCF/neuroshapes

> >     <https://github.com/INCF/neuroshapes>
> >
> >     Dan
> >
> >         kc
> >         [1]
> >         https://github.com/LD4P/arm/blob/master/application_profiles/art/shacl/artfra

> me_art_form.ttl
> >         <https://github.com/LD4P/arm/blob/master/application_profiles/art/shacl/artfr

> ame_art_form.ttl>
> >         [2]
> >         https://github.com/LD4P/arm/blob/master/core/validation/shacl/arm_core_pro

> perty_shapes.ttl
> >         <https://github.com/LD4P/arm/blob/master/core/validation/shacl/arm_core_pr
> operty_shapes.ttl>
> >         --
> >         Karen Coyle
> >         mailto:kcoyle@kcoyle.net<mailto:kcoyle@kcoyle.net> <mailto:mailto<mailto:mailto>:kcoyle@kcoyle.net<mailto:kcoyle@kcoyle.net>> http://kcoyle.net

> >         m: 1-510-435-8234 (Signal)
> >         skype: kcoylenet/tel:+1%20510-984-3600

> >
> >
> >
> >
> > --
> > Rob Sanderson
> > Semantic Architect
> > The Getty Trust
> > Los Angeles, CA 90049
>
> --
> Karen Coyle
> mailto:kcoyle@kcoyle.net<mailto:kcoyle@kcoyle.net> http://kcoyle.net

> m: 1-510-435-8234 (Signal)
> skype: kcoylenet/tel:+1%20510-984-3600