- From: David Booth <david@dbooth.org>
- Date: Wed, 05 Oct 2011 00:26:38 -0400
- To: public-rdf-dawg-comments <public-rdf-dawg-comments@w3.org>
http://www.w3.org/TR/sparql11-query/#func-str The str() function is currently defined to accept only a literal or an IRI -- not a bnode. Is there a compelling reason why not? I think this is a problem because AFAICT it is currently impossible to impose an ordering on bnodes, since the "<" operator also does not compare IRIs or bnodes. I think the str() function should also accept a bnode argument and return a lexical form of that bnode that is unique to the result set. This would allow one to write a query that distinguishes the "first" bnode from others (where the choice of first is arbitrary, but holds within the query), thus allowing that query to (for example) delete all "non-first" bnode objects. For example, consider the following RDF: :x :p [ :foo "a" ; :bar "b" ] . When it is read in repeatedly to a graph, each time it is read in an additional bnode will be created, thus leading to multiple (redundant) statements in the graph, each having a *different* bnode: :x :p _:b1 . _:b1 :foo "a" ; :bar "b" . :x :p _:b2 . _:b2 :foo "a" ; :bar "b" . :x :p _:b3 . _:b3 :foo "a" ; :bar "b" . . . . I.e., the graph becomes increasingly non-lean. It would be nice to be able to write a simple DELETE query to get rid of these extra bnode objects, but without the ability to impose an arbitrary ordering on them in the query, I do not see an easy way to distinguish one bnode object from all the others and delete only "all the others". In the case where there is a known, fixed number of predicates in the bnode object then I could use a nested SELECT DISTINCT, but I want to be able to write the query more generally, where the set of predicates is not fixed (though the depth of the bnode object would be fixed, to avoid getting into the general problem of making graphs lean). There are probably other use cases that would also benefit from the ability to impose an ordering on bnodes -- just as it is useful to be able to impose an ordering on other entities -- but this is the case that happened to motivate me to send in this suggestion. I assume that this suggestion is too late for consideration in SPARQL 1.1, but if it could be added to a wish list for future consideration I would appreciate it. Thanks! -- 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 Wednesday, 5 October 2011 04:27:03 UTC