- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Fri, 07 Oct 2011 09:49:08 +0100
- To: public-rdf-dawg-comments@w3.org
David, The following should carry out that task - delete everything and put one instance back. Proceed by a query to check if it's needed. ---------------------- PREFIX : <http://example/> DELETE { :x :p ?x . ?x :foo "a" ; :bar "b" . } WHERE { :x :p ?x . ?x :foo "a" ; :bar "b" . FILTER( isBlank(?x) ) } INSERT DATA { :x :p [ :foo "a" ; :bar "b" ] } ---------------------- Most of the results formats (XML, JSON, TSV) already have a per-result set bNode identifier but it is per-resultset and not the identifier used by the store to identify the bNode internally to the store (if there is a stable one at all). Changing str() would only work if it were the store-wide identifier AND that identifier could be used in a later operation. Some systems do provide this as a non-standard extension and have done since SPARQL 1.0. The RDF-WG has published a revised RDF Abstract Syntax document which is relevant here as it describes bNode skolemization: http://www.w3.org/TR/rdf11-concepts/#section-blank-nodes Andy On 05/10/11 05:26, David Booth wrote: > 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! >
Received on Friday, 7 October 2011 08:49:38 UTC