Re: New Terminology Section

On 5/8/16 3:54 PM, Holger Knublauch wrote:
> On 7/05/2016 23:14, Peter F. Patel-Schneider wrote:
>> On 05/06/2016 09:54 PM, Holger Knublauch wrote:
>>> On 7/05/2016 2:14, Peter F. Patel-Schneider wrote:
>>>> I think that instead of reiterating descriptions from RDF 1.1
>>>> Concepts and
>>>> Abstract Syntax, and having errors in at least one of the
>>>> descriptions, it
>>>> would be better to just defer to that document.
>>> Where is the error? The definitions of terms like node and triples
>>> are just
>>> meant to be links to the RDF spec.
>> The definitions of terms like node and triples are definitely
>> different from
>> RDF 1.1 Concepts and Abstract Syntax.  Here are just two examples that I
>> noticed at first glance.
>> 1/ An RDF triple does not consist of three nodes.
>> 2/ It is RDF terms that can be IRIs, literals, or blank nodes, not
>> nodes.  RDF
>> does not define a notion of a node outside of the nodes of an RDF graph.
>> Each and every time new wording is used to describe existing notions
>> there is
>> a decided chance for an inconsistency to be introduced.  It is safer, and
>> better, to just say something like
>> This document uses "RDF graph", "RDF triple", "IRI", "literal", "blank
>> node",
>> "node" of an RDF graph, "RDF term", and "subject", "predicate", and
>> "object"
>> of RDF triples as defined in Section 3 of RDF 1.1 Concepts and
>> Abstract Syntax.
> Ok, applied.
>> Similarly for other notions from RDF and RDFS that are used in SHACL.
>>>> I think that it is a bad idea to redefine terms from RDF and RDFS.
>>>> Like it or
>>>> not, some readers of SHACL documents will use the RDF and RDFS
>>>> definitions of
>>>> terms like subclass and superclass when reading SHACL documents even
>>>> if these
>>>> terms are redefined in the SHACL documents.
>>> The goal of this terminology section was to divide and conquer the
>>> problem
>>> space so that we have specific small snippets to work on. Everyone is
>>> welcome
>>> to contribute here. Pointing out that something is "a bad idea" needs
>>> to be
>>> followed by a specific suggestion on what to do instead. We already
>>> spoke at
>>> length about not using terms from RDFS if they have different meaning in
>>> SHACL. You suggested using "SHACL instance" instead of "instance"
>>> etc. If that
>>> is still your suggestion, I have no problem switching to that term
>>> within the
>>> spec (although I doubt anybody will ever use these terms elsewhere
>>> and that it
>>> would make a difference in practice). The CSS styling of underlining
>>> each use
>>> of these terms to go back to their definition should also help.
>>> But if someone has better terms for "instance", "class", "subclass" and
>>> "type", then please make suggestions. My role as an editor is not to
>>> create
>>> the whole content, but to reflect what the WG has decided.
>> My view is that instead of introducing new notions that use the same
>> words or
>> phrases as notions from RDF and RDFS SHACL should use new phrases,
>> e.g., SHACL
>> instance.   I have been very clear about this throughout.
> Arnaud, could we put finalizing these terms on the agenda for next
> meeting? We know Peter's position, but I'd like to hear from others too.

I definitely throw in with Peter. Right now (and I realize that this is 
an area of the spec that is undergoing change) "type" is defined as:

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 

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.


> Thanks,
> Holger

Karen Coyle
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600

Received on Monday, 9 May 2016 17:47:54 UTC