- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Fri, 9 Dec 2016 09:17:52 -0800
- To: public-data-shapes-wg <public-data-shapes-wg@w3.org>
Thanks, Dimitris. As I recall, at one point the model had sh:Constraint as a subclass of sh:Shape. Then sh:Shape became a subclass of sh:Constraint. I looked for a discussion and resolution for that but haven't found it. It may be in the discussions about simplification, but it isn't obvious to me. I was hoping to find the discussion that motivated that change. I also am not aware of any decisions to use OO as the SHACL design model. I don't know to what extent the current design forces that, but my understanding was that the group was charged with creating an RDF vocabulary, which, of course, leaves a lot unsaid. I would not like OO to be baked into the design, allowing implementers to work in the program style of their choice. As it stands today, I don't believe that the current design speaks clearly to those who must create SHACL graphs, and that is my first priority. Unfortunately, we haven't touched the primer in ages, so I can't look to that for the graph-writer view. In addition, the "high level language" requirement that had at one point meant integrating ShEx language seems to have fallen by the wayside. Basically, I'm not seeing the result that I believed I was signing up for. Not a happy camper, kc On 12/8/16 11:17 PM, Dimitris Kontokostas wrote: > 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 > <mailto: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> > <mailto: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> > <mailto: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> > <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> > <mailto: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> > > <mailto: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> > <mailto: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> > > <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> > <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> > <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> > <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 > <http://aksw.org/DimitrisKontokostas> > Research Group: AKSW/KILT http://aksw.org/Groups/KILT > > > -- > Karen Coyle > kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> http://kcoyle.net > m: 1-510-435-8234 > skype: kcoylenet/+1-510-984-3600 <tel:%2B1-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 > -- Karen Coyle kcoyle@kcoyle.net http://kcoyle.net m: 1-510-435-8234 skype: kcoylenet/+1-510-984-3600
Received on Friday, 9 December 2016 17:18:30 UTC