Re: Use of SHACL for profiles

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.

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.

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
2) Description of profile, including relationships and components
3) Usage in DCAT context

What other aspects of publication do you think we might want to cover?

BTW I think we can ground this discussion in Phil's nice introductory
blurb



On Tue, 10 Jul 2018 at 00:30 Karen Coyle <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 <danbri@google.com
> > <mailto:danbri@google.com>> wrote:
> >
> >     On Sat, 7 Jul 2018 at 12:47, Karen Coyle <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/artframe_art_form.ttl
> >         <
> https://github.com/LD4P/arm/blob/master/application_profiles/art/shacl/artframe_art_form.ttl
> >
> >         [2]
> >
> https://github.com/LD4P/arm/blob/master/core/validation/shacl/arm_core_property_shapes.ttl
> >         <
> https://github.com/LD4P/arm/blob/master/core/validation/shacl/arm_core_property_shapes.ttl
> >
> >         --
> >         Karen Coyle
> >         kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> http://kcoyle.net
> >         m: 1-510-435-8234 (Signal)
> >         skype: kcoylenet/+1-510-984-3600 <+1%20510-984-3600>
> >
> >
> >
> >
> > --
> > Rob Sanderson
> > Semantic Architect
> > The Getty Trust
> > Los Angeles, CA 90049
>
> --
> Karen Coyle
> kcoyle@kcoyle.net http://kcoyle.net
> m: 1-510-435-8234 (Signal)
> skype: kcoylenet/+1-510-984-3600 <+1%20510-984-3600>
>
>