- From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Date: Sun, 13 Mar 2016 15:24:40 -0700
- To: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
- Cc: Karen Coyle <kcoyle@kcoyle.net>, public-data-shapes-wg <public-data-shapes-wg@w3.org>
Even in this situation I think that "instance" in the rest of the document needs to be qualified. Some readers of the document will know about RDFS instance and will need to be continually reminded that the meaning that they know for "instance" is not being used in this document. peter On 03/13/2016 07:20 AM, Dimitris Kontokostas wrote: > Looks like we are getting closer to a suggested resolution > > On Sun, Mar 13, 2016 at 12:10 AM, Peter F. Patel-Schneider > <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>> wrote: > > This discussion was about making the difference between RDFS instance and > SHACL instance (and similarly for type and subclass) clear. It is not about > making SHACL change at all. It is just that RDFS instance (and type and > subclass) is different from SHACL instance (and type and subclass) and in my > opinion that the difference should be noted every time instance, or type, or > subclass is used in SHACL documents because otherwise there is a very high > likelihood that readers will come to incorrect conclusions. > > As far as an actual editorial change to the document goes, I proposed using > "SHACL instance" instead of "instance". Similar changes for type and subclass > are also indicated. The definitions of the terms are already in the document > and their wording only needs to be tweaked slightly to make them definitions > of SHACL instance and type and subclass. > > > If we added this at the end of section 1.1., would it be sufficient? > "instance: A node is an instance of a class if one of its types (as defined > above) is the given class." (already there) > "Instances, in terms of the RDFS defintion of instance, will be referred as > "RDFS instance" > or would you still prefer to use instance (for RDFS) and SHACL instance ? > > > As far as what changes to SHACL are permissable without going back on previous > resolutions, it looks to me as if SHACL could be changed to use the entire > RDFS definitions of instance and type and subclass without technically > violating any resolutions. Right now SHACL does something about midway > between nothing and complete RDFS inferencing, so having some RDFS inferencing > can't be violating any resolution. There are lots of other points in this > middle that are not complete RDFS inference, and I believe that SHACL does not > need to implement all of RDFS reasoning to abide by RDFS instance and type and > subclass. This is a very lawyerly argument, but you did ask. > > > if this is something that doesn't change our resolutions and could work in > e.g. SPARQL endpoints I would be very open to revisit this issue > Should we move this to another thread? > > > To understand the difference between the SHACL treatment of type and instance > and subclass and the RDFS treatment of type and instance and subclass I > suggest reading the RDF Schema 1.1 at https://www.w3.org/TR/rdf-schema/. This > document lays out, in an informal setting, how type and instance and subclass > work in RDFS. It should be easily understandable by anyone in the working > group. The normative underpinnings for RDFS are in RDF 1.1 Semantics > https://www.w3.org/TR/rdf11-mt/ but I don't think that there is any need to > read this document and I do not know of any differences between the two > documents that affect the matter at hand. The SHACL treatment of type and > instance and subclass has been a matter of discussion in the working group. > There is a section of Shapes Constraint Language (SHACL), > http://w3c.github.io/data-shapes/shacl/#shacl-rdfs, that indicates how SHACL > treats instance and subclass (which should also talk about type, by the way). > > > section 1.1 also has a definition for type (not sure when it was added): > "type: The types of a node are the classes that are linked to the node via > rdf:type as well as their superclasses as defined above." > > > > I believe that the working group would work better if most of its members > understood the languages used in SHACL. I had thought that such knowledge was > common in the working group, but maybe not. > > peter > > > On 03/12/2016 03:02 AM, Dimitris Kontokostas wrote: > > Peter, you are one of the very few (if not the only) person in the WG who can > > understand these differences and help us overcome them. > > according to your opinion, > > - what parts of RDF/RDFS can be included in SHACL without altering any > > resolutions we had in this regard? > > - how does the spec needs to change to accommodate the different in meaning > > terms of type and instance? > > > > I will try to make an attempt but as I said you have the expertise to help us > > resolve this problems > > would something in the lines of the following work for section 1.1? > > shacl uses rdf and rdfs terms but performs no rdfs reasoning at all even for > > core rdfs terms i.e. a triple like rdfs:range ex:label "range" . does not > > infer ex:label rdf:type rdf:Property when this triple is validated in SHACL. > > When explicitly stated, SHACL may compute the transitive closure of some rdfs > > properties like rdfs:subClassOf through sparql property paths but without > > performing complete rdfs inferencing > > > > On Sat, Mar 12, 2016 at 5:36 AM, Peter F. Patel-Schneider > > <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com> > <mailto:pfpschneider@gmail.com <mailto: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 <mailto:pfpschneider@gmail.com> > <mailto:pfpschneider@gmail.com <mailto: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 > > >>>> > > >>> > > >>> > > >> > > >> > > > > > > > > > > > > > -- > > Dimitris Kontokostas > > Department of Computer Science, University of Leipzig & DBpedia Association > > Projects: http://dbpedia.org, http://rdfunit.aksw.org, > > http://http://aligned-project.eu <http://aligned-project.eu/> > > Homepage:http://aksw.org/DimitrisKontokostas > > Research Group: AKSW/KILT http://aksw.org/Groups/KILT > > > > > > > -- > Dimitris Kontokostas > Department of Computer Science, University of Leipzig & DBpedia Association > Projects: http://dbpedia.org, http://rdfunit.aksw.org, > http://http://aligned-project.eu <http://aligned-project.eu/> > Homepage:http://aksw.org/DimitrisKontokostas > Research Group: AKSW/KILT http://aksw.org/Groups/KILT >
Received on Sunday, 13 March 2016 22:25:11 UTC