- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Thu, 8 Dec 2016 08:44:34 -0800
- To: public-data-shapes-wg@w3.org
Dimitris, can you provide a diagram that can be compared to the current on in the spec? Thanks, kc 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