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
>