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

ISSUE-65: type and instance and subclass in SHACL documents

From: Holger Knublauch <holger@topquadrant.com>
Date: Thu, 10 Mar 2016 15:47:27 +1000
To: public-data-shapes-wg@w3.org
Message-ID: <56E10A6F.6080904@topquadrant.com>
I would also like to know the answer to Irene's questions. If not, then 
I believe we can basically delete the contentious section 1.1. All we 
need to state is that SHACL does not require full RDFS inferencing. 
Section 1.1 has already created a lot of noise


I have filed this email under ISSUE-65 so that we don't forget about it.


On 8/03/2016 9:00, Irene Polikoff wrote:
> rdfs:subClassOf is defined as follows:
> "The property rdfs:subClassOf is an instance of rdf:Property that is used
> to state that all the instances of one class are instances of another.
> 		A triple of the form:
>    C1 rdfs:subClassOf C2
> states that C1 is an instance of rdfs:Class, C2 is an instance of
> rdfs:Class and C1 is a subclass of C2. The rdfs:subClassOf property is
> transitive."
> This definition doesnıt really require for any inferred triples to be
> present.
> Is there anything in SHACLıs use of rdfs:subClassOf that is contradictory
> to the above definition?
> The only wording close to the definition of the word ³instance² that I
> found in the specs is:
> "The members of a class are known as instances of the class.²
> Finally, rdf:type is described in the RDFS spec as
> "The rdf:type property may be used to state that a resource is an instance
> of a class.²
> RDF specs donıt talk about rdf:type.
> Is there anything in SHACLıs use of the word ³instance" or of rdf:type
> that contradicts this definition? If so, what is it?
> Irene Polikoff
> On 3/7/16, 5:36 PM, "Holger Knublauch"<holger@topquadrant.com>  wrote:
>> On 8/03/2016 1:51, Peter F. Patel-Schneider wrote:
>>> On 03/06/2016 08:46 PM, Holger Knublauch wrote:
>>>> Thanks for the feedback, Peter. I have tried to address it here:
>>> [...]
>>>> On 7/03/2016 6:59, Peter F. Patel-Schneider wrote:
>>>>> General
>>> [...]
>>>>> It is not sufficient to say in 1.1 that SHACL has unique versions of
>>>>> types
>>>>> and instances.  These notions are in very widespread use.  Each time
>>>>> that
>>>>> SHACL deviates from the common, accepted W3C practice it should be
>>>>> called
>>>>> out, e.g., "SHACL type" or "SHACL instance".
>>>> I hope this doesn't need to be repeated each time as this may render
>>>> the
>>>> document harder to read. Furthermore, the terms "SHACL type" and "SHACL
>>>> instance" would first need to be formally defined too.
>>>> Instead, I suggest we should define what "type", "instance" and
>>>> "subclass"
>>>> mean in the remainder of the document. I have put a corresponding
>>>> terminology
>>>> block at the end of section 1.1
>>> This is inadequate.
>>> SHACL uses RDF graphs and RDFS vocabulary.  There are already
>>> definitions of
>>> type and instance and subclass that come from RDF and RDFS.  SHACL
>>> needs to
>>> differentiate its version of type and instance and subclass from these
>>> dominant notions and this can only be reliably done by qualifying them
>>> each
>>> time they appear in formal SHACL documents.
>>> Alternatively the SHACL document could use different words for these
>>> relationships or could restrict the inputs that it handles so that it
>>> uses the
>>> dominant versions of type and instance and subclass.
>> My interpretation of the situation is
>> - RDF and RDFS define the IRIs of vocabulary terms rdf:type and
>> rdfs:subClassOf
>> - terms like subclass, type and instance already existed before RDFS and
>> carry intuitive meaning
>> - there is no need to over-complicate a situation that is already clear
>> to most readers
>> The only difference between our definitions of the terms is that you
>> think that subclassing must always require inferences (domain, ranges
>> etc). I believe these concepts are orthogonal. Some rdfs:subClassOf
>> triples may be the result of inferencing, but it doesn't matter to SHACL
>> where they came from. As long as we make this clear in the beginning, I
>> hope we can keep the document intuitive and not over-complicate it.
>> Holger
Received on Thursday, 10 March 2016 05:48:04 UTC

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