- From: Simon Spero <sesuncedu@gmail.com>
- Date: Wed, 14 Dec 2016 17:16:57 -0500
- To: David Booth <david@dbooth.org>
- Cc: public-rdf-shapes@w3.org
- Message-ID: <CADE8KM48wuqQw-Rg3NUVoDtksVVEUK03DGRF9EAmgaK+FkJEUA@mail.gmail.com>
That's not the problem; the problem is the non-duplicates. See: https://www.w3.org/TR/owl2-mapping-to-rdf/#Parsing_of_the_Ontology_Header_and_Declarations It would theoretically be possible to extend things to handle multiple ontologies in a single file using RDF 1.1 multi graph serializations like TRIG, but since that's putting lipstick on a pig, when it's not even their colour. Then again, it was also theoretically possible to not end up with rdf:PlainLiteral *and* rdf:langString. Also, it was theoretically possible to charter a new WG to agree on the various choices that RDF 1.1 + OWL raised. Sigh. BTW, there's a useful example of the importance of distinguishing between normative and informational parts of a specification in the PlainLiteral document. The document defines a langRange facet, and specifies that extended matching is used; however the example given uses basic matching. Because the example is non-normative, this error does not create ambiguity. Indeed, the example have been replaced by a picture of a sad kitten with the same effect. Simon On Dec 14, 2016 4:09 PM, "David Booth" <david@dbooth.org> wrote: On 12/14/2016 03:29 PM, Simon Spero wrote: > 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). > If the protégé parser rejects the document because of duplicate triples then that is a bug in the parser, because it is not possible for an RDF graph to have duplicate triples: https://www.w3.org/TR/rdf11-concepts/#section-rdf-graph "An RDF graph is a set of RDF triples." David Booth > (The RDF to OWL mapping code is 90% spit, 90% bailing wire, 90% duct > tape, with trace amounts of nutrients). > > Simon > > On Dec 14, 2016 2:33 PM, "Eric Prud'hommeaux" <eric@w3.org > <mailto:eric@w3.org>> wrote: > > * Simon Spero <sesuncedu@gmail.com <mailto:sesuncedu@gmail.com>> > > [2016-12-14 13:22-0500] > > This was/is an issue with XML DTDs. > > > > Incidentally, PROV ns files on w3.org <http://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 > <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 <mailto: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 <mailto: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/376aeaac562bf82494 > 3a383904728a > <https://github.com/w3c/data-shapes/commit/376aeaac562bf8249 > 43a383904728a> > > 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 > <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 <tel:%2B1.617.599.3509> > mobile: +33.6.80.80.35.59 <tel:%2B33.6.80.80.35.59> > > (eric@w3.org <mailto: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 22:17:31 UTC