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

Re: type and instance and subclass in SHACL documents

From: Karen Coyle <kcoyle@kcoyle.net>
Date: Wed, 11 May 2016 08:45:26 -0700
To: public-data-shapes-wg@w3.org
Message-ID: <57335396.7000302@kcoyle.net>
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

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