Re: List of open SHACL Core Syntax ISSUEs

On 14/07/2016 18:44, Dimitris Kontokostas wrote:
>
>
> On Tue, Jul 12, 2016 at 6:02 AM, Holger Knublauch 
> <holger@topquadrant.com <mailto:holger@topquadrant.com>> wrote:
>
>     Looking through the tracker tickets, many remaining tickets are
>     rather editorial, but the following aspects of the SHACL Core
>     syntax are currently unresolved.
>
>     ISSUE-133, ISSUE-135 and ISSUE-141: sh:Shape vs. sh:constraint vs.
>     sh:node
>
>     The three tickets above are related, and I have seen various
>     proposals with individual pros and cons.
>
>     a) Leaving as-is, i.e. representing node constraints as separate
>     objects via sh:constraint.
>     + Would mean: no further changes are needed
>     + Syntax is similar to sh:property, i.e. each constraint is linked
>     to a shape via a property
>
>     b) As b) but renaming sh:constraint to something like sh:node
>     + Would make the syntax more consistent with sh:property and sh:sparql
>
>     c) Merging sh:Shape and sh:NodeConstraint, attaching parameters
>     such as sh:closed directly to shape
>     + Better syntax to express mixed ranges (ISSUE-141) and
>     sh:and/sh:or (ISSUE-135)
>     + Arguably simpler metamodel
>
>     I am undecided but would welcome discussion around this topic so
>     that we can further stabilize the language. Adopting c) would have
>     quite some impact on the terminology because we would drop node
>     constraints. Such a change should be made before another editorial
>     swipe through the whole document. If we don't want to go this way,
>     we should at least have a decision and then close the related tickets.
>
>
> Personally I am between (b) and (c) with a preference for (b).
> If we choose (c), i.e. write constraints directly to the shape I think 
> it is more intuitive if we follow the approach of Peter's proposal and 
> change NodeConstraints.
> We would then apply the constraints to the set of focus nodes and not 
> to each focus node separately as we do now .
>
> e.g.   here is it clear (to me at least) that the constraint applies 
> on each node separately
> ex:ShapeA a sh:Shape;
> sh:scopeClass ex:Person ;
> sh:node [
>   sh:minCount 1;
>   sh:nodeKind sh:IRI ;
> ]
>
> but here it is confusing and more intuitive to apply on the set of all 
> persons
>
> ex:ShapeB a sh:Shape;
> sh:scopeClass ex:Person ;
> sh:minCount 1.
> sh:nodeKind sh:IRI .
>
> e.g. in the first example the sh:minCount makes no sense because it is 
> applied on each node that is a person, if there is none, nothing happens.
> while in the second it requires at least one person in the data graph

The problem remains that scopes are just one way among others to trigger 
shapes. Once someone uses the same ex:ShapeB from a sh:shape the whole 
set-based approach stops making sense. And then there are the syntax 
issues in SPARQL - it's IMHO more flexible, cleaner and easier to 
explain to have something like the current $PATH variable instead of 
some "magically" appearing boilerplate.

But I don't see adopting c) making the semantic change of node 
constraints necessary. My preference remains that the set-based 
constraint components such as sh:minCount simply don't apply to node 
constraints, and this resolves these questionable cases.

Overall I have a slight preference for c) right now because it provides 
a nice syntax for sh:and/or, allows us to represent mixed ranges, drops 
sh:classIn, avoids the naming decision of sh:node vs. sh:constraint and 
merges node constraints with shapes. But I would not vote -1 against the 
other options either, as they would be the smaller change. In any case, 
it would be lovely to see some decision, one way or the other, so that 
we can move on.

Holger



>
> Dimitris
>
>     Other tickets in the syntax category, less urgent:
>
>     - ISSUE-92: sh:partition vs qualifiedCount - waiting for input
>     from Eric and/or Iovka
>     - ISSUE-137: Should we add a constraint component for language tags?
>     - ISSUE-139: universal applicability (has little impact on core
>     syntax, yet impacts the metamodel/SPARQL)
>     - ISSUE-169: Renaming sh:scopeProperty to sh:scopeSubjectsOf
>
>     Regards,
>     Holger
>
>
>
>
>
> -- 
> 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
>