- 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:05:16 UTC