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

Dear all,

as input to our meeting today I prepared this document to explain the
metamodel issues and how we got up to here.
I hope this will drive a constructive discussion in the meeting and will
help people that were not part of the WG from the very beginning.

an online version can be found here:
https://docs.google.com/document/d/1BtMVYzGv3jLgxpEeNSUsoOnLdJusUjIE-Wb5pqG4WHw/edit#

Best,
Dimitris

On Thu, Jan 26, 2017 at 12:41 PM, Dimitris Kontokostas <
kontokostas@informatik.uni-leipzig.de> wrote:

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


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