str() function should also accept blank node argument

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