Re: invocation conflicting with sh:scope*

* Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de> [2016-06-24 23:10+0100]
> For me it is also fine to say that it is considered a good/best practice to
> keep scopes and shapes separated but I would prefer not to require it.
> Otherwise we would have to change a lot in the spec for things that are
> quite stable now e.g. validation will require 3 graphs, data, shapes &
> scopes

Understood, but that means that every example encourages the use of
sh:scope*, encouraging something that we don't consider good practice.


> We already suggest owl:imports in the spec as a way to merge different
> shapes graphs and this could be an option to keep shapes and scopes separate

Some of the examples would be simpler if we just had a typographic
convention like changing the results blocks from:
┌────────────────────────────┬────┐
│ Example validation results │    │
├────────────────────────────┘    │
│ ...                             │
└─────────────────────────────────┘
to:
┌───────────────────────┬─────────┐
│ Validation <X> as <Y> │         │
├───────────────────────┘         │
│ ...                             │
└─────────────────────────────────┘

If implementations followed the curent spec directly, users would have
to mechanically edit a schema graph in order to apply it to different
nodes or classes from which it was originally targeted. For example,
if your schema ties nodes of type ex:Person to my:StudenShape,

my:StudenShape sh:scopeClass ex:Person ;
  sh:property [ sh:predicate foaf:age ; # or path or whatever
                sh:maxInclusive 18 ] .

I'd have a hard time reusing that schema on data in the wild where
only some set of the ex:Persons were students. Specifically, I'd have
to edit your schema to remove the sh:scopeClass arc and maybe add a
set of sh:scopeNode assertions.

One could argue that the type should be more specific, but it's not
feasible for the author of the data to know what types would
discriminate the shapes that consumers of his/her data will need.


> On Thu, Jun 23, 2016 at 5:22 PM, Karen Coyle <kcoyle@kcoyle.net> wrote:
> 
> > I'm fine with creating a separation between scoping and constraint
> > definitions, although I think that SHACL should provide both or else it
> > cannot be a full, programmable solution to the RDF validation problem. By
> > separating them, a different solution to either function could be
> > substituted in the future.
> >
> > kc
> >
> >
> > On 6/22/16 10:26 PM, Eric Prud'hommeaux wrote:
> >
> >> * Holger Knublauch <holger@topquadrant.com> [2016-06-23 09:15+1000]
> >>
> >>> Hi Eric,
> >>>
> >>> when a shape is validated as part of a "nested" sh:shape, sh:and, sh:not
> >>> etc
> >>> then its declared scope is ignored. Only its sh:filterShapes will be
> >>> considered.
> >>>
> >>
> >> Understood, but this isn't about "nested" shapes. Many use cases
> >> involve a sort of late binding where the invocation context determines
> >> pairings of node/shape for validation. UC4 is explicit about this, but
> >> I expect the case where a user interface invokes sh:hasShape directly
> >> to be an extremely common case in linked data.
> >>
> >> We could get more reusability out of the schema by moving sh:scope*
> >> into a separate "control graph" (Peter's term), allowing that schema
> >> to be applied to other data that doesn't have e.g. a discriminating
> >> type arc.
> >>
> >>
> >> This is one of the reasons why the current spec states that node
> >>> constraints
> >>> are validated against each focus node individually, because the set of
> >>> scope
> >>> nodes is relatively orthogonal to the shape's current execution context.
> >>>
> >>> HTH
> >>> Holger
> >>>
> >>>
> >>> On 23/06/2016 8:03, Eric Prud'hommeaux wrote:
> >>>
> >>>> Is a validation engine expected to always honor sh:scope*?
> >>>>
> >>>> Apart from cardinality constraints on subjects of type arcs,
> >>>> validations boil down to various choreographies to invoke sh:hasShape,
> >>>> which effectively validates a node in a graph against a shape in a schema.
> >>>> There are of course an unenumerable number of ways that one may wish to
> >>>> connect nodes to shapes, user interface, posts to LD containers, routine
> >>>> sweeps of data stores, etc. So if one were to invoke a validation and the
> >>>> schema included some conflicting sh:scopeNode or sh:scopeProperty
> >>>> assertions, which would win?
> >>>>
> >>>
> >>>
> >>>
> >>
> > --
> > Karen Coyle
> > kcoyle@kcoyle.net http://kcoyle.net
> > m: 1-510-435-8234
> > skype: kcoylenet/+1-510-984-3600
> >
> >
> 
> 
> -- 
> Dimitris Kontokostas
> Department of Computer Science, University of Leipzig & DBpedia Association
> Projects: http://dbpedia.org, http://rdfunit.aksw.org,
> http://aligned-project.eu
> Homepage: http://aksw.org/DimitrisKontokostas
> Research Group: AKSW/KILT http://aksw.org/Groups/KILT

-- 
-ericP

office: +1.617.599.3509
mobile: +33.6.80.80.35.59

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.

Received on Wednesday, 29 June 2016 11:53:31 UTC