- From: Holger Knublauch <holger@topquadrant.com>
- Date: Fri, 11 Mar 2016 11:01:41 +1000
- To: "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
Thanks for your prompt responses. It would be great if we could get
through this topic as soon as we can.
On 11/03/2016 9:54, Peter F. Patel-Schneider 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.
No, the tools will have to do even more work in your case, because there
are more syntax variations to express the same thing (in your approach,
multiple fillers may exist, but also sh:and and now multiple sh:class
directly).
Furthermore, it is trivial to pick certain cases to support your case.
We need to look at the big picture, and many different examples. I would
consider the case of "Person and teacher" to be not very common, but
others will of course disagree and make the claim it's critical. So how
would anyone decide that? It will always be subjective.
>
> 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.
(I thought you had "sh:fillers". Did this change already?)
I think your proposed handling of flags is unusable. You suggest a
completely different (list) syntax if flags are present compared to if
only the pattern exists.
>
> 5/ Merging constraints and shapes does not limit the places where severity
> and other information can be attached.
Let's look at an example. Here is the current syntax:
ex:MyShape a sh:Shape ;
sh:scopeClass ex:MyClass ;
sh:constraint [
sh:closed true ;
sh:severity sh:Warning ;
rdfs:comment "Note that this is just a warning" ;
] ;
sh:constraint [
sh:or ( ... ) ;
] .
How does this look like in your syntax?
>
> 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.
I think you should decide one way or another, it becomes too fuzzy
otherwise.
>
> 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.
I thought we were discussing about real-world RDF, not some theoretical
constructs. It is invalid to have literals as subjects. The language
should help users avoid such silly mistakes. Proposal 3 supports this as
part of the metamodel, while Proposal 4 just glances over this useful
feature.
But beside sh:minInclusive, how would sh:minCount work for a stand-alone
shape? And please provide a (single) SPARQL query to back its
implementation, because that's another thing that your approach claims.
>
> 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?
I have explained this for ISSUE-134:
https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Mar/0126.html
How does your approach handle this?
>
> 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.
What is "one of whatever"? Please provide a (single) SPARQL query that
implements this.
>
> 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.
What matters is that your design has made this situation by orders of
magnitude worse. This was not an improvement but a leap backwards.
>
> 19,20/ These appear to be implementation issues.
This is not an acceptable response.
Again, you claimed that your approach has improved usability and the
metamodel. None of this is the case here. You have added unnecessary
dependencies on the shapesGraph and made every SPARQL query slower and
much more verbose. Users will not be happy about this (unnecessary)
change. This problem was already solved in Proposal 3.
>
> 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?
If multiple templates use the same property, then all of them will be
executed. Sharing of properties is a natural thing in RDF, and your
approach prohibits this common practice (this should have been issue 28).
>
> 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.
You have not responded to my point. Your approach does not work at all.
It is not possible to dynamically create the triples for such a list.
And what would be the advantage of doing that?! You are trying to put a
square peg into a round hole only to keep the single-property philosophy
alive.
>
> 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.
I had shown that the list syntax is not simpler at all, e.g. in JSON-LD.
Neither is it transparent to users nor efficient for machines. If you
switch to an object-like syntax (please do!) then you basically end up
with the current syntax.
>
> 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.
I cannot follow here. What are the fillers of the path here:
ex:MyShape
a sh:Shape ;
sh:scopeClass ex:Person ;
sh:minCount 1 .
Holger
>
>
> 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_simplifications#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 01:02:16 UTC