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

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 Thursday, 2 April 2015 22:38:21 UTC