RE: Use of SHACL for profiles

On Wednesday, July 18, 2018 2:02 AM, Simon.Cox@csiro.au [mailto:Simon.Cox@csiro.au] wrote:

> I see no reason why conformsTo is cardinality [1..1].

+1 to that!

> OTOH it is probably most helpful to point to one specification, and for that to supply
> information about overlaps.

Hmmm, that only works if the profiles really extend (or constrain or whatever) each other. If we have the case that profile A says "dcterms:creator is mandatory" and profile B says " schema:title is mandatory" then there is no overlap...

And I have the feeling that this discussion maybe advances too far into solution space.

Best,

Lars

> From: Rob Atkinson [mailto:rob@metalinkage.com.au]
> Sent: Wednesday, 18 July, 2018 09:56
> To: Cox, Simon (L&W, Clayton) <mailto:Simon.Cox@csiro.au>
> Cc: mailto:rob@metalinkage.com.au; mailto:L.Svensson@dnb.de;
> mailto:kcoyle@kcoyle.net; mailto:public-dxwg-wg@w3.org
> Subject: 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 <mailto: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:mailto:rob@metalinkage.com.au]
> Sent: Wednesday, 18 July, 2018 07:09
> To: Svensson, Lars <mailto:L.Svensson@dnb.de>
> Cc: Rob Atkinson <mailto:rob@metalinkage.com.au>; mailto:kcoyle@kcoyle.net;
> mailto: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 <mailto:L.Svensson@dnb.de> wrote:
> On Tuesday, July 10, 2018 6:54 AM, Rob Atkinson
> [mailto: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: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:mailto:danbri@google.com
> > > <mailto:mailto:mailto:mailto:danbri@google.com>> wrote:
> > >
> > >     On Sat, 7 Jul 2018 at 12:47, Karen Coyle <mailto:mailto:kcoyle@kcoyle.net
> > >     <mailto:mailto: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:mailto:kcoyle@kcoyle.net
> <mailto:mailto: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:mailto:kcoyle@kcoyle.net http://kcoyle.net

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

Received on Wednesday, 18 July 2018 10:57:47 UTC