Re: on the turtle serialization of SHACL

Following linked data principles, every well-designed RDF vocabulary 
should have a machine-readable RDF graph at the web server of its 
namespace. The SHACL TTL file plays that role and will be uploaded to 
the W3C server at some stage. That's its main role. Whether the word 
"normative" is the right term I cannot say, so I have avoided this term 
for now:

https://github.com/w3c/data-shapes/commit/376aeaac562bf824943a383904728a06f19f88c6

Nowhere in the document we state that this file needs to be imported 
into a shapes graph, so it could not ever have fulfilled any other 
normative role anyway.

I am surprised you don't see any utility in referring to this document 
at all. Just a few days ago a colleague of mine asked me about this very 
file because he wanted to understand the metamodel better. Such files 
are often a very helpful way to learn RDF models, e.g. by browsing them 
with an RDF editing tool. Furthermore, the RDF file can serve as 
backbone of a SHACL engine implementation, and we use this very file in 
production in our SHACL engine on a daily basis. So it is receiving 
quite a bit of testing along the way.

FWIW, the general topic had been discussed at length before, see 
https://www.w3.org/2014/data-shapes/track/issues/87

Holger


On 14/12/2016 11:17, Peter F. Patel-Schneider wrote:
> If the spec overrules the Turtle document, then I don't see how the Turtle
> document can be considered to be normative and I don't even see any utility in
> referring to the document at all.
>
> However, I don't think that that is what you are saying.   You appear to be
> saying that if this document contains something like
> sh:Shape rdfs:subClassOf sh:PropertyConstraint .
> then even if this is not stated anywhere in the SHACL document every shape is
> also a property constraint in SHACL and all SHACL processors MUST treat them
> as such, i.e., all SHACL processors MUST signal a syntax error on shapes
> graphs like
>
> se:s1 rdf:type sh:Shape ;
>   sh:targetNode ex:n1 ;
>   sh:class ex:c1 .
>
> However only certain aspects of the Turtle document will have this kind of
> effect.  As you say, rdfs:domain and rdfs:range portions won't do anything.
> How then are they normative?
>
> Further, it is the document itself that is being stated to be normative.  If
> changing namespace prefixes doesn't change anything then it seems to be more
> that the intent is not that the document is normative but that some RDF graph
> has some normative intent.
>
> So:
>
> ISSUE:  The intent and effects of the Turtle document are unclear.
>
>
> peter
>
>
>
>
> On 12/13/2016 04:32 PM, Holger Knublauch wrote:
>> The idea is that the existing TTL file is consistent with what is written in
>> the main spec. If there are errors, I welcome bug reports. If we are unsure,
>> we could add a statement along the lines of "the spec wins if the TTL file
>> contradicts".
>>
>> But overall this TTL file has a similar impact as any other file that may be
>> imported into a shapes graph. So if someone adds a triple that makes
>> sh:PropertyConstraint rdfs:subClassOf sh:Shape, and SHACL is defined to look
>> for all SHACL instances of sh:Shape, then an engine will also treat those
>> property constraints as shapes. SHACL doesn't do RDFS inferencing, so
>> rdfs:domain has no impact unless the shapes graph has RDFS activated (which is
>> outside of SHACL's concern). Changing namespace prefixes has no impact on
>> behavior, changing sh:prefix triples would.
>>
>> Holger
>>
>>
>> On 14/12/2016 9:50, Peter F. Patel-Schneider wrote:
>>> The current version of the SHACL document contains "The Turtle serialization
>>> of the SHACL vocabulary is part of the normative specification. However, the
>>> values of rdfs:label and rdfs:comment in that file are not normative.",
>>> pointing to a Turtle document available on the web.
>>>
>>> In what sense is this document normative?
>>>
>>> Would removing the line "rdfs:subClassOf sh:Constraint ;" from the part of
>>> the document about sh:Shape change anything about SHACL?  Would adding
>>> "sh:PropertyConstraint rdfs:subClassOf sh:Shape." somewhere to the document
>>> change anything about SHACL?  Would removing "rdfs:domain sh:Shape ;" from
>>> the part of the document about sh:property change anything aobut SHACL?
>>> Would changing "owl:" to "rowl:" throughout the document change anything
>>> about SHACL?  Would changing the document in any way change SHACL?
>>>
>>>
>>> Peter F. Patel-Schneider
>>> Nuance Communications
>>>
>>

Received on Wednesday, 14 December 2016 03:16:23 UTC