Re: shapes-ISSUE-23 (punning): Shapes, classes and punning [SHACL Spec]

In a punning design, I think the main difference would be that the triple { rdfs:Class rdfs:subClassOf sh:Shape } would be absent.

To make specialisation work, the cleanest version would appeal to RDFS inference to get additional rdf:type triples, and thus any constraints that happen to be attached to these types would go into effect as well. (I’m not saying that this would necessarily be my preferred solution, because it sucks for implementers. It’s just the simplest to specify.)

In both your draft design and a punning design, the difference between sh:valueType and sh:valueShape is very subtle and difficult to explain. Shape authors that decide to attach constraints directly to classes would likely be confused which of those to use.

Best,
Richard


> On 2 Apr 2015, at 23:36, Holger Knublauch <holger@topquadrant.com> wrote:
> 
> It may be more productive to look at specific proposals to this issue and then have those who have objections speak up and propose alternatives.
> 
> My current draft has this implemented as follows:
> 
> - There is a class sh:Shape which defines the system properties sh:property, sh:inverseProperty and sh:constraint.
> - The class rdfs:Class is declared to be rdfs:subClassOf sh:Shape (in the context of the SHACL system vocabulary).
> - As a result, any RDFS/OWL class is also a Shape.
> - Some core language elements such as sh:valueShape and sh:OrConstraint take sh:Shapes as arguments, which means that people could also use classes there.
> - Specialization of shapes (ISSUE-24) is addressed via the usual rdfs:subClassOf mechanism.
> - People may prefer to instantiate sh:Shape directly to avoid conflicts with RDFS classes, but these cannot have specialization (i.e. I don't think we should have both rdfs:subClassOf and sh:extends).
> 
> I believe this is the best possible compromise, especially for an incremental adoption path and existing data models. Another option that I could happily live with would be to delete sh:Shape and only have classes, but we had too much opposition to this earlier design called LDOM.
> 
> See also the ISSUE 2 at http://w3c.github.io/data-shapes/shacl/#shapes
> 
> Regards,
> Holger
> 
> 
> On 4/3/2015 6:27, Richard Cyganiak wrote:
>> Arthur,
>> 
>> I personally don’t see a problem with shapes being classes, but there is significant opposition to this notion from parts of the WG. I tried to paraphrase some of the justifications mentioned in the issue description.
>> 
>> Richard
>> 
>> 
>>> On 2 Apr 2015, at 21:20, Arthur Ryman <arthur.ryman@gmail.com> wrote:
>>> 
>>> Richard,
>>> 
>>> Thx. I believe that OWL needed to introduce punning because in strict
>>> Description Logic there is a partitioning of resources into disjoint
>>> sets, i.e. Class, Property, Individual.
>>> 
>>> I don't believe that we are basing SHACL on DL. Therefore there is no
>>> problem with SHACL triples having a their subject as a Class. Is there
>>> some problem with this? What am I missing? Do you imagine that a SHACL
>>> engine would need some way to distinguish a Shape from a Class? i.e.
>>> given an IRI, if it's a Class to one thing else if it's a Shape do
>>> some other thing?
>>> 
>>> -- Arthur
>>> 
>>> On Thu, Apr 2, 2015 at 4:00 PM, Richard Cyganiak <richard@cyganiak.de> wrote:
>>>> 
>>>>> On 2 Apr 2015, at 20:44, Arthur Ryman <arthur.ryman@gmail.com> wrote:
>>>>> 
>>>>> I am not familiar with the term "punning" in this context. Have you
>>>>> got a reference? Thx.
>>>> Arthur,
>>>> 
>>>> In logic, “punning” means to use the same name for multiple distinct things. In our context, it means using the same IRI for multiple distinct things. I’m only familiar with the concept through its use in OWL 2, where a single IRI can denote multiple things, for example a class and an individual. So I don’t have any deeper background references to offer, but the examples here should be enlightening:
>>>> 
>>>> http://www.w3.org/TR/owl2-new-features/#F12:_Punning
>>>> 
>>>> In the context of SHACL, a punning approach would mean that classes and shapes are still conceptually distinct, but SHACL authors could use a single IRI to refer to both a class and a shape. Informally stated, I could dangle some subClassOf triples and some sh:constraint triples off the same RDF node. The semantics of SHACL would have to be carefully written to tease apart these separate aspects, so that the RDFS-related mechanisms and the SHACL-related mechanisms don’t trip each other up.
>>>> 
>>>> Best,
>>>> Richard
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> -- Arthur
>>>>> 
>>>>> On Sat, Mar 28, 2015 at 4:14 PM, RDF Data Shapes Working Group Issue
>>>>> Tracker <sysbot+tracker@w3.org> wrote:
>>>>>> shapes-ISSUE-23 (punning): Shapes, classes and punning [SHACL Spec]
>>>>>> 
>>>>>> http://www.w3.org/2014/data-shapes/track/issues/23
>>>>>> 
>>>>>> Raised by: Richard Cyganiak
>>>>>> On product: SHACL Spec
>>>>>> 
>>>>>> Some people want to apply different shapes to the same class.
>>>>>> Some peope want to apply shapes to data that doesn't include type statements.
>>>>>> Some people want to associate shapes directly with class definitions.
>>>>>> Some people want to “inherit” shapes down existing class hierarchies.
>>>>>> Some people want to “specialise” shapes where there are no existing class hierarchies.
>>>>>> Some people don't want shapes to have anything to do with classes at all to avoid reinventing RDFS, badly.
>>>>>> 
>>>>>> No proposal seems to satisfy all people.
>>>>>> 
>>>>>> 
>>>>>> 
>> 
> 
>

Received on Friday, 3 April 2015 10:12:32 UTC