- From: Enrico Franconi <franconi@inf.unibz.it>
- Date: Thu, 29 Dec 2005 17:04:53 +0100
- To: RDF Data Access Working Group <public-rdf-dawg@w3.org>, public-swbp-wg@w3.org
- Cc: David Wood <dwood@softwarememetics.com>, Brian McBride <brian.mcbride@hp.com>
> From: Dan Connolly <connolly@w3.org>
> Date: 29 December 2005 15:25:43 GMT+01:00
> To: RDF Data Access Working Group <public-rdf-dawg@w3.org>
>
> On Tue, 2005-12-27 at 19:37 +0100, Enrico Franconi wrote:
>> b) we want back the ability to label bnodes in a query as
>> "told-bnodes", in order to allow, e.g., for the use case
>> "Publishing on the Web" in
>> <http://lists.w3.org/Archives/Public/public-rdf-dawg/2005JulSep/
>> 0430>;
>> also in the SWBP WG there are several requests to allow
>> for this, for example
>> <http://lists.w3.org/Archives/Public/public-swbp-wg/2005Nov/0176>.
>
> As we (re)discovered in the teleconference, the WG discussed
> a relevant issue, bnodeRef, at some length...
> http://www.w3.org/2001/sw/DataAccess/issues#bnodeRef
>
> and decided, 2005-07-12, to postpone it.
>
> In all the discussion of it that I have seen recently, the
> designs go out of scope (by introducing yet another sort
> of term beyond literals, URIs, bnodes, and ?variables
> at the abstract syntax level) without a clear requirement
> nor a compelling use case. The "Publishing on the Web"
> use case does not have a critical mass of support.
>
> We'll need new information in order to re-open bnodeRef
> and consider designs.
Aren't you happy of the lengthy discussion in the SWBP WG I was
mentioning?
I believe these are compelling cases from the real users community,
and that they are enough to support the addition of an optional
"told" keyword for each bnode in a query (or of an optional unique
"told" keyword in a query, listing all the told bnodes).
I paste the latest summary message from the SWPB WG below
<http://lists.w3.org/Archives/Public/public-swbp-wg/2005Nov/0035>:
On 5 Nov 2005, at 17:29, David Wood wrote:
> Hi all,
>
> This message contains comments on SPARQL [1] problems with blank
> nodes which specifically impact SWBP work. It is in continuation
> of the action item at [2].
>
> I wrote in [3] regarding blank nodes:
>
> On Oct 14, 2005, at 14:31, David Wood wrote:
>> 3) The handling of blank nodes ("bnodes") is, again in my
>> opinion, the single greatest failure of the specification. We
>> have to admit that RDF graphs contain bnodes and queries will run
>> across them. We also have to admit that a querier will (not
>> 'may') often want to subsequently find information connected to
>> those bnodes. SPARQL's insistence that bnodes' true internal
>> identities not be returned to a querier (correct in and of itself)
>> combined with the lack of subquery capability ensures that many
>> useful RDF queries routinely performed in other languages simply
>> cannot be written in SPARQL. OPTIONAL addresses only part of that
>> functionality.
>
> There are at several places where the need to query across blank
> nodes pop up in SWBP work. Some of them are:
>
> - SKOS Core
> - RDF/A
> - N-ary Relations
>
> The SKOS Core Guide [4] includes an example where a blank node is
> used to represent a collection. How, using SPARQL, could one
> construct a query which asks, to use the example collection in the
> Guide, for the rdfs:labels of any collections which includes a
> skos:member ex:buffalomilk?
>
> The RDF-in-XHTML TF has been wrestling [5] with a use case
> requiring the definition of properties referencing blank nodes. The
> RDF/A Syntax [6] uses the CURIE proposal [7] to generate blank
> nodes. Therefore, I make the case that since they are producing
> graphs inclusive of blank nodes, SPARQL should be able to make
> queries regarding those properties indirectly (e.g. "give me all
> docs/elements which have things which have property x" and more
> complex variations on that theme). Ralph has commented privately
> that he considers that important.
>
> Nokia's comments to SPARQL ([8] and [9]) suggest that they consider
> support for transitive closure to be important, which is another
> way of addressing the same issue.
>
> The N-ary Relations draft's Use Case 3: N-ary relation with no
> distinguished participant [10] uses an "aggregating node" and
> assigns it an explicit URI. John Madden from Duke University has
> made the (correct, IMHO) suggestion [11] that the aggregating node
> should be a blank node. In that case, he goes on to raise issues
> regarding the applicability of OWL DL and comments, "In the
> examples given, it strikes me as pretty likely that the aggregating
> node would be a juicy target to be the object of other triples."
> John seems to be thinking along lines similar to Ralph, Nokia and
> myself.
>
> Therefore, I contend that sufficient need for querying across blank
> nodes (whether by transitive closure or another mechanism, such as
> subqueries) exists within the body of SWBP work and propose that
> the working group take such a position with the DAWG regarding the
> lack of such support in SPARQL.
>
> [1] http://www.w3.org/TR/rdf-sparql-query/
> [2] http://www.w3.org/2005/10/03-swbp-minutes.html#action17
> [3] http://lists.w3.org/Archives/Public/public-swbp-wg/2005Oct/
> 0107.html
> [4] http://www.w3.org/TR/2005/WD-swbp-skos-core-guide-20050510/
> [5] http://www.w3.org/2005/04/05-swbp-minutes.html
> [6] http://www.w3.org/2001/sw/BestPractices/HTML/2005-rdfa-
> syntax#id87921
> [7] http://www.w3.org/2001/sw/BestPractices/HTML/2005-10-21-curie
> [8] http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/
> 2005Sep/0007.html
> [9] http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/
> 2005Sep/0023.html
> [10] http://smi-web.stanford.edu/people/noy/nAryRelations/n-
> aryRelations-2nd-WD.html
> [11] http://lists.w3.org/Archives/Public/public-swbp-wg/2005Jul/
> 0017.html
>
> Regards,
> Dave
Received on Thursday, 29 December 2005 16:12:01 UTC