Re: type and instance and subclass in SHACL documents

On 12/05/2016 12:22, Karen Coyle wrote:
> The SHACL document says, in the introduction:
>
> "However, SPARQL is not required for the implementation of the SHACL 
> Core language."
>
> Our decision was to use SPARQL as the formal definition of SHACL 
> functions "where possible" but is it truly reasonable to provide this 
> functionality and NOT require SPARQL?

SPARQL is just one way among others to implement this functionality. For 
example, the rdfs:subClassOf* expression would turn into a recursive 
function in Java, avoiding duplicate classes that we have already visited.

>
> Before we get to that point though, could someone point out the 
> operations in SHACL that would logically make use of SPARQL query 
> (with or without the SPARQL "rdfs:subClassOf*"). I'm trying to 
> understand where it fits in.

sh:class implements this logic directly, see the SPARQL DEFINITION in 
section 3.1.1 which uses the exact rdf:type/rdfs:subClassOf* mechanism.

The other main place is sh:scopeClass. Once we have finalized the 
terminology section, the definition of sh:scopeClass in section 2.1.2 
will hyperlink to the term currently called "instances". That definition 
could be done in terms of SPARQL. Also note that all scope types 
including the core scope types and those from the extension mechanism 
can be backed by a SPARQL query to select focus nodes, see Section 8.2 
"SPARQL-based Scope Types".

So, using SPARQL is not only precise but also leads to a direct 
implementation path using SHACL's own extension mechanism.

BTW most other uses of the terminology currently discussed, such as "The 
values of sh:nodeKind must be instances of the class sh:NodeKind" 
basically reflect constraints on the SHACL system vocabulary itself 
("the sh:class of sh:nodeKind is sh:NodeKind"). This means that each 
time we use the term "instance" using the rdfs:subClassOf* definition, 
we basically rely on the same, consistent logic. In cases where we don't 
mean the same thing, we will use a different term. So once we have 
agreed on the terms to use, we will make a pass through the whole 
document and update each individual usage of the terms.

Holger


>
> Thanks,
> kc
>
> On 5/11/16 3:25 PM, Holger Knublauch wrote:
>> A precise definition can be achieved via SPARQL, e.g.
>> rdf:type/rdfs:subClassOf*. The subclass relationship and the additional
>> type relations are computed on the fly as part of the queries. Using the
>> term inferencing here is unnecessary and potentially harmful, because
>> inferencing is typically understood to produce additional "inferred"
>> triples from those that are "asserted". No new triples are needed.
>>
>> Holger
>>
>>
>> On 12/05/2016 8:16, Martynas Jusevičius wrote:
>>> So how do you express that form of subclassing? There surely must be a
>>> more precise and formal way than a sentence of prose. Even if it's not
>>> RDFS inferencing, it should be possible to define a different kind of
>>> inferencing for RDF, for example OO-like.
>>>
>>> It's not that SHACL implementations will need reasoners, their
>>> implementations just need to deliver results that are consistent with
>>> the official definition.
>>>
>>> Hint: RDF rules for definition.
>>>
>>> On Thu, May 12, 2016 at 12:03 AM, Holger Knublauch
>>> <holger@topquadrant.com> wrote:
>>>> SHACL doesn't do RDFS inferencing. SHACL uses a trivial and intuitive
>>>> form
>>>> of subclassing that had been invented long before RDFS, and is
>>>> well-established in OO systems. The fact that RDFS also reinvented a
>>>> similar
>>>> technique (and added some other inferencing rules) is orthogonal.
>>>> RDFS does
>>>> not have any rights to block these concepts or the terms for all 
>>>> future
>>>> technologies.
>>>>
>>>> The SHACL spec doesn't use the term inferencing except to state 
>>>> that it
>>>> doesn't rely on inferencing. Even if this WG decides to use other
>>>> terms than
>>>> "instance", "type" and "subclass", the effect to the end user will be
>>>> exactly the same. It's just a matter of clarity and politics.
>>>>
>>>> Holger
>>>>
>>>>
>>>>
>>>> On 11/05/2016 23:30, Peter F. Patel-Schneider 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.
>>>>>
>>>>>
>>>>> 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 ] .
>>>>>
>>>>>
>>>>> 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>> 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>>
>>>>>>>> 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
>>>>>>
>>>>
>>
>>
>>
>

Received on Thursday, 12 May 2016 04:38:40 UTC