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

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