- From: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
- Date: Wed, 11 May 2016 18:57:00 +0300
- To: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
- Cc: Holger Knublauch <holger@topquadrant.com>, public-data-shapes-wg <public-data-shapes-wg@w3.org>
- Message-ID: <CA+u4+a3ZRwj3Z5yaBmXFVpRZ_LTn8xVOMcX1g+J3c7btjAMdwQ@mail.gmail.com>
I wanted to see if by stating that there is no inferencing going on in either graphs (Except these two cases only) it would be acceptable to use the terms instance, subclass, superclass & type in all other cases we would be expecting an explicit type statement e.g. for instances of sh:NodeConstraint would be the set of all subjects in triples with rdf:type as predicate and sh:NodeConstraint as object I think everyone, including you, find the current definitions of sh:scopeClass / sh:class much better and more useful than disallowing inferencing from shacl completely and you also understand the reasons it is not feasible to have full rdfs reasoning in the data graph. We roughly have these options: 1. disallow inferencing completely from shacl (it would be a pity since it has very useful & practical use cases) 2. rename instance, subclassof, superclass to shacl instance, shacl subclassof, shacl superclass as you proposed some time ago (this will look very bad to the readers of shacl) 2.b many people probably object to redefine these terms again 3. limit inferencing further to the only absolutely necessary cases and say something at the beginning that takes us out of this awkward situation. We then use custom terms (e.g. shacl instance etc) in very few places that is needed Assuming we do not want to go to (1) can we come up for something in the direction of (3) if (2) is the only option, how would you rename e.g. "The values of sh:nodeKind must be instances of the class sh:NodeKind." to avoid any confusion with rdfs On Wed, May 11, 2016 at 6:15 PM, Peter F. Patel-Schneider < pfpschneider@gmail.com> wrote: > The word "instance" currently occurs 56 times in the SHACL specification. > Many of these occurences involve inferencing, notably > > Shapes are instances of the class sh:Shape > Class-based scopes define the scope as the set of all instances of a class. > If, in the shapes graph, a shape is an instance of both sh:Shape and > rdfs:Class > every instance of an abstract class > instances of sh:Scope > Instances of constraint types > instances of sh:NodeConstraint. > The property sh:class can be used to verify that each value node is an > instance of a given type. > The property sh:classIn can be used to verify that each value node is an > instance of a type from a given list. > The values of sh:nodeKind must be instances of the class sh:NodeKind. > The values of sh:in must be well-formed instances of rdf:List. > Property constraints may link to an instance of the class sh:PropertyGroup > The values of sh:constraint may be instances of any subclass of > sh:Constraint. > Validation results must be instances of the class sh:ValidationResult. > SHACL implementations may produce instances of other subclasses of > sh:AbstractResult, > The values of this property must be instances of the class sh:Constraint. > Each parameter must be an instance of sh:Parameter, > SPARQL-based scopes must be instances of sh:SPARQLScope, > The values of sh:derivedValues must be instances of a subclass of > sh:ValuesDeriver. > Functions that encapsulate a SPARQL query must be instances of > sh:SPARQLFunction > Each parameter must be an instance of sh:Parameter > Instances of sh:SPARQLFunction must have exactly one value for the property > sh:sparql > > This doesn't even consider "subclass" and "superclass", which both do show > up > in the SHACL specification. It also doesn't consider "type", which shows > up a > lot. > > So there is lots of RDFS inferencing going on in the shapes graph, and more > RDFS inferencing going on in the data graph than just for class scopes and > sh:class. > > > peter > > > On 05/11/2016 07:26 AM, Dimitris Kontokostas wrote: > > > > > > On Wed, May 11, 2016 at 4:30 PM, Peter F. Patel-Schneider > > <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>> wrote: > > > > But SHACL does do RDFS inferencing in the data graph. In > particular, the > > sh:class depends in RDFS inferencing, namely inference rule rdfs11 > from > > https://www.w3.org/TR/rdf11-mt/#rdfs-entailment. At one time > sh:class also > > depended on inference rules rdfs4a and rdfs4b as well as the RDFS > axiom > > rdf:first rdfs:domain rdf:List . > > > > So saying that SHACL doesn't do RDFS inferencing in the data graph is > > incorrect. > > > > > > Correct, so I will slightly revise > > > > we say that SHACL uses rdf and rdfs terms but a shacl processors takes > two > > immutable graphs (shapes & data) and performs no rdfs inferencing on the > > graphs at all > > except for two cases: sh:classScope and sh:class > > any other inferencing must be performed as a preprocessing step and is > out of > > scope for shacl > > > > ... define the term "shacl instance" and give more details on > sh:classScope > > and sh:class > > > > The wording now is noway near perfect but if you agree with this > direction > > maybe you can help us write it down in a nicer way > > > > > > > > > > Simmilarly SHACL does RDFS inferencing in the shapes graph when it > accepts > > ex:s1 as a shape in > > > > ex:Shape rdfs:subClassOf sh:Shape . > > ex:s1 rdf:type ex:Shape ; > > sh:scopeClass ex:Person ; > > sh:constraint [ rdf:type sh:NodeConstraint ; > > sh:nodeKind sh:IRI ] . > > > > (This appears to be an acceptable SHACL shape, based on the SHACL > > specification.) > > > > > > Of course, SHACL does not do *complete* RDFS inferencing. In > particular, > > there is no SHACL shape in > > > > ex:subClassOf rdfs:subPropertyOf rdfs:subClassOf . > > ex:Shape ex:subClassOf sh:Shape . > > ex:s1 rdf:type ex:Shape ; > > sh:scopeClass ex:Person ; > > sh:constraint [ rdf:type sh:NodeConstraint ; > > sh:nodeKind sh:IRI ] . > > > > > > Both of these cases can be considered (imho) edge cases. > > I believe no one will object to disallow them if we can get to a > resolution > > > > Dimitris > > > > > > peter > > > > > > > > > > On 05/11/2016 01:58 AM, Dimitris Kontokostas wrote: > > > I am reopening this old thread which is more related to the other > open > > > discussions we have atm. > > > > > > Looking at Tom Baker's emails and in particular [1] (the first > three > > > paragraphs under discussion) I was wondering if this can be a way > forward > > > > > > in particular say that SHACL uses rdf and rdfs terms but a shacl > processors > > > takes two immutable graphs (shapes & data) and performs no rdfs > inferencing on > > > the graphs at all > > > any inferencing must be performed as a preprocessing step and is > out of scope > > > for shacl > > > In there we define the term "shacl instance" which is used in only > two places > > > in the spec, in sh:classScope and sh:class and no-where else > > > if people believe that we should disallow optional rdf:type > statements (e.g. > > > for sh:property) I do not mind if this can unblock the current > situation > > > Peter, would using the terms instance, class or subClassOf be fine > under these > > > conditions? > > > > > > (I am also in favor of dropping sh:entailment btw) > > > > > > Any comments on this? > > > > > > Best, > > > Dimitris > > > > > > [1] > https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1605&L=DC-ARCHITECTURE&P=3148 > > > > > > On Tue, Mar 22, 2016 at 12:56 AM, Holger Knublauch < > holger@topquadrant.com <mailto:holger@topquadrant.com> > > > <mailto:holger@topquadrant.com <mailto:holger@topquadrant.com>>> > wrote: > > > > > > This is becoming a long long thread about what is an entirely > editorial > > > matter. I don't think it deserves the urgency. I also do not > agree that we > > > are misusing these terms at all. I believe to make progress we > could > > > > > > a) try to find alternative terms (Peter suggested "SHACL > instance" etc, > > > but it could also be "is-a") > > > b) follow the lead of what other, similar W3C specs are doing > > > c) define the terms in the beginning and then use them as <span > > > class="term">instance</span> so that the reader knows that we > use that > > > definition. That would be my preferred solution. > > > > > > Looking at the OWL 2 spec [1] the term "instance" is used in > many > > > different contexts, without even being defined: > > > - "Each OWL 2 ontology represented as an instance of this > conceptual > > > structure" > > > - "if an individual /a:Peter/ is an instance of the class > /a:Student/, > > > and /a:Student/ is a subclass of /a:Person/, then from the OWL > 2 > > semantics > > > one can derive that /a:Peter/ is also an instance of > /a:Person/." > > > - "Instances of the UML classes" > > > - Class expressions represent sets of individuals by formally > specifying > > > conditions on the individuals' properties; individuals > satisfying these > > > conditions are said to be /instances/ of the respective class > > expressions" > > > - ... > > > > > > Not only does OWL use the term "instance" inconsistently but > even > > changes > > > the RDF term by applying additional OWL semantics. RDFS does > not > > have the > > > monopoly on these terms. > > > > > > The problem is not our use of these terms but the misleading > section 1.1 > > > that needs to be replaced. I liked a previous proposal from > Dimitris, > > > along the lines of "SHACL is based on pattern matching like > SPARQL. > > > Inferencing is not required but there is no harm if > inferencing is > > > activated (be it OWL or RDFS inferencing)". Then define the > terms > > similar > > > to what we currently have at the end of section 1.1. And > that's it. > > > > > > Holger > > > > > > > > > > > > https://www.w3.org/TR/owl2-syntax/ > > > > > > > > > On 22/03/2016 4:15, Peter F. Patel-Schneider wrote: > > >> I don't think that this helps at all. In fact, all that it > does is > > further > > >> obfuscate the issue. The issue is that the wording needs to > be > > clear that in > > >> > > >> sh:shape rdf:type my:Shape . > > >> my:subClassOf rdfs:subPropertyOf rdfs:subClassOf. > > >> my:Shape my:subClassOf sh:Shape . > > >> > > >> my:Shape is not a SHACL shape, but that in > > >> > > >> sh:shape rdf:type my:Shape . > > >> my:Shape rdfs:subClassOf sh:Shape . > > >> > > >> it is. > > >> > > >> There are many cases where the SHACL notion of subclass, > instance, > > typing, > > >> etc., diverges from the common definition of these notions. > > >> > > >> peter > > >> > > >> > > >> On 03/21/2016 02:05 AM, Dimitris Kontokostas wrote: > > >>> Hi Peter, I did some research on other w3c specs regarding > the > > term instance. > > >>> > > >>> if we changed occurrences of instance from e.g. > > >>> "shapes are the instances of sh:Shape" to > > >>> "sh:Shape is the class of all shapes" > > >>> would this be fine from your side? > > >>> > > >>> Some cases like sh:class and sh:classScope would need extra > care > > of course. > > >>> > > >>> On Mon, Mar 14, 2016 at 12:24 AM, Peter F. Patel-Schneider > > >>> <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com> > > <mailto:pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>> > > <mailto:pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>> > > <mailto:pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>>> > wrote: > > >>> > > >>> 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 > > >>> > > > > > > > > > > > > > > > -- > > > Dimitris Kontokostas > > > Department of Computer Science, University of Leipzig & DBpedia > Association > > > Projects: http://dbpedia.org, http://rdfunit.aksw.org, > > > 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://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://aligned-project.eu Homepage: http://aksw.org/DimitrisKontokostas Research Group: AKSW/KILT http://aksw.org/Groups/KILT
Received on Wednesday, 11 May 2016 16:00:20 UTC