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