- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Fri, 20 Jul 2012 18:45:10 +0100
- To: SPARQL Working Group <public-rdf-dawg@w3.org>
-1 SPARQL is defined as CONSTRUCTing RDF graphs. If an implementation wishes to deviate from that, fine - but it is not compliant. SPARQL is defined for sending graphs over the wire - that is all. Andy -------- Original Message -------- Subject: CONSTRUCTing illegal triples should be optional Resent-Date: Fri, 20 Jul 2012 16:19:26 +0000 Resent-From: public-rdf-dawg-comments@w3.org Date: Fri, 20 Jul 2012 12:18:57 -0400 From: David Booth <david@dbooth.org> To: public-rdf-dawg-comments <public-rdf-dawg-comments@w3.org> Regarding this: http://www.w3.org/TR/sparql11-query/#construct [[ If any such instantiation produces a triple containing an unbound variable or an illegal RDF construct, such as a literal in subject or predicate position, then that triple is not included in the output RDF graph. ]] This really bothers me, because: (a) it unnecessarily couples SPARQL to a controversial decision in the RDF WG that may well change in the future, i.e., the prohibition against literals as subjects; and (b) it forces a conforming implementation to perform checks that its user may not want or need. If a user chooses to generate invalid RDF then that is his/her business. The SPARQL spec should not prohibit it. If a particular implementation offers the feature of performing this check, then that is fine. But it is unnecessarily draconian to require all implementations to do it. I suggest changing the above to: [[ If any such instantiation produces a triple containing an unbound variable then that triple MUST NOT be included in the output RDF graph. Otherwise, if any such instantiation produces a triple containing any illegal RDF construct, such as a literal in subject or predicate position, then that triple MAY be excluded from the output RDF graph. ]] -- David Booth, Ph.D. http://dbooth.org/ Opinions expressed herein are those of the author and do not necessarily reflect those of his employer.
Received on Friday, 20 July 2012 17:45:38 UTC