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

On Thu, Jan 26, 2017 at 9:14 AM, Holger Knublauch <holger@topquadrant.com>
wrote:

> 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.
>

Your proposal improved something that was broken in the previous version
and it was accepted as a better basis to discuss issue 211. This is also
tracked with the minutes and the discussion I recalled. People can correct
me if I am wrong.
Trying to make me look like the bad guy here isn't helping anyone imo.
Everyone in this WG has built his profile with his/her actions so far


> 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.
>

No matter how this issue is resolved it will be very easy to update the
spec. We have all the necessary text material available to copy.
So I do not see this blocking CR in any way.


>
> 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
> > 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
>>>
>>> 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#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
> Research Group: AKSW/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