W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > January 2017

Re: shapes-ISSUE-221 (sh:Shape hierarchy): Simplify the class hierarchy of shapes [SHACL - Core]

From: Holger Knublauch <holger@topquadrant.com>
Date: Thu, 26 Jan 2017 17:14:38 +1000
To: public-data-shapes-wg@w3.org
Message-ID: <5d688f0c-d3ec-4574-289c-669cb325fd04@topquadrant.com>
Hi Dimitris,

the resolution of ISSUE-211 was a *package*. I reluctantly accepted 
several aspects of the redesign that I think were mistakes (in 
particular generalizing targets, which has significant costs because it 
offers too many ways to express the same thing). OTOH as part of the 
deal we kept the separation of the two metaclasses that I have explained 
several times, and this is something that you don't like.

I am unfortunately getting the impression that the notion of 
"compromises" has become a one way street. First you accepted my 
proposal for the compromise, but then you reopen a new issue which 
basically would take away the part of the deal that I needed. This is 
not how the W3C consensus process works.

And I do not remember that we discussed we look at the current design as 
a "counter proposal". This is the final solution for CR from my 
perspective. Reopening this whole discussion yet again isn't going to 
lead anywhere IMHO, just create divisions in the group.

Holger


On 26/01/2017 16:45, Dimitris Kontokostas wrote:
> Dear Holger, it is sad to hear that,
>
> when we discussed that issue you said that you will try to formulate 
> your counter proposal by mostly renaming terms and moving targets to 
> the upper class.
> Then, we would look at it again. We tried to do that yesterday but it 
> was suggested to use a new issue to track this and this is where we are.
>
> This is also tracked by the minutes and does not invalidate the 
> closing of issue 211
> https://www.w3.org/2017/01/11-shapes-minutes.html#resolution05
> https://www.w3.org/2017/01/25-shapes-minutes.html#resolution07
>
>
> On Thu, Jan 26, 2017 at 12:50 AM, Holger Knublauch 
> <holger@topquadrant.com <mailto:holger@topquadrant.com>> wrote:
>
>     Hi Dimitris,
>
>     what you are asking to remove here is the very thing that caused
>     me to vote in favor of the rest of your proposal. It was part of
>     the *compromise*. I am disappointed this is discussed yet once
>     again. I am strongly against even opening this ticket - it was
>     already discussed at length, invalidates the resolution to
>     ISSUE-211 and would set us back yet again with the release of the
>     spec.
>
>     Holger
>
>
>
>     On 26/01/2017 8:33, RDF Data Shapes Working Group Issue Tracker wrote:
>
>         shapes-ISSUE-221 (sh:Shape hierarchy): Simplify the class
>         hierarchy of shapes [SHACL - Core]
>
>         http://www.w3.org/2014/data-shapes/track/issues/221
>         <http://www.w3.org/2014/data-shapes/track/issues/221>
>
>         Raised by: Dimitris Kontokostas
>         On product: SHACL - Core
>
>         as a task from today;s resolution on ISSUE-211 I created this
>         issue
>
>         The current editors draft defines three classes for shapes:
>         sh:Shape with the following subclasses
>           -> sh:NodeShape
>           -> sh:PropertyShape
>
>         However, all shape-expecting constraint components (sh:shape,
>         sh:or, sh:and) use only sh:Shape and do not distinguish
>         between the two subclasses.
>
>         The only exception is sh:property that expects a property shape.
>         This, however, creates redundancy in the shape definitions e.g.
>
>         ex:a a sh:Shape
>            sh:shape [
>              sh:path ex:name;
>              sh:minCount 1;
>            ]
>
>         is the equivalent shape for
>
>         ex:a a sh:Shape
>            sh:property [
>              sh:path ex:name;
>              sh:minCount 1;
>            ]
>
>         In addition, property shapes, as a separate subclass of
>         sh:shape, are not needed anywhere else in the spec. There very
>         few occurrences can be easily reworded.
>
>         This indicates that the only reason for this hierarchy is
>         sh:property and this is something that can be defined with
>         sh:shape.
>
>         It would be a great simplification if we removed both
>         subclasses and kept only sh:Shape as defined in
>         https://jimkont.github.io/data-shapes/shacl/core.html#shacl-shapes
>         <https://jimkont.github.io/data-shapes/shacl/core.html#shacl-shapes>
>         https://jimkont.github.io/data-shapes/shacl/core.html#value-nodes
>         <https://jimkont.github.io/data-shapes/shacl/core.html#value-nodes>
>
>
>
>
>
>
>
>
> -- 
> 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 
> <http://aksw.org/Groups/KILT>
>
Received on Thursday, 26 January 2017 07:15:17 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 26 January 2017 07:15:17 UTC