Re: New Terminology Section

On Mon, May 9, 2016 at 8:18 PM, Holger Knublauch <holger@topquadrant.com>
wrote:

> On 10/05/2016 12:30, Tom Johnson wrote:
>
>
>
> On Mon, May 9, 2016 at 5:29 PM, Holger Knublauch <
> <holger@topquadrant.com>holger@topquadrant.com> wrote:
>
>>
>>
>> On 10/05/2016 10:11, Tom Johnson wrote:
>>
>> Irene, you say:
>>
>> > "Doing more" doesn't create a problem, but, on the other hand, it is
>> not required.
>>
>> I'm really uncertain about this. Couldn't inferring further class
>> relations (e.g., by using the entailment mechanism included in the spec)
>> cause different results for basically every operation in SHACL?
>>
>>
>> Can you think of a specific example? sh:entailment would potentially
>> produce additional triples. But this is the user's choice, and then the
>> user may expect to see additional validation results...
>>
>
> We seem to be in agreement that inferring additional triples will change
> results. Examples seem obvious; adding a `subClassOf` statement whose
> subject is any class referenced in a shape will do the trick, but that's
> far from the only example.
>
> This seems like a problem to me because I don't see that it's clear where
> triples like `subClassOf` must appear (data graph? shapes graph? any
> graph?) for a resource to count as a shape, or to match various constraint
> components.
>
>
> To have an effect on sh:scopeClass and sh:class, the subClassOf triples
> must be in the data graph.
>

Is this stated somewhere in the current spec? I haven't been able to find
it, if so.

Also, the question applies equally to cases where the intent is presumably
that (only?) the data graph counts. For instance: which resources count as
sh:Shapes?

> Note that adding a `subClassOf` triple to a shapes graph to effect
> validation could be considered a feature; I'm unsure whether that feature
> is supported.
>
>
> Currently the spec only looks at the data graph.
>
>
> Additionally, `sh:entailment` seems generally under/un-defined. Can
> inference effect data graphs only? or also shapes graphs? Which triples can
> be considered by a reasoner and how are inferred triples used by the SHACL
> semantics?
>
>
> I have just clarified this to the sh:entailment section:
>
>
> https://github.com/w3c/data-shapes/commit/71a9eeaff0317de0cdca6b36500412dabc922f78
>
> I am unsure how many people will actually use sh:entailment, so any
> feedback/requirement may help us add missing details. It is very brief
> right now, indeed.
>

I think some clear definition is called for; otherwise, I would simply
remove the feature; is there a functional difference between entailment (in
this case) and providing a mechanism for the user/engine to add arbitrary
triples to the data or shapes graph during pre-processing? This could be a
simpler way to think of the problem.

- Tom


Holger
>
>
>
> Some of my other concerns about the specifics of `class` and `instance`
> definitions seem to be in the process of being fixed up; from a quick
> reading of the latest editor's draft, this is looking promising.
>
> - Tom
>
>
>> Thanks, i
>> Holger
>>
>>
>>
>>
>> In lieu of a repeat of previous conversations, I'll just say: For me, as
>> an implementer in waiting, this is a huge problem. On last reading, very
>> little seemed unambiguously defined.
>>
>> - Tom
>>
>> On Mon, May 9, 2016 at 12:14 PM, Irene Polikoff < <irene@topquadrant.com>
>> irene@topquadrant.com> wrote:
>>
>>> Karen,
>>>
>>> As I understand it, RDFS inferencing is one way to address this. However,
>>> RDFS inferencing would do more than what is specified here. "Doing more²
>>> doesn¹t create a problem, but, on the other hand, it is not required.
>>>
>>> Another way to address this is to run a query as follows:
>>>
>>> SELECT ?resource
>>> WHERE {
>>>
>>> ?class rdfs:subClassOf* example:Class1 .
>>> ?resource a ?class .
>>>
>>> }
>>>
>>> Running this query would not change any graphs. As an aside, RDFS
>>> inferencing is also often done without modifying any graphs. Inferences
>>> are calculated on the fly when users/systems query data without any
>>> materialization of inferred triples. At least, this is how triple stores
>>> that support RDFS inferencing typically work.
>>>
>>> Does your concern have to do with where the rdfs:subClassOf triples come
>>> from - would they exist in the data graph, would they exist in the shapes
>>> graph? They could be in either. If no subclass triples are there, then
>>> the
>>> first triple match simply binds ?class to example:Class1 and the query
>>> result is the same as if we were only looking for nodes that are
>>> connected
>>> to example:Class1 via rdf:type link.
>>>
>>> It doesn¹t seem to be a role of SHACL to mandate where these triples
>>> should be located. If they are available in either of the graphs, a SHACL
>>> engine should take them into account. If they are not available, than it
>>> doesn¹t take them into account.
>>>
>>> In our experience, users typically put the subclass triples into the
>>> shapes graph. At the same time, they need flexibility to do whatever fits
>>> their architecture and processes.
>>>
>>>
>>> Irene Polikoff
>>>
>>>
>>> On 5/9/16, 1:47 PM, "Karen Coyle" < <kcoyle@kcoyle.net>kcoyle@kcoyle.net>
>>> wrote:
>>>
>>> >Type
>>> >The types of a node are its values of rdf:type as well as the
>>> >superclasses of these values.
>>> >
>>> >This conflates two different relationships: the relationship of a
>>> >subject to a class (as defined in RDF/RDFS), defining the subject as an
>>> >instance of the class; and the sub-/super-class relationships between
>>> >classes. I dont' see how this can be achieved without inferencing.
>>> >
>>> >If we assume some pre-processing of the data graph to include the
>>> >superclasses, then type is precisely as it is defined in RDF - there are
>>> >just more type statements in the graph.
>>> >
>>> >As stated, this is quite an expansion of the meaning of type. In
>>> >addition, it appears to require modifications to the data graph to
>>> >include the super classes of each class (presumably up to and including
>>> >rdfs:Resource).
>>> >
>>> >I think it would be best if SHACL defined the shape and data graphs as
>>> >immutable, thus expecting that all operations read but do not modify the
>>> >graphs. I thought we had come to that conclusion.
>>> >
>>> >kc
>>>
>>>
>>>
>>>
>>
>>
>> --
>> -Tom Johnson
>>
>>
>>
>
>
> --
> -Tom Johnson
>
>
>


-- 
-Tom Johnson