- From: Irene Polikoff <irene@topquadrant.com>
- Date: Thu, 10 Mar 2016 07:53:25 -0500
- To: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
- Cc: Holger Knublauch <holger@topquadrant.com>, public-data-shapes-wg <public-data-shapes-wg@w3.org>
- Message-Id: <384029E3-BF4C-41C5-8C5B-BED599470135@topquadrant.com>
If this is the extent of concern, then I believe it would be incorrect to say that SHACL uses a different meaning for rdfs:subClassOf or type. The meaning is the same and there is certainly no contradiction or clash, but SHACL engines are not required to perform complete RDFS inferencing. If the issue is that SHACL engines are required to perform a subset of RDFS inferencing, but not all of it, one way to address this is to say that SHACL defines an RDFS profile. For example, called RDFS CL. This profile includes only the following RDFS inferences: :A rdfs:subClassOf :B. :B rdfs:subClassOf :C. Infers :A rdfs:subClassOf :C :i rdf:type :A. :A rdfs:subClassOf :B. Infers :i rdf:type :B SHACL engines MUST support RDFS CL profile. Sent from my iPhone > On Mar 10, 2016, at 2:22 AM, Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de> wrote: > > Peter may correct me if I am wrong but the problem comes from the relation of rdf:type / rdfs:subClassOf* and the definition of subClass & subProperty in RDFS > if someone defines ex:subClassOf rdfs:subPropertyOf rdfs:subClassOf and uses ex:subClassOf in his relations SHACL will not be able to identify these relations. > This is more or less what the biggest part of section 1.1 is about. > > I think removing it completely will create more confusion. I would suggest to postpone this until we get close candidate rec and then see how this can be shortened. > >> On Thu, Mar 10, 2016 at 7:47 AM, Holger Knublauch <holger@topquadrant.com> wrote: >> 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 >> >> https://twitter.com/tombaker/status/694516400497545216 >> https://twitter.com/metazippy/status/659379807784992768 >> >> I have filed this email under ISSUE-65 so that we don't forget about it. >> >> Holger >> >> >>> 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 > > > > -- > Dimitris Kontokostas > Department of Computer Science, University of Leipzig & DBpedia Association > Projects: http://dbpedia.org, http://rdfunit.aksw.org, http://http://aligned-project.eu > Homepage:http://aksw.org/DimitrisKontokostas > Research Group: AKSW/KILT http://aksw.org/Groups/KILT >
Received on Thursday, 10 March 2016 12:54:08 UTC