- From: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
- Date: Fri, 9 Dec 2016 09:17:23 +0200
- To: Karen Coyle <kcoyle@kcoyle.net>
- Cc: public-data-shapes-wg <public-data-shapes-wg@w3.org>
- Message-ID: <CA+u4+a2Aaz8WnFboY8zN7MpJNKS1ec6oiZ1LUX_=fLKwmxpHaA@mail.gmail.com>
Hi Karen, The existing diagram is here: http://w3c.github.io/data-shapes/shacl/#shapes In Peter's original proposal there was only the Shape class and nothing else In my variation I have Shape as the main class and PropertyShape as the only subclass that contains the following properties - sh:predicate or sh:path : rdfs:Resource - sh:name : xsd:string or rdf:langString - sh:description : xsd:string or rdf:langString - sh:defaultValue : any - sh:group : sh:PropertyGroup see the attached diagram for a (not so pretty) visualisation On Thu, Dec 8, 2016 at 6:44 PM, Karen Coyle <kcoyle@kcoyle.net> wrote: > 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 > > -- 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
Attachments
- image/png attachment: diagram.png
Received on Friday, 9 December 2016 07:18:30 UTC