Fwd: Re: str() function should also accept blank node argument

The issue seems to be disagreement with what the WG has decided, not on 
whether we have answered the comment.

We can raise-and-postpone an issue.

I disagree with saying SPARQL does not have the same support for bNodes 
as other terms.  They are different so they behave differently.

The fact STR() works on literals and URIs is because there are two STR 
functions, with different signatures.  STR access the lexical form of 
literals, the IRI string for IRIs; RDF does not define a string for bNodes.

 Andy

-------- Original Message --------
Subject: Re: str() function should also accept blank node argument
Date: Wed, 02 Nov 2011 09:50:18 -0400
From: David Booth <david@dbooth.org>
To: Andy Seaborne <andy.seaborne@epimorphics.com>
CC: public-rdf-dawg-comments@w3.org

Hi Andy,

I only partly agree.  I do agree that there are work-arounds available,
and one such work-around is to avoid the use of bnodes by skolemizing
them on input, as you suggest.

But it seems to me that if SPARQL is going to support bnodes, then it
should support them just as it supports all other kinds of terms.  If
SPARQL is *not* giving the same support to bnodes as it gives to all
other terms, and the WG is encouraging users to avoid them and use
skolemization instead, then in essence SPARQL has deprecated this
feature of the language.  And as much as I dislike bnodes, I don't think
we're ready to take that step.

I appreciate the WG's time constraints and I would be okay with a WG
decision to defer this to the next SPARQL release if the WG felt it
would cause too much delay to address it now, but I do not agree that
this functionality is not needed.  Bnodes should have the same level of
support in SPARQL that all other RDF terms have.

Thanks,
David


On Wed, 2011-11-02 at 10:58 +0000, Andy Seaborne wrote:
> David,
>
>  > The RDF-WG's progress on skolomization is welcome complementary
>  > progress, but this inability to apply the str() function to a bnode is
>  > still a gap in SPARQL that should be addressed.  If it cannot be
>  > addressed now (due to time constraints) I think it should go on an
>  > issues list to be addressed in the next version.
>
> The skolemization work by the RDF Working Group would address your use
> case because it provides both an external identification of the blank
> node (considered as an item of RDF abstract syntax) and as a way to use
> identification found in a query and then used in update operations.
>
> Since a general mechanism is defined by the RDF specifications, this
> should be used and not rely on a feature unique to SPARQL.
>
> A number of SPARQL implementations do already provide, as extensions,
> protoype implementations of the skolemization feature. Even if the
> details differ at this stage, it suggests that take up of this RDF
> feature will happen.
>
> The timescales of SPARQL-WG and RDF-WG are not aligned and the SPARQL
> Working Group does not want a dependency on the skolemization work of
> RDF-WG. Therefore the SPARQL Working Group has decided not to make
> changes to the STR() or IRI() functions.
>
> We would be grateful if you would acknowledge that your comment has been
> answered by sending a reply to this mailing list.
>
> Andy, On behalf of the SPARQL WG
>
>
> On 18/10/11 22:08, David Booth wrote:
> > Andy,
> >
> > That solution works only for fixed values of :foo and :bar.  And moving
> > the INSERT into the same statement as the DELETE won't work either,
> > because that would cause duplicate bnodes to be reinserted:
> >
> >> PREFIX :<http://example/>
> >>
> >> DELETE { :x :p ?x .
> >>            ?x :foo ?a ; :bar ?b . }
> >> INSERT DATA { :x :p [ :foo ?a ; :bar  ?b ] }
> >> WHERE { :x :p ?x .
> >>           ?x :foo ?a ;
> >>              :bar ?b .
> >>           FILTER( isBlank(?x) )
> >>         }
> >>
> >
> > But this is only one use case that I happened to run into.  I'm sure
> > there are others.  IMO, as a general principle of language design,
> > *every* value that can be generated should be able to be turned into a
> > string and compared.
> >
> > I agree that it would be ideal if the str() function would return a
> > string that is unique to the store rather than merely being unique to
> > the solution set, so please amend my request in this way.  :)  I had
> > suggested making it unique to the solution set only because I was
> > concerned that there might be resistance to store-wide values for
> > implementations that already return bnode serializations that are only
> > unique within a solution set.
> >
> > The RDF-WG's progress on skolomization is welcome complementary
> > progress, but this inability to apply the str() function to a bnode is
> > still a gap in SPARQL that should be addressed.  If it cannot be
> > addressed now (due to time constraints) I think it should go on an
> > issues list to be addressed in the next version.
> >
> > Thanks,
> > David
> >
> >
> >> From: Andy Seaborne<andy.seaborne@epimorphics.com>
> >> Date: Fri, 07 Oct 2011 09:49:08 +0100
> >> Message-ID:<4E8EBD04.1040603@epimorphics.com>
> >> 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!
> >>>
> >>
>
>

-- 
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, 2 November 2011 14:34:30 UTC