Re: Use of SHACL for profiles

Was aware of that.

NB "model" is fairly loose - and schema is probably best done via a
qualified relationship (i.e. a Profile descriptor) where the standard the
schema conforms to (language it is written in) can be defined. At some
point I think we should revisit this wording in the context of profile
guidance.

Note we have just now formally voted to recognise requirement to be able to
express that conformance may be to >=1 profiles (a base specification is a
trivial profile of itself - as per A rdfs:subClassOf A ) - so should
dct:conformsTo list all profiles or just the most specific, or the ones a
community defines in its own DCAT profile?



On Wed, 18 Jul 2018 at 07:42 <Simon.Cox@csiro.au> wrote:

> 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> wrote:
>
> On Tuesday, July 10, 2018 6:54 AM, Rob Atkinson [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>
> 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:mailto:danbri@google.com>> wrote:
> > >
> > >     On Sat, 7 Jul 2018 at 12:47, Karen Coyle <mailto:kcoyle@kcoyle.net
> > >     <mailto: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: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 http://kcoyle.net
> > m: 1-510-435-8234 (Signal)
> > skype: kcoylenet/tel:+1%20510-984-3600
>
>