Re: on the turtle serialization of SHACL

This was/is an issue with XML DTDs.

Incidentally, PROV ns files on w3.org  present an interesting case, as the
rdf/xml "file",   http://www.w3.org/ns/prov.owl , is invalid, and rdf/xml
is the only required OWL encoding.

It is thus *un*informative.  This contrasts with an apparently normative
rdfs or owl vocabulary document for a  specification which in fact defines
a different semantic to one defined in the text, in which case the
vocabulary document becomes *dis*informative (how very 2016).



On Dec 14, 2016 12:00 PM, "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
wrote:

Good to know.

I seem to remember that there were problems with W3C hosting such documents
for RDF because of the web traffic that they created.

peter


On 12/14/2016 08:49 AM, David Price wrote:
> On 14 Dec 2016, at 15:47, Peter F. Patel-Schneider <pfpschneider@gmail.com>
wrote:
>>
>>
>>
>> On 12/13/2016 07:15 PM, Holger Knublauch wrote:
>>> 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.
>>
>> Has W3C committed to hosting this document?  Has the W3C team been asked
to
>> determine whether W3C is doing this sort of thing at all?
>
> The W3 hosts Turtle files for all it’s ontology standards, for example
here’s Prov-O:
>
>> Abstract
>>
>> The PROV Ontology (PROV-O) expresses the PROV Data Model [PROV-DM] using
the OWL2 Web Ontology Language (OWL2) [OWL2-OVERVIEW]. It provides a set of
classes, properties, and restrictions that can be used to represent and
interchange provenance information generated in different systems and under
different contexts. It can also be specialized to create new classes and
properties to model provenance information for different applications and
domains. The PROV Document Overview describes the overall state of PROV,
and should be read before other PROV documents.
>>
>> The namespace for all PROV-O terms is http://www.w3.org/ns/prov#.
>>
>> The OWL encoding of the PROV Ontology is available *here*.
>>
>
>
> and the “here” links to a downloadble Turtle file. So, this requirement
is common in the W3C - not a problem at all :-)
>
> Cheers,
> David
>
>
>
>
>>
>>> Whether the word "normative" is the right term I
>>> cannot say,
>>
>> Someone in the working group should determine whether "normative" is the
right
>> term.
>>
>>> so I have avoided this term for now:
>>>
>>> https://github.com/w3c/data-shapes/commit/376aeaac562bf824943a383904728a
06f19f88c6
>>
>> Has the working group signed of on this substantive change to SHACL?
>>
>>> 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 don't think that this is the case.  Even if this document is not
imported,
>> it was a normative document so whatever it says was part of SHACL.  So
if this
>> document contains sh:Shape rdfs:subClassOf sh:PropertyConstraint then it
>> saying that throughout SHACL there is always a subclass relationship from
>> shapes to property constraints so all shapes were property constraints
in SHACL.
>>
>>> 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.
>>
>> Yes, I can see that an RDF document about the SHACL vocabulary can have
>> tutorial utility.  However then the document has to reflect the actual
>> situation with respect to the SHACL vocabulary.  This does not appear to
be
>> the case.  There are lots of occurrences of rdfs:domain and rdfs:range
in the
>> document.  As SHACL doesn't do RDFS reasoning these are only creating
false
>> impressions.
>>
>> As far as SHACL implementations depending on a document served by W3C, I
think
>> that the W3C team should sign off on that.
>>
>>>
>>> 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
>>>>>>
>>>>>
>>>
>>>
>>
>
>