- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Wed, 11 May 2016 08:45:26 -0700
- To: public-data-shapes-wg@w3.org
My question is: how many of these are fundamental to the functioning of SHACL? For example if this: > The values of sh:nodeKind must be instances of the class sh:NodeKind. were not declared, if we had only sh:nodekind without class sh:NodeKind, what would be the result? As I have said before, it isn't clear what these classes and their instances do in SHACL. In most cases the only reference to sh:ClassX in the spec is to say that sh:propertyX is an instance of it. kc On 5/11/16 8:15 AM, Peter F. Patel-Schneider 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 >> > > -- Karen Coyle kcoyle@kcoyle.net http://kcoyle.net m: 1-510-435-8234 skype: kcoylenet/+1-510-984-3600
Received on Wednesday, 11 May 2016 15:48:11 UTC