Re: on the turtle serialization of SHACL

* Simon Spero <sesuncedu@gmail.com> [2016-12-14 15:29-0500]
> It's valid (if redundant) RDF/XML, but it's invalid OWL;  there are
> multiple instances of owl:Ontology in the file, which is forbidden in the
> mapping document because there's no way to tell which axioms are part of
> which ontology.
> 
> There are even repeated declarations of the same ontology, at which point
> even the non-strict parse mode OWLAPI gives up.  This causes protégé and
> other related tools to reject the document  (the turtle encoding parses OK).
> 
> (The RDF to OWL mapping code is 90% spit, 90% bailing wire, 90% duct tape,
> with trace amounts of nutrients).

Bailing wire I can work with but the other two don't provide much
structure.

I see:

   <owl:Ontology rdf:about="http://www.w3.org/ns/prov#">
   <owl:Ontology rdf:about="http://www.w3.org/ns/prov-o#"/>
   <owl:Ontology rdf:about="http://www.w3.org/ns/prov-o-inverses#"/>
   <owl:Ontology rdf:about="http://www.w3.org/ns/prov-aq#"/>
   <owl:Ontology rdf:about="http://www.w3.org/ns/prov-dc#"/>
   <owl:Ontology rdf:about="http://www.w3.org/ns/prov-dictionary#"/>
   <owl:Ontology rdf:about="http://www.w3.org/ns/prov-links#"/>
   <owl:Ontology rdf:about="#">
   The last one should be the same as /prov#, which imports:
        prov-o#, prov-o-inverses#, prov-aq#, prov-dc#,
        prov-dictionary#, prov-links#

Can this be made legal (and thus probably readable with OWL API) by
breaking it back up into a base which may or may not import six
components, each luxuriating in its own file? This would require
a catalog.xml file but I imagine that wouldn't be a problem.

What's this mean?
   <owl:Ontology rdf:about="http://www.w3.org/ns/prov-links#">
      <specializationOf rdf:resource="http://www.w3.org/ns/prov-links"/>
  </owl:Ontology>
Can I get that with and without zero-width terminaing whitespace as well?

Anyways, if you think you know what it ought to look like, I can
probably get permission to create zillions of spurious files in /ns
(I'm very persuasive).


> Simon
> 
> On Dec 14, 2016 2:33 PM, "Eric Prud'hommeaux" <eric@w3.org> wrote:
> 
> * Simon Spero <sesuncedu@gmail.com> [2016-12-14 13:22-0500]
> > 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.
> 
> Is it? The validator [1] doesn't whine about it.
> Perhaps it's not that the RDF/XML is invalid but the data therein is wrong?
> Is this seriously broken or a minor point that won't affect machines or
> people?
> Anyways, W3C staff can fix these things without convening a Working Group
> or Council of Elrond or any such expensive opperation.
> 
> [1] https://www.w3.org/RDF/Validator/rdfval?URI=http%3A%
> 2F%2Fwww.w3.org%2Fns%2Fprov.owl&PARSE=Parse+URI%3A+&TRIPLES_AND_GRAPH=PRINT_
> TRIPLES&FORMAT=PNG_EMBED
> 
> 
> > 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).
> 
> Sob!
> 
> 
> > 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
> > >>>>>>
> > >>>>>
> > >>>
> > >>>
> > >>
> > >
> > >
> 
> --
> -ericP
> 
> office: +1.617.599.3509
> mobile: +33.6.80.80.35.59
> 
> (eric@w3.org)
> Feel free to forward this message to any list for any purpose other than
> email address distribution.
> 
> There are subtle nuances encoded in font variation and clever layout
> which can only be seen by printing this message on high-clay paper.

-- 
-ericP

office: +1.617.599.3509
mobile: +33.6.80.80.35.59

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.

Received on Wednesday, 14 December 2016 21:46:26 UTC