- From: David Booth <david@dbooth.org>
- Date: Tue, 31 Jul 2012 13:00:05 -0400
- To: Andy Seaborne <andy.seaborne@epimorphics.com>
- Cc: public-rdf-dawg-comments <public-rdf-dawg-comments@w3.org>
Hi Andy, Thanks for your response. I am not satisfied with this resolution. I see no harm that would be created by the simple wording change that I proposed -- NO implementation would have to change -- and I do see harm in the current wording. This is similar to many other situations in which the specification should not force an implementation to perform strict validity checking that the user may not want or need, such as ensuring that all dynamically generated URIs are strictly conforming, all dates are valid, etc. Strict validity checking is definitely a nice optional value-add for implementations that choose to provide it, when users want it. But the specification (rightly) does not force every implementation to perform strict validity checking, and shouldn't in this case either. The SPARQL spec cannot standardize exactly what should be output if the user CONSTRUCTs a triple having a literal as subject, but it doesn't need to: the result can be implementation defined, just as it is in other situations in which the user does something illegal. This has been a standard approach in programming language design for decades: if the user *chooses* to do something illegal, then the results are implementation defined. David On Tue, 2012-07-31 at 09:06 +0100, Andy Seaborne wrote: > David, > > Thank you for your comment about CONSTRUCT. > > SPARQL is defined to work with RDF and CONSTRUCT defined to create RDF > graphs by receiving an HTTP-carried request and returning the results > using one of the RDF concrete syntaxes. The SPARQL specification does > not say anything about API use. It is not in the charter of the working > group to define a new data framework going beyond RDF. SPARQL builds on > the work of the RDF working group. > > If an implementation wishes to go beyond the specification in some way, > such as allowing API use to create other forms of triples, it is at > liberty to do so, accepting responsibility for interoperability issues > this raises. Interoperability is an important aspect for a web system. > > The working group is not planning to make any changes in this area. > > I would be grateful if you reply to this message to confirm that the > working group has responded to your comment. > > Yours, on behalf of the SPARQL Working Group, > > Andy > > > On 20/07/12 17:18, David Booth wrote: > > 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 Tuesday, 31 July 2012 17:00:38 UTC