Re: Selected problems with Proposal 4

I agree that many of these are implementation issues, but then having the
implementation is very important - it shows that the proposal is indeed
viable, otherwise, it is all a bit hypothetical and here-say. Invariably,
implementation work uncovers issues (some smaller, some larger) that often
lead to the revisions of the proposal. Such incremental revisions tend to
add complexity and what looked clean and streamlined in the beginning
often starts to become considerably more convoluted.

Peter, are you planning to create a reference implementation for this to
actually prove the viability of your proposal?

Irene 


On 3/10/16, 6:54 PM, "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
wrote:

>Here are responses to some of the points that Holder makes.
>
>peter
>
>
>2/ The current SHACL syntax does not nicely handle some common examples.
>
>Consider a shape limiting a person's guru to be both a person and a
>preacher.  The Simplest current Way of doing this is something like
>  ex:foo a sh:Shape ;
>   sh:property [ sh:predicate ex:guru ;
>   	       	 sh:class ex:Person ] ;
>   sh:property [ sh:predicate ex:guru ;
>   	       	 sh:class ex:Preacher ] .
>In my proposal this would be
>  ex:foo a sh:Shape ;
>   sh:property ( ex:guru [ sh:class ex:Person; sh:class ex:Preacher ] ) .
>The current syntax results in shapes that are harder to analyze by tools.
>
>Consider a shape limiting the form of a SSN.  Right now this requires
>something like
>  ex:foo a sh:Shape ;
>   sh:property [ sh:predicate ex:guru ;
>   	       	 sh:pattern "[0-9]*" ] .
>My proposal is very similar
>  ex:foo a sh:Shape ;
>   sh:property ( ex:guru [ sh:pattern "[0-9]*" ] ) .
>However, to figure out what is going on in the current syntax requires
>looking for the flags property, also not so simple for tools.
>
>5/ Merging constraints and shapes does not limit the places where severity
>and other information can be attached.
>
>9,10/ I agree that paths add a lot of complication both for implementing
>constraints and for other toos.  I added them to see how complex they
>would
>be.  The proposal does not depend on paths.  I will indicate where the
>changes would be.
>
>11/ Even though RDF requires that subjects of triples are not literals,
>there is no reason to forbid literal-only constructs in places where
>literals can not appear.  For conforming RDF graphs these will always be
>false but for extended RDF graphs they will do the right thing.  SPARQL
>itself permits literals as the subject of triple patterns so that it will
>work well with extended RDF graphs.
>
>12/ If a construct like sh:minCount needs to know whether it is in the
>object of a sh:property or an sh:inverseProperty, then that is problematic
>in the current situation.  How is it to know?
>
>13/ In sh:fillers ( ex:property [ sh:minCount 1 ] ), the sh:minCount does
>work alone, without knowledge about its context.  All that it is saying
>that
>there is at least one of whatever.  If an implementation needs to know
>about
>the context then that is something to be fixed or worked around.
>
>17/ Optional parameters complicate matters no matter how they are set up.
>Putting the parameters together requires unpacking them.  Having two
>properties requires finding them both.
>
>19,20/ These appear to be implementation issues.
>
>22/ I believe that Arthur was against using metaclasses in the metamodel,
>i.e., that a template was a metaclass and a constraint was a class.  In
>this
>proposal templates are classes, not a metaclass.  Templates are also
>properties, so the IRI of the template can be directly used in shapes.
>This
>has the added benefit of tieing the template property to the template.  In
>the current setup instead separate bits of the template are required to
>state which properties carry its meaning.  This has a problem if two
>templates use the same properties.  Which template is to be used then?
>
>23/ I do not limit Functions to a single argument.  The information passed
>in is the list of the arguments, which can be split up in the SPARQL code.
>
>25/ I am not using list positions to "encode logic".  I am using list
>positions for syntax, so as to make the syntax more compact.  Even most
>logics uses list positions in their syntax.  If compactness is not a
>desirable feature then changing to a object-like syntax is simple.
>
>26/ Conceptually an expression like sh:minCount does not need to work on a
>focus node + path combination.  All that it really needs to know is the
>fillers of the path so that it can count them.
>
>
>On 03/10/2016 03:10 AM, Holger Knublauch wrote:
>> I took a reasonably in-depth look at
>> 
>> 
>>https://www.w3.org/2014/data-shapes/wiki/ISSUE-95:_Metamodel_simplificati
>>ons#Proposal_4
>> 
>> 
>> and below is my feedback.
>> 
>> Summary: I don't regard anything in this proposal as an improvement over
>> proposal 3. IMHO it presents a massive step backwards for both users of
>>the
>> core language and the advanced features. If there are ideas worth
>>harvesting
>> then these should be raised and examined individually. I support
>>re-opening
>> ISSUE-41 as suggested by Simon for the paths topic, and to generalize
>> sh:and/or/not so that they can directly point at sh:Constraints instead
>>of
>> just shapes.
>> 
>> HTH
>> Holger
>> 
>> 
>> General Problems
>> 
>> 1) Proposal 4 is poorly motivated. As Peter stated himself, he started
>>this
>> effort to simplify the metamodel. He made changes to the end-user
>>visible
>> syntax in order to "simplify" the metamodel. However, there was no
>>problem
>> with the end-user visible syntax to begin with. There was no need to
>>change
>> it, and the new syntax is a step backwards. The metamodel is far less
>> important than the user-facing syntax.
>> 
>> 2) The syntax changes seem to reflect Peter's world view that SHACL
>>should
>> only be a constraint checking language, not used to describe data or
>>even as
>> "a modeling language". The syntax changes have made the model less
>> predictable, and harder to use by algorithms such as form builders,
>>without
>> adding expressivity for constraint checking.
>> 
>> 3) There is no experience with this syntax. We need to redo all
>>evaluation,
>> repeat experiments, even revisit every single already closed ISSUE
>>whether it
>> is still valid under the new approach. External observers of SHACL will
>>be
>> upset that we made such changes so relatively late in the process. Such
>>a
>> drastic change will set us back by months. We'll likely need another
>>face to
>> face meeting. The arguments to justify all this are extremely weak.
>>Meanwhile
>> we will be losing a lot of time just debating something that I consider
>>a
>> non-starter. It would be much more productive to look at some key
>>aspects of
>> where Peter believes we could do better and work on incremental
>>improvements,
>> i.e. harvest some ideas that we agree on, instead of creating a
>>completely new
>> language.
>> 
>> 
>> On merging Shapes and Constraints
>> 
>> 4) There is nothing conceptually difficult about the current metamodel,
>>and
>> there was no need to change it. Shapes are a collection of constraints
>>and
>> define a scope. Constraints restrict the focus node, possibly following
>> properties. That's basically it. Shapes are similar to class
>>definitions and
>> intuitive to understand for most people. Merging these concepts blurs
>>the
>> lines, for no convincing reason. I expect that future use cases of
>>Shapes will
>> involve rules via a property such as shr:rule. Shapes serve as an
>>entity to
>> group focus nodes, and this role is independent of constraints.
>> 
>> 5) If Shapes are constraints then we are just repeating the same
>>mistake with
>> making sh:closed an attribute of the shape: We lose the ability to
>>specify
>> severity and other things. Basically, it has become impossible (or
>>arcane) to
>> specify different (node) constraints with different severity. For this,
>> constraints need to be objects attached to the shape. Alternatively
>>you'd need
>> shapes pointing at sub-shapes, but then you end up with different
>>syntaxes for
>> the same thing.
>> 
>> 6) If the main motivation for linking shapes and constraints was
>>syntactic
>> sugar, then we could make plenty of other incremental changes, such as
>> allowing the values of sh:and/sh:or to be sh:NodeConstraints, not just
>>Shapes,
>> or generalize sh:valueShape into sh:valueConstraint, pointing at
>>constraints
>> directly.
>> 
>> 
>> On property/inverseProperty vs generalized paths
>> 
>> 7) Paths can already be handled (in a very controlled form) using
>> sh:valueShape and derived values.
>> 
>> 8) The syntax for inverse properties becomes very ugly and inconsistent
>>with
>> how forward properties are represented:
>> 
>> ex:MyShape
>>     sh:fillers ( [ sh:inverse ex:parent ] [ sh:minCount 1 ] ) ;
>>     sh:fillers ( ex:parent [ sh:minCount 1 ] ) .
>> 
>> 9) Path expressions cause a lot of new complexity, computationally,
>> syntactically, for SPARQL generation etc.
>> 
>> 10) Path expressions make static analysis (for things like form
>>generation and
>> structural checking of a shapes model) almost impossible. If an
>>arbitrary path
>> can show up where we previously only had simple predicates, then a lot
>>of
>> extra checking and branching needs to happen to make sense of the
>>situation.
>> 
>> 11) It is incorrect to claim that all constraint types can be used in
>> combination with every path. For example, sh:minInclusive does not
>>apply to
>> inverse properties. The current metamodel and proposal 3 can express
>>this
>> using standard techniques (classes such as
>>sh:InversePropertyConstraint), but
>> Proposal 4 throws everything together and this ability is lost. As a
>>result,
>> tools cannot provide guidance about which values can actually be
>>entered when.
>> 
>> 12) Some constraint types require different SPARQL queries (or
>>JavaScript or
>> whatever) depending on the direction of a property (or even worse, for
>>an
>> arbitrary path). For example sh:minCount needs to count subjects versus
>> objects. Proposal 4 does not even talk about this and no example of
>>SPARQL
>> generation is given. Not all constraint types are of the simple
>>allValuesFrom
>> pattern implemented by NodeValidationFunctions.
>> 
>> 13) In cases like sh:fillers ( ex:property [ sh:minCount 1 ] ) the
>>"shape"
>> with the minCount is no longer working stand-alone, but it requires
>>knowledge
>> about its context (e.g. the specific path that was used) to work
>>correctly.
>> This is unclear and adds unnecessary complexity. It is an unnecessary
>> construct to have objects that change their meaning depending of their
>>parent
>> resource.
>> 
>> 
>> On the constraint types limited to a single property only
>> 
>> 14) This is a particularly poorly motivated change that goes backwards:
>>in
>> order to accommodate a "simplification" of the metamodel, the syntax was
>> changed and an unfounded claim is used that "multiple parameters are a
>>poor
>> syntax". The example in ISSUE-133 is skewed to give the impression that
>>a real
>> problem exists:
>> 
>> [ a sh:Propertyonstraint ;
>>     sh:pattern "http:*" ;
>>     sh:predicate ex:httpURL ;
>>     sh:datatype xs:string ;
>>     sh:minCount 1 ;
>>     sh:maxCount 1 ;
>>     sh:flags "i" ]
>> 
>> If your concern is readability of the source code, why would anybody put
>> sh:pattern and sh:flags so far apart? This is ridiculous. Just write
>> 
>> [ a sh:Propertyonstraint ;
>>     sh:pattern "http:*" ;  sh:flags "i" ;
>>     sh:predicate ex:httpURL ;
>>     sh:datatype xs:string ;
>>     sh:minCount 1 ;
>>     sh:maxCount 1 ]
>> 
>> and problem solved. If you are not editing the Turtle, then of course
>>it is a
>> matter of tool support, and any reasonable tool will of course group
>>those
>> parameters visually together. We even have sh:group and sh:order
>>attributes
>> for those purposes, and the ConstraintTypes bundle together their
>>parameters
>> in Proposal 3. The same information can (and will) be used by editing
>>tools
>> that write Turtle files.
>> 
>> 15) With single-parameter constraint types, and the need to use reified
>> objects or list parameters whenever you need to pass in multiple values
>> instead, the labeltemplate and sh:message templates become useless as
>>there is
>> no general mechanism to access the nested parameter values. They just
>>become
>> random objects and lists.
>> 
>> 16) If multiple parameters are needed, the problem of defining and
>>using them
>> is just shifted by one level. For example, proposal 3 has a uniform and
>> integrated syntax to define parameters. If you just point at an object
>>then
>> you need to talk (elsewhere) about the constraints on those objects.
>>This is
>> inconsistent, verbose, unmaintainable and not user friendly at all.
>> 
>> 17) There is no uniform syntax for parameters anymore. Some are just
>>plain
>> values, others are lists, others are objects. Consider the case of
>>sh:pattern.
>> In Proposal 4, the values of sh:pattern are either a string or a list
>>where
>> the first value is a string and the second another string, with a
>>different
>> meaning. Imagine having to write code, editors or even a SPARQL query
>>for
>> that. You'll end up with complicating UNIONs and ORs everywhere just to
>>handle
>> the variations due to the metamodel "simplifications".
>> 
>> 18) If you need parameter objects to pass in multiple logical
>>parameters, then
>> you basically *always* need access to the $shapesGraph. Peter was
>>strongly
>> against this for ages, and made a lot of noise about that. Now he has
>> completely reverted his position, just to accommodate his
>>"simplification",
>> and to even make it possible at all.
>> 
>> 19) If you need parameter objects to pass in multiple values, every
>>SPARQL
>> implementation of such a constraint type will first need to start with
>>a block
>> to retrieve all the real parameters that are nested in the object or
>>list.
>> Compare:
>> 
>> WHERE {
>>     GRAPH $shapesGraph {
>>         $myParam ex:value1 ?value1 .
>>         OPTIONAL {
>>             $myParam ex:value2 ?value2 .
>>         }
>>     }
>>     $this $predicate ?object .
>>     FILTER (doSomething(?object, ?value1) || (bound(?value2) &&
>> soSomethingElse(?object, ?value2))
>> }
>> 
>> versus the current syntax:
>> 
>> WHERE {
>>     $this $predicate ?object .
>>     FILTER (doSomething(?object, $value1) || (bound(?value2) &&
>> soSomethingElse(?object, $value2))
>> }
>> 
>> 20) Related to point 19) above, you will have a combinatorial explosion
>>of
>> parameters if you have multiple OPTIONAL blocks. This will sometimes
>>require
>> nested SELECT DISTINCTs etc.
>> 
>> 21) Proposal 4 separates the "shape" of a constraint type from its
>>actual
>> definition. This is verbose and harder to maintain. Proposal 3 handles
>>this
>> much more elegantly, where the constraint type itself doubles as a
>>shape, and
>> sh:parameter is basically a property constraint (pending the choice of
>>various
>> options). No need for separate shapes.
>> 
>> 22) sh:ComponentTemplate in Proposal 4 mixes rdf:Property and sh:Shape.
>>One of
>> the main points of criticism from Arthur (and others I believe) was
>>that my
>> proposal used metaclasses. Here something very similar happens again.
>> 
>> 23) Show stopper: Proposal 4 also limits Functions to just a single
>>parameter,
>> and claims that parameter objects can be passed into the function
>>instead.
>> This is not working, because it is not practically possible to
>>manipulate the
>> shapes graph prior to every function invocation. For example
>>ex:myFunction(2,
>> 3) would become ex:myFunction(ex:args) where [ ex:args sh:arg1 2 ;
>>sh:arg2 3
>> ]. This cannot work for cases such as ex:myFunction(2, ?value). Fixing
>>this
>> would cause an inconsistency in the way that functions vs other
>> parameterizables are defined. Proposal 3 handles all these consistently.
>> 
>> 
>> Miscellaneous
>> 
>> 24) The new syntax is not more user friendly at all, e.g. the proximity
>>of
>> sh:fillers vs sh:filter. What is a "filler" anyway? The existing syntax
>>from
>> Proposal 3 is very similar to Resource Shapes and OWL (restrictions),
>>both
>> have user experience and there was no need to switch to something like
>> sh:fillers.
>> 
>> 25) Show stopper: Using list positions to encode logic is a very bad
>> anti-pattern. The syntax
>> 
>>     sh:fillers ( ex:myProperty [ sh:minCount 1 ] )
>> 
>> may superficially look more compact, but it violates any established
>>design
>> pattern in either RDF or object-orientation. If something is a "path",
>>then
>> call it "path" in the data model. If something is a shape then call it
>>such,
>> even if the Turtle becomes a bit longer:
>> 
>>     sh:fillers [ sh:path ex:myProperty ; sh:shape [ sh:minCount 1 ] ) .
>> 
>> Just for the sake of it, following this "design pattern" someone could
>>model a
>> Person record as an rdf:List:
>> 
>>     (   "John"
>>         "Doe"
>>         "1971-07-07"^^xsd:date
>>         ex:USA )
>> 
>> Following your approach, if someone has multiple first names, make a
>>nested list
>> 
>>     ( ("John" "Edward" )
>>         "Doe"
>>         "1971-07-07"^^xsd:date
>>         ex:USA )
>> 
>> The "beauty" of your syntax fades quickly if you ever use this in other
>> formats such as JSON-LD:
>> 
>>     [ [ "John", "Edward" ],
>>         "Doe",
>>         { "@value" : "1971-07-07", "@type" :
>> "http://www.w3.org/2001/XMLSchema#date" },
>>         { "@id" : "ex:USA" } ]
>> 
>> The problem here is that lists don't allow you to create @contexts. A
>>better
>> JSON-LD syntax, using normal named properties instead of lists would be:
>> 
>>     { "firstNames": [ "John", "Edward" ],
>>         "lastName" : "Doe",
>>         "dob" : "1971-07-07",
>>         "country": "ex:USA" ]
>> 
>> So, creating an RDF vocabulary just so that it looks good in Turtle is
>>a very
>> bad idea. While the Person example above is for illustration purposes,
>>the
>> same issue happens for every sh:filler scenario and will happen with
>>custom
>> extensions too.
>> 
>> Needless to say, such rdf:Lists are almost impossible to use in SPARQL
>>or any
>> query-based approach.
>> 
>> 26) The claim that a simple sh:sparqlTemplate per componentTemplate is
>> sufficient is incorrect, because some templates need to operate on the
>>results
>> of path expressions (e.g. sh:class) while others need to look at the
>>full
>> focus node + path combination. There is no vocabulary to encode these
>> differences that could be used by an implementation. It would require a
>>novel
>> text-insertion mechanism for things like "insert path here".
>> 
>> 27) The SPARQL behind these templates cannot be reused in other SPARQL
>> queries, unlike sh:NodeValidationFunctions.
>> 
>> 
>

Received on Friday, 11 March 2016 00:38:35 UTC