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

Re: type and instance and subclass in SHACL documents

From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
Date: Wed, 11 May 2016 08:15:51 -0700
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: <0b31a0a9-9ea9-79d5-2180-78d89bb30cbd@gmail.com>
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
> 
Received on Wednesday, 11 May 2016 15:16:26 UTC

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