Re: issue-95 metamodel simplifications

On 5/03/2016 0:45, Jim Amsden wrote:
> 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.

I would have no problems whatsoever with keeping the current metamodel. 
However, some people in the WG didn't like the use of Abstract 
superclasses, which caused me to work on alternative designs.

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

I believe the requirements are well understood at this stage, and that 
we are basically comparing variations in the syntax. However, the longer 
we delay syntax decisions (or even worse, come up with yet another 
syntax in draft 3), the less time for community feedback we will get. I 
believe there needs to be very strong arguments in favor of syntax 
changes at this stage, or we miss the boat completely.

Holger


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