Re: issue-95 metamodel simplifications

As a new-comer, who is quite familiar with the well practiced 
ResourceShapes 2.0, I don't personally find the current metamodel that 
complex, or the SHACL syntax that difficult to read and understand. Rather 
I'm having more trouble understanding the simplifications. But its a lot 
to digest.

Perhaps focusing on  the business case for SHACL: the capabilities and 
value propositions that are derived from the use cases; we can assess what 
we have as a deliverable to a community in a time horizon, and its ability 
to produce a desired outcome. That might yield better results than 
worrying too much about the metamodel or even the syntax.



Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575




From:   Holger Knublauch <holger@topquadrant.com>
To:     "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
Date:   03/02/2016 09:36 PM
Subject:        Re: issue-95 metamodel simplifications



Some serious problems with this proposal:

- it would set us back to somewhere mid-2015; all specs, examples, 
tests, implementations, user experiments etc will need to be rewritten 
or discarded, nobody has any experience of how well this approach would 
work.

- the extension mechanism has disappeared, this only covers the current 
snapshot of the core language.

- the syntax is not simpler at all IMHO. A comprehensive study on users 
would be needed to evaluate which syntax is better.

All of the above are show stoppers from my perspective. And a closer 
look will probably reveal more issues. I would find it very unfortunate 
if this sets us back by months, with endless discussions. Neither do I 
understand what problem this is supposed to solve. I see no need to 
challenge everything based on what basically amounts to personal taste 
about the syntax. The current design has reached a certain level of 
maturity, and instead of reopening all of that I think we really need to 
iron out the remaining details and then swiftly take the next step and 
work on test cases etc.

Holger


On 3/03/2016 10:13, Peter F. Patel-Schneider wrote:
>                A modest proposal for a revamped SHACL syntax
>
> This proposal rearranges the SHACL constructs, collapsing constraints 
and
> shapes into one construct.  The result is a more regular SHACL syntax 
with a
> simpler metamodel.  A few constructs become a bit more verbose.
>
> Syntax
>
> The main SHACL construct is a shape (sh:Shape).  Shapes have zero or 
more
> scopes (triples with the shape as subject and sh:scopeNode, 
sh:scopeClass,
> sh:scopePropertyObject, or sh:scopePropertySubject as the predicate), 
zero
> or more filters (values of sh:filter) which are themselves shapes, one 
or
> more components (triples with the shape as subject and one of the 
component
> properties as property, including associated triples as necessary), and 
can
> be closed (sh:closed value true, zero or more fillers of
> sh:ignoredProperty).
>
> Note:  The shape components might be called constraints.  I didn't use
> constraint so as not to cause confusion with the current constraints in 
SHACL.
>
> The syntax of the various components are:
> sh:class class
> ... (various other simple components)
> sh:pattern pattern
> Q: How to handle flags?  There are several options.
> sh:equals ( property/path ... property/path )
> sh:disjoint ( property/path ... property/path )
> sh:lessThan ( property/path ... property/path )
> ... (other comparison components)
> sh:fillers [ sh:property property/path; sh:shape shape ]
> sh:list shape
> sh:shape shape
> sh:and ( shape ... shape )
> sh:or ( shape ... shape )
> sh:not shape
> sh:minCard int
> sh:maxCard int
> sh:uniqueLang true
> sh:partition ( shape_1, ..., shape_n )
>
> A property/path is either a property or a list consisting of nodes 
linked to
> properties via sh:property or sh:propertyInverse.  (Yes, this is a bit
> unclean.)
>
> Note:  Qualified cardinalities are replaced by an embedded shape where 
the
> embedded shape's filter has the same role as the filler for
> sh:qualifiedValueShape.
>
> A vital aspect of this syntax is that each component of shapes uses 
exactly
> one triple with the shape as subject.  The sole exception is closure, 
and
> closure could be reworked this way as well, but closure is special in 
the
> semantics so it is not so bad to make it special in the syntax as well.
>
> Examples
>
> sh:personShape [ a sh:Shape;
>   sh:scopeClass ex:Person ;
>   sh:fillers [ sh:path name; sh:shape [ a sh:Shape; sh:datatype 
xs:string ] ] ;
>   sh:fillers [ sh:path child; sh:shape [ a sh:Shape; sh:class ex:Person 
] ] ;
>   sh:fillers [ sh:path age; sh:shape [ a sh:Shape; sh:datatype 
xs:integer;
>                                        sh:minCount 1 ; sh:maxCount 1 ] ] 
] .
>
> sh:personShape is satisfied on a graph if all instances of ex:Person 
have
> all their stated names be strings, all their stated children belonging 
to
> ex:Person, and have exactly one stated age, which is an integer.
>
> Note: Combining the path and the shape would shorten the syntax but does
> complicate the metamodel.  Alternatively sh:fillers coud take a 
two-element
> list.
>
> sh:SJG [ a sh:Shape;
>   sh:scopeClass ex:Person ;
>   sh:filter [ a sh:Shape ;
>     sh:fillers [ sh:path gender;
>                                sh:shape [ a sh:Shape; sh:in ( ex:female 
) ] ]  ];
>   sh:filter [ a sh:Shape ;
>     sh:fillers [ sh:path ( [ sh:property child ] [ sh:property child ] ) 
;
>                                sh:shape [ a sh:Shape; sh:minCount 1 ] ] 
] ;
>   sh:fillers [
>     sh:path child ;
>     [ a sh:Shape ;
>       sh:filter [ a sh:Shape ;
>                                                 sh:fillers [ sh:path 
gender;
>                                                      sh:shape [ a 
sh:Shape; sh:in ( ex:male ) ] ] ] ;
>       sh:class ex:Professional ] ] ] .
>
> sh:SJG is satisfied on a graph if all instances of ex:Person (the scope) 
and
> have ex:female as gender (the first filter) and have at least one 
grandchild
> (the second filter) have all their male children be instances of
> ex:Professional.
>
>
> Semantics (ignoring recursion)
>
> A graph satisfies a shape if the set of nodes of the graph selected by 
any
> scope of the shape satisfies the shape.  A sh:scopeNode filler selects 
that
> node.  A sh:scopeClass filler selects each node in the graph that is an
> instance of the class.  A sh:scopePropertyObject filler selects each 
node in
> the graph that is an object for that property.  A 
sh:scopePropertySubject
> selects each node in the graph that is a subject for that property.
>
> A shape satisfies a set of nodes (the input nodes) as follows.  The 
input
> nodes that satisfy each of the filters of the shape are called in-filter
> nodes, those that do not are out-of-filter nodes.  Some components 
(those
> involving sh:shape, sh:and, sh:or, sh:not, sh:minCard, sh:maxCard,
> sh:uniqueLang, and sh:partition) work on the set of in-filter nodes as a
> whole.  If a component of this kind is not satisfied then each of the
> in-filter nodes fails to satisfy the shape.  Some components (values of
> sh:class, ..., sh:pattern, sh:fillers) work on each in-filter node
> independently.  Each in-filter node that fails to satisfy one or more of
> these components fails to satisfy the shape.  If the shape is closed an
> in-filter node fails to satisfy the shape if it has a filler for some
> property that is neither the path of some component of the shape nor a
> filler for sh:ignoredProperty.  Each in-filter node that does not fail 
to
> satisfy the shape is said to satisfy the shape.  A shape is satisfied on 
a
> set of input nodes if there are no in-filter nodes that fail to satisfy 
the
> shape on these input nodes.
>
> The components work as follows:
>
> sh:class class - the node belongs to class
> ...
> sh:pattern pattern - the "name" of the node matches pattern
> sh:equals ( path ... )
>   - the node has the same fillers for each path
> sh:disjoint ( path ... )
>   - the fillers for the paths are pairwise disjoint
> sh:lessThan ( path ... )
>   - the fillers for a path are smaller than the fillers for the next 
path
> ...
> sh:fillers [ sh:path path; sh:shape shape ]
>   - the fillers of path for the node satisfy each shape
> sh:list shape
>   - the nodes in the list are the transitive-reflexive closure of 
rdf:rest
>   - each such node has a single filler for rdf:rest, except rdf:nil 
which has none
>   - each such node has a single filler for rdf:first, except rdf:nil 
which has none
>   - the nodes that are rdf:first fillers
>
> sh:shape shape
>   - the set of in-filter nodes satisfies the shape
> sh:and ( shape ... shape )
>   - the set of in-filter nodes satisfies each shape
> sh:or ( shape ... shape )
>   - each in-filter node is individually satisfied by some shape, i.e., 
if
>     there are only sh:class constructs then each in-filter node belongs 
to one
>     of them or
>     the set of in-filter nodes satisfies some shape, i.e., if there are 
n
>     fillers and a sh:minCard of n then the sh:or is satisfied
> sh:not shape
>   - the set of in-filter nodes does not satisfy the shape
> sh:minCard int - there are at least int in-filter nodes
> sh:maxCard int - there are at most int in-filter nodes
> sh:uniqueLang true - only one in-filter node for any particular language 
tag
> sh:partition ( shape_1, ..., shape_n )
>   - let input_1 be the set of in-filter nodes
>   - let input_i+1 be the out-of-filter nodes of shape_i on input_i
>   - shape_i is satisfied on input_i, for 1<=i<=n
>   - input_n+1 is empty
>
> Meta model classes and properties
>
>   - sh:Shape
>   - sh:scopeNode, sh:scopeClass, sh:scopePropertyObject, 
sh:scopePropertySubject
>   - sh:filter, sh:closed, sh:ignoredProperty
>   - sh:class, ..., sh:pattern, sh:equals, sh:disjoint, sh:lessThan, ...,
>     sh:fillers, sh:list
>   - sh:shape, sh:and, sh:or, sh:not, sh::minCard, sh:maxCard,
>     sh:uniqueLang, sh:partition
>   - sh:property, sh:propertyInverse
>   - sh:severity, sh:name, ...
>