W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > March 2016

Re: issue-95 metamodel simplifications

From: Jim Amsden <jamsden@us.ibm.com>
Date: Fri, 4 Mar 2016 09:45:41 -0500
Message-Id: <201603041445.u24EjlZ0021506@d03av01.boulder.ibm.com>
To: "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
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

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 

- 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.


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 
> 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 
> scopes (triples with the shape as subject and sh:scopeNode, 
> sh:scopePropertyObject, or sh:scopePropertySubject as the predicate), 
> or more filters (values of sh:filter) which are themselves shapes, one 
> more components (triples with the shape as subject and one of the 
> properties as property, including associated triples as necessary), and 
> 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 
> 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 
> 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 
> one triple with the shape as subject.  The sole exception is closure, 
> closure could be reworked this way as well, but closure is special in 
> 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 
>                                        sh:minCount 1 ; sh:maxCount 1 ] ] 
] .
> sh:personShape is satisfied on a graph if all instances of ex:Person 
> all their stated names be strings, all their stated children belonging 
> 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 
> 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 
>                                                      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) 
> have ex:female as gender (the first filter) and have at least one 
> (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 
> scope of the shape satisfies the shape.  A sh:scopeNode filler selects 
> 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 
> 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 
> 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 
> 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 
> satisfy the shape is said to satisfy the shape.  A shape is satisfied on 
> set of input nodes if there are no in-filter nodes that fail to satisfy 
> 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 
> ...
> 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 
>   - 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., 
>     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 
>     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 
> 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: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, ...
Received on Friday, 4 March 2016 14:46:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:30 UTC