W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > March 2016

Re: type and instance and subclass in SHACL documents

From: Irene Polikoff <irene@topquadrant.com>
Date: Sat, 12 Mar 2016 13:39:50 -0500
Message-Id: <06184D06-7B41-4098-BC87-5B7D2F2BC967@topquadrant.com>
Cc: kcoyle@kcoyle.net, public-data-shapes-wg@w3.org
To: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
I think I should have said

> If {rdfs:range rdf:type rdf:Property} triple was provided to a SHACL engine

Got confused by Peter saying

>> Using the RDFS definition of instance, rdfs:label is an instance of
>> rdf:Property so it is in the scope of the shape and there is a violation.
>> Using the SHACL definition of instance, rdfs:label is *not* an instance of
>> rdf:Property so it is *not* in scope and there is *no* violation.


Weren't  we discussing rdfs:range as an example of a property in a combination with a shape saying that a property needed at least one rdfs:label?

And the data graph didn't have anything to do with rdfs:label.

Anyhow, this is getting more confusing and not clearer for me. Would be very glad for someone to shed the light.

Sent from my iPhone

> On Mar 12, 2016, at 1:05 PM, Irene Polikoff <irene@topquadrant.com> wrote:
> 
> We need rdf:type to know if something is an instance of a class (note that I am saying simply 'instance' because I do not see the difference).
> 
> If {rdfs:label rdf:type rdf:Property} triple was provided to a SHACL engine, then the violation would be raised.
> 
> How else could it be known from the data graph that rdfs:label is a property? Or are you saying that SHACL engines should always include triples in RDFS vocabulary when they do their processing? 
> 
> Sent from my iPhone
> 
>> On Mar 11, 2016, at 10:36 PM, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote:
>> 
>> Using the RDFS definition of instance, rdfs:label is an instance of
>> rdf:Property so it is in the scope of the shape and there is a violation.
>> Using the SHACL definition of instance, rdfs:label is *not* an instance of
>> rdf:Property so it is *not* in scope and there is *no* violation.
>> 
>> peter
>> 
>> 
>>> On 03/11/2016 04:50 PM, Karen Coyle wrote:
>>> Peter, I admit that I, too, am having trouble understanding this. (And so it
>>> isn't all on Peter, if anyone else "gets it" maybe they could weight in.) The
>>> SHACL document uses the term "instance" 78 times. I admit I only looked at the
>>> first couple of dozen of those uses. For the most part they appear to me to
>>> conform to the RDFS definition of "instance" - meaning an instance of class.
>>> In some cases the term is used more colloquially, but those places in the
>>> document don't seem to be definitional.
>>> 
>>> You say that it doesn't validate, but can you say what the difference is in
>>> the two definitions? I still see it as having to do with the vocabulary
>>> definition as opposed to the SHACL validation, but you didn't buy that when I
>>> suggested it. If I were to use a typical OWL-based validation, rdfs:range
>>> ex:label "range" would be flagged as inconsistent. The same would be true if I
>>> would have
>>> ex:someSubject dct:type "text" .
>>> (dct:type has a range of rdf-schema#Class)
>>> 
>>> If this isn't the issue, I would sure like to know what is.
>>> 
>>> Thanks,
>>> kc
>>> 
>>>> On 3/11/16 2:22 PM, Peter F. Patel-Schneider wrote:
>>>> The definition of SHACL depends on "instance".  This can be read to mean
>>>> "RDFS instance" or "SHACL instance".  Under the former meaning the data graph
>>>> does not validate against the shape.   Under the latter meaning the data graph
>>>> does validate against the shape.
>>>> 
>>>> peter
>>>> 
>>>> 
>>>>> On 03/11/2016 02:15 PM, Irene Polikoff wrote:
>>>>> I don¹t understand what you mean by
>>>>> 
>>>>> "validates against this shape under SHACL instance but not under RDFS
>>>>> instance.²
>>>>> 
>>>>> I am not able to parse the sentence.
>>>>> 
>>>>> What are you doing? Taking a shape described and the graph described and
>>>>> running it against SHACL engine? What execution validates and what
>>>>> execution doesn¹t validate?
>>>>> 
>>>>> 
>>>>> 
>>>>> Irene
>>>>> 
>>>>> 
>>>>> 
>>>>> On 3/11/16, 5:03 PM, "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
>>>>> wrote:
>>>>> 
>>>>>>> On 03/11/2016 01:01 PM, Karen Coyle wrote:
>>>>>>> 
>>>>>>> 
>>>>>>>> On 3/11/16 11:43 AM, Peter F. Patel-Schneider wrote:
>>>>>>>> Consider the following shape (using obvious prefix declarations)
>>>>>>>> 
>>>>>>>> sh:propertyShape a sh:Shape ;
>>>>>>>>  sh:scopeClass rdf:Property ;
>>>>>>>>  sh:property [ sh:predicate rdfs:label ;
>>>>>>>>                sh:minCount 1 ] .
>>>>>>>> 
>>>>>>>> The data graph (using obvious prefix declarations)
>>>>>>>> 
>>>>>>>> rdfs:range ex:label "range" .
>>>>>>>> 
>>>>>>>> validates against this shape under SHACL instance but not under RDFS
>>>>>>>> instance.
>>>>>>> 
>>>>>>> Isn't this a problem with every vocabulary and not just RDFS? If the
>>>>>>> rules of
>>>>>>> the vocabulary (such as domain and range) are not encoded as such in
>>>>>>> SHACL
>>>>>>> then the SHACL result can be "in violation" of the vocabulary
>>>>>>> definition.
>>>>>>> 
>>>>>>> Now, if that is the case then I understand that violating the foundation
>>>>>>> vocabulary of RDF/RDFS may be more grave than violating a user-developed
>>>>>>> vocabulary, and in some cases doing the latter may indeed be the
>>>>>>> intention of
>>>>>>> the SHACL definition. So do we want to build into SHACL that it must
>>>>>>> follow
>>>>>>> RDF/RDFS property and class definitions? And how feasible is that?
>>>>>>> 
>>>>>>> kc
>>>>>> 
>>>>>> This is only a real problem because SHACL uses "instance" in its
>>>>>> specification, this term is also used centrally in RDFS, and SHACL uses
>>>>>> RDFS
>>>>>> vocabulary.
>>>>>> 
>>>>>> The question then is how to read "instance" in SHACL documentation, i.e.,
>>>>>> how
>>>>>> to prevent readers of the SHACL documentation from seeing "RDFS instance"
>>>>>> where "SHACL instance" is meant.
>>>>>> 
>>>>>> 
>>>>>> peter
>> 

Received on Saturday, 12 March 2016 18:40:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:30 UTC