Re: what is inferencing?

There has been talk about inference related to sh:defaultValueType, which is
neither RDFS nor OWL inferencing, so the current discussion is not limited to
RDFS/OWL inferencing.  Given this, I was wondering just what inferencing means
in a SHACL context.  It appears to me that there is no reasonable way of
defining inference that does not overlap with what SHACL does.

There are certain kinds of inference that SHACL is almost certainly not going
to do, but that doesn't mean that SHACL doesn't do inference.


peter


On 05/10/2016 07:34 AM, Karen Coyle wrote:
> Jim, what I understood from the discussions on inferencing (which I found in
> various minutes from about a year ago) is that we were indeed referring to the
> RDFS/OWL function of inferring additional triples in a graph. The general
> concept, as defined by Peter, does not appear to be what we were talking
> about. So I should have been clearer about the context of the term in my
> messages, especially since so much time has passed.
> 
> kc
> 
> On 5/10/16 6:00 AM, Jim Amsden wrote:
>> Peter,
>> If by inferencing, you mean the the validation results are inferred from
>> information in the associated graph, then I see your point.
>>
>> Is the discussion about inferencing for SHACL addressing the case where
>> there is the possibility of using RDFS or OWL schema information to
>> infer additional triples in the graph itself that must be included in
>> the SHACL evaluations? If so, that might require any conforming
>> implementation to support inferencing in order to support SHACL, and
>> that may not only be limiting, but it might also be undesirable in some
>> usage scenarios such as those typically handled by OSLC Resource Shapes.
>> And it raises the question of which inferencing.
>>
>> A similar argument would apply to inferencing on the SHACL graph itself
>> assuming SHACL provides an RDFS schema.
>>
>>
>>
>> Jim Amsden, Senior Technical Staff Member
>> OSLC and Linked Lifecycle Data
>> 919-525-6575
>>
>>
>>
>>
>> From:  "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
>> To:  RDF Data Shapes Working Group <public-data-shapes-wg@w3.org>
>> Date:  05/09/2016 09:26 PM
>> Subject:    what is inferencing?
>> ------------------------------------------------------------------------
>>
>>
>>
>> There has been quite a bit of discussion of inferencing and SHACL recently.
>> However, there has not been much discussion on the actual relationship
>> between
>> SHACL and inferencing.
>>
>> It turns out that SHACL depends entirely on inferencing.  The definition of
>> sh:nodeKind, probably the simplest construct in SHACL, says "A validation
>> result must be produced for each value node that does not match the
>> given node
>> kind."  But this is inferencing!  True, a very degenerate form of
>> inferencing
>> but inferencing none the less.
>>
>> OK, let's rule out degenerate forms of inferencing, i.e., where all that is
>> required is looking at the form of an RDF term.
>>
>> But then there is sh:hasValue.  Its definition says "A validation result
>> must
>> be produced if the sh:hasValue is not among the value nodes."  This is again
>> inferencing and not so degenerate as the inferencing required for
>> sh:nodeKind.
>> This construct succeeds or fails depending on whether a specfic triple is
>> present in an RDF graph.   This is inferencing.  True, trivial
>> inferencing but
>> inferencing none the less.
>>
>> OK, let's rule out trivial forms of inferencing , i.e., where all that is
>> required is determining the presence of a single triple in an RDF graph.
>>
>> But then there is sh:minCount.  Its definition says "A validation result
>> must
>> be produced if the number of value nodes is less than the value of
>> sh:minCount."  This again inferencing and not inferencing that can be
>> done by
>> only looking for a single RDF triple.  Here the number of triples that
>> satisfy
>> a particular criterion has to be determined.  This is actually quite
>> sophisticated inferencing indeed.
>>
>> It thus seems that SHACL needs sophisticated inferencing.  Nonetheless let's
>> press on and rule out even the sort of inteferencing where triples have
>> to be
>> retrieved from an RDF graph until a set number of matching triples are
>> obtained.
>>
>> But then there is sh:class.  The definition of sh:class says "A validation
>> result must be produced for each value node that is either a literal or a
>> non-literal without a matching rdf:type. A non-literal matches a type if it
>> has an rdf:type value that is the given type or one of its (transitive)
>> subclasses, via rdfs:subClassOf."   So sh:class depends on the determination
>> of transitive closure, again a quite sophisticated kind of inference.
>>
>> So what does it mean that SHACL doesn't use inferencing?  As far as I
>> can see
>> the only true statement about SHACL and (non-)inferencing is that everything
>> in SHACL can be implemented by a simple translation from a SHACL shape to a
>> SPARQL query.  (This dividing line isn't even supported by the SHACL
>> document
>> as the translation there is not to SPARQL but some very significantly
>> extended
>> SPARQL.)   And even this isn't true if recursion is added to SHACL.
>>
>> It certainly isn't the case that the dividing line is the need to reason by
>> cases (or, equivalently, to entertain multiple models).   RDFS inferencing
>> does not need reasoning by cases and SHACL does not need all of RDFS
>> inferencing.
>>
>> If there is a dividing line, it may be that SHACL inferencing is not
>> inherently serial.  However, I'm not at all sure that SHACL is indeed not
>> inherently serial, even with numbers written in unary and without recursion.
>>
>>
>> The net result is that SHACL depends on inferencing, and even quite
>> sophisticated inferencing at that.
>>
>> peter
>>
>>
>>
>>
>

Received on Tuesday, 10 May 2016 19:11:02 UTC