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

Re: proposal for issue-211

From: Karen Coyle <kcoyle@kcoyle.net>
Date: Thu, 8 Dec 2016 08:44:34 -0800
To: public-data-shapes-wg@w3.org
Message-ID: <fc4f28ce-78b1-b6a3-37c5-20e2d5a964ac@kcoyle.net>
Dimitris, can you provide a diagram that can be compared to the current 
on in the spec? Thanks,

On 12/7/16 11:01 PM, Dimitris Kontokostas wrote:
> To answer some of the above comments
> Irene, we remove constructs from the language structure that we can put
> back as constraint components
> Holger explains the effect of this change in the current language
> Holger, IBM Resource shapes was a good language but we overloaded that
> with focus node constraints and sparql constraints.
> Until these were separate everything was clear and we had a clear OO
> design. After we merged node constraints with Shapes, definitions &
> overlaps of shapes, constraints and property constraints are not so
> clear in the spec.
> I would like to hear what others feel about this change
> On Thu, Dec 8, 2016 at 1:29 AM, Irene Polikoff <irene@topquadrant.com
> <mailto:irene@topquadrant.com>> wrote:
>     I do remember long discussions regarding nodes over resources that
>     happened well over a year ago.
>     At that time, I was advocating the use “resource” in the spec. I
>     believe it was Peter who said we could/shouldn’t use it. I could
>     never understand why for longer than 5 minutes at a time. That is, I
>     would understand the arguments and then loose their logic just a
>     little later. This means that, while may be formally correct on some
>     level, the arguments were very counterintuitive. In any case,
>     everyone was persuaded by Peter and we settled on using “nodes”. I
>     thought it would make harder to write and understand the spec. And I
>     think it did.
>     So, as you Holger, I felt deja vu when this came about again with a
>     complete reversal.
>>     On Dec 7, 2016, at 6:10 PM, Holger Knublauch
>>     <holger@topquadrant.com <mailto:holger@topquadrant.com>> wrote:
>>     The problem that this WG has is that the same topics are being
>>     reopened and rediscussed over and over again. The node-vs-resource
>>     discussion has happened many times over the last two years.
>>     Likewise the metamodel discussions are now reopened even though we
>>     already spent several months on this. We are clearly on the path
>>     of self-destruction. It is fine to have different opinions but
>>     topics like these do not have black and white answers. In such a
>>     situation, the process needs to include deadlines and have cut-off
>>     rules for discussions that simply bounce back and forth. Not
>>     everyone will get their will, and yes I still don't like the very
>>     concept of shapes and believe we should have just used classes.
>>     Many unnecessary discussions would have been avoided this way. In
>>     the end we all need to compromise and move on.
>>     Since the very beginning of the WG we had a design based on
>>     Resource Shapes in which shapes pointed at property constraints
>>     which pointed back to shapes. This design is easy to understand
>>     and well established, e.g. due to its similarity with OO modeling
>>     and XML schema. Shapes are like classes, and property constraints
>>     are like attributes and relationships of those classes. We have
>>     successfully lived with this design for a long time now, SHACL has
>>     been used in practice based on this design and feedback from our
>>     co-workers and customers is overwhelmingly positive. Some details
>>     (such as corner cases) have been pointed out over time but we have
>>     addressed them one by one. Nothing is fundamentally broken right
>>     now. None of the comments from the last three months caused any
>>     changes to the implementations, they were largely editorial.
>>     There is any number of possible metamodels that we could continue
>>     to try out. The proposed changes basically have two effects:
>>     a) Targets are being generalized so that any constraint (i.e. also
>>     property constraints and SPARQL constraints) can serve as entry
>>     points. While this is technically possible, it is IMHO an
>>     unnecessary change and one that just adds to the cost of learning
>>     and using SHACL, and to the cost for implementers because there
>>     are now many more ways that people could edit constraints. Form
>>     generation algorithms become more complicating. Editing tools need
>>     to support the additional patterns. The more different ways we
>>     have to express the same thing, the less interoperability we will
>>     have.
>>     b) Property constraints can directly point at other property
>>     constraints. This is again technically possible but adds little to
>>     no practical value. The same can be achieved with path expressions
>>     and nested shapes already. And it breaks the simple OO-like design
>>     that we currently have, for no convincing reason.
>>     In contrast to what Dimitris states, I believe making the
>>     suggested change will have enormous costs. It is a fundamental
>>     change to the metamodel. Every previous decision and discussion
>>     will need to be revisited. Nobody has practical experience with
>>     this design. I am strongly against making such a radical change a
>>     few weeks before we are trying to reach closure and CR status. The
>>     perceived benefits are subjective and speculative, while the cost
>>     of the change is very real. Furthermore, as explained above, I
>>     don't like the new design at all. To me as a tool implementer this
>>     is significantly adding to the costs. Also, while it solves some
>>     issues it introduces other problems, e.g. the overlap between
>>     sh:shape and sh:property.
>>     Oh and BTW the example that Dimitris gave is incorrect. It would
>>     need to be an instance of sh:PropertyShape instead of sh:Shape:
>>     ex:S1 a sh:PropertyShape ;  # not sh:Shape
>>       sh:targetClass ex:Person;
>>       sh:predicate ex:name ;
>>       sh:minCount 1 .
>>     The speculation that this may move us quicker to CR status is
>>     based on the assumption that it will appease Peter. Sorry, but
>>     Peter is not the only person who has an opinion or the right to
>>     submit feedback. There will be a lot of other people commenting
>>     and some of them may actually get confused by the new design's
>>     flexibility. We cannot make everyone happy. As long as we can
>>     prove that we have discussed the concerns, we can be confident to
>>     move on even if we disagreed with the suggestions.
>>     Dimitris: is this really a blocker for you or could you live with
>>     a -0.9 on the current design?
>>     Arnaud: we need proper deadlines and shift gears. This isn't going
>>     to converge otherwise.
>>     Holger
>>     On 8/12/2016 7:51, Dimitris Kontokostas wrote:
>>>     Hi Irene,
>>>     in my opinion, the language is greatly simplified since now
>>>     everything is a Shape so we have fewer definitions.
>>>     in addition, sh:property is not part of the language anymore but
>>>     only a constraint component like sh:shape.
>>>     practically,
>>>     if we choose to maintain backwards compatibility this change will
>>>     have no effect on most of the current SHACL syntax.
>>>     in addition, it will enable some useful shortcuts for some users
>>>     and it will make the syntax more intuitive for cases that would
>>>     most probably lead to invalid shape definitions
>>>     see for example a recent patch on the validation definition
>>>     http://w3c.github.io/data-shapes/shacl/#validation
>>>     <http://w3c.github.io/data-shapes/shacl/#validation>
>>>     "A node conforms to a shape if and only if the node conforms to
>>>     all of the constraints of the shape. Note that validation against
>>>     a shape processes the shape as a focus node constraint only, even
>>>     if the shape may have rdf:type triples or an expected type that
>>>     would also make it a property constraint."
>>>     On Wed, Dec 7, 2016 at 10:05 PM, Irene Polikoff
>>>     <irene@topquadrant.com <mailto:irene@topquadrant.com>> wrote:
>>>         Dimitris,
>>>         What does this practically mean?
>>>         100% percent of our users 90+% percent of the time will
>>>         describe shapes with constraints on multiple properties.
>>>         Thus, shapes that only support a description of a single
>>>         property constraint are of no practical interest to them and
>>>         to address their needs, the language has to makes it easy to
>>>         write and understand shapes that define conditions for
>>>         multiple properties.
>>>         I suppose if there is no effect on the existing syntax, these
>>>         requirements are addressed. But then, what problem are we
>>>         solving? How does adding another way to say the same thing
>>>         simplifies something?
>>>>         On Dec 7, 2016, at 4:06 AM, Dimitris Kontokostas
>>>>         <kontokostas@informatik.uni-leipzig.de
>>>>         <mailto:kontokostas@informatik.uni-leipzig.de>> wrote:
>>>>         here's the motivation behind this proposal
>>>>         It makes shacl more flexible and simplifies the language and
>>>>         the metamodel a lot with minimal changes in the current
>>>>         syntax and no effect on shacl full
>>>>         it removes any corner cases  / grey areas that have been
>>>>         pointed out in the past and we are patching / extending
>>>>         definitions to cover
>>>>         It makes it much easier to explain and define SHACL.
>>>>         Even though this requires to rewrite some parts of the spec,
>>>>         I believe it will take us faster to CR
>>>>         (attaching this to another issue is fine by me)
>>>>         On Wed, Dec 7, 2016 at 10:25 AM, Holger Knublauch
>>>>         <holger@topquadrant.com <mailto:holger@topquadrant.com>> wrote:
>>>>             Could you summarize what motivates this change? The
>>>>             "issue" mentioned in the email that you quote below is
>>>>             irrelevant. Users will *not* write such shapes. What is
>>>>             broken with the current design?
>>>>             Holger
>>>>             On 7/12/2016 17:38, Dimitris Kontokostas wrote:
>>>>>             After a lot of thought, I would like to propose a
>>>>>             change in shacl to close this issue.
>>>>>             the change is a slight variation of Peter's proposal
>>>>>             option #2 from this email
>>>>>             https://lists.w3.org/Archives/Public/public-rdf-shapes/2016Nov/0053.html
>>>>>             <https://lists.w3.org/Archives/Public/public-rdf-shapes/2016Nov/0053.html>
>>>>>             The variation adds the notion of sh:PropertyShape as a
>>>>>             subClass of sh:Shape.
>>>>>             This makes it easier to define some annotation
>>>>>             properties like sh:label that make sense on properties
>>>>>             only and gives us the option to keep sh:property in the
>>>>>             language if we want to.
>>>>>             if we decide to keep sh:property, it will become a
>>>>>             constraint like sh:shape but it will make all our
>>>>>             existing syntax valid and with the exact same behaviour.
>>>>>             So this approach will have no effect on the existing
>>>>>             syntax but will also regularise the language and enable
>>>>>             some new shorter forms of shapes e.g.
>>>>>             ex:S1 a sh:Shape ;
>>>>>               sh:targetClass ex:Person;
>>>>>               sh:property [
>>>>>                 sh:predicate ex:name ;
>>>>>                 sh:minCount 1 .
>>>>>               ]
>>>>>             could be also written as
>>>>>             ex:S1 a sh:Shape ;
>>>>>               sh:targetClass ex:Person;
>>>>>               sh:predicate ex:name ;
>>>>>               sh:minCount 1 .
>>>>>             if we decide to drop sh:property we would use sh:shape
>>>>>             instead and reduce the alternate ways we can define the
>>>>>             same thing.
>>>>>             I also checked this offline with Peter and he is
>>>>>             willing to help us get the new terminology right should
>>>>>             we decide to go this way
>>>>>             Best,
>>>>>             Dimitris
>>>>>             --
>>>>>             Dimitris Kontokostas
>>>>>             Department of Computer Science, University of Leipzig &
>>>>>             DBpedia Association
>>>>>             Projects: http://dbpedia.org <http://dbpedia.org/>,
>>>>>             http://rdfunit.aksw.org <http://rdfunit.aksw.org/>,
>>>>>             http://aligned-project.eu <http://aligned-project.eu/>
>>>>>             Homepage: http://aksw.org/DimitrisKontokostas
>>>>>             <http://aksw.org/DimitrisKontokostas>
>>>>>             Research Group: AKSW/KILT http://aksw.org/Groups/KILT
>>>>>             <http://aksw.org/Groups/KILT>
>>>>         --
>>>>         Dimitris Kontokostas
>>>>         Department of Computer Science, University of Leipzig &
>>>>         DBpedia Association
>>>>         Projects: http://dbpedia.org <http://dbpedia.org/>,
>>>>         http://rdfunit.aksw.org <http://rdfunit.aksw.org/>,
>>>>         http://aligned-project.eu <http://aligned-project.eu/>
>>>>         Homepage: http://aksw.org/DimitrisKontokostas
>>>>         <http://aksw.org/DimitrisKontokostas>
>>>>         Research Group: AKSW/KILT http://aksw.org/Groups/KILT
>>>>         <http://aksw.org/Groups/KILT>
>>>     --
>>>     Dimitris Kontokostas
>>>     Department of Computer Science, University of Leipzig & DBpedia
>>>     Association
>>>     Projects: http://dbpedia.org <http://dbpedia.org/>,
>>>     http://rdfunit.aksw.org <http://rdfunit.aksw.org/>,
>>>     http://aligned-project.eu <http://aligned-project.eu/>
>>>     Homepage: http://aksw.org/DimitrisKontokostas
>>>     <http://aksw.org/DimitrisKontokostas>
>>>     Research Group: AKSW/KILT http://aksw.org/Groups/KILT
>>>     <http://aksw.org/Groups/KILT>
> --
> Dimitris Kontokostas
> Department of Computer Science, University of Leipzig & DBpedia Association
> Projects: http://dbpedia.org, http://rdfunit.aksw.org,
> http://aligned-project.eu
> Homepage: http://aksw.org/DimitrisKontokostas
> Research Group: AKSW/KILT http://aksw.org/Groups/KILT

Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600
Received on Thursday, 8 December 2016 16:45:13 UTC

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