- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Mon, 21 Aug 2006 17:34:23 +0100
- To: Fred Zemke <fred.zemke@oracle.com>
- CC: public-rdf-dawg@w3.org
Fred Zemke wrote: > For your consideration, > the attached paper presents a formal semantics for SPARQL > that is based on mapping rather than entailment. > > Fred I was a bit confused by the 'bindable' terminology - am I right in reading you your document as saying that blank nodes, in queries, are not be bound to a graph term, as their existential. Test case: Data: :x :p 1 . :y :p 1 . Query: SELECT ?x { [] :p ?x } has one solution ?x/1 doesn't it (and implementation terms it is much like the same with blank node treated as regular variables then a partial term-distinct being applied over the BGP match ; it's implementing this partial-distinct that worries me if we care about a moderately direct 1-1 mapping to some form of SQL). What do you expect from this example (I know we are not that we are covering aggregation but I'm interested in your view): Data: as above Query: SELECT sum(?x) { [] :p ?x } Is it 1 or 2? This example shows me that treating blank nodes as pure existentials, when the entailment regime can provide bindings, will given counter-intuitive results, especially where the graph pattern though of as a "graph with holes" (making blank nodes as in unlabelled nodes of the RDF syntax) quite naturally bindings. On the spanning blank nodes, we could remove the problem by requiring labels do not span BGPs. Then blank node labels can't appear in two different BGPs. Alternatively, no blank nodes with labels at all and have "??x" - if we want existential variables, maybe an explicit syntax for them such as ??x (double question mark) might be better. It's only the use of [] from N3/Turtle that complicates this. It's the syntax issue about [] that introduced them - it would be a shame to loose that convenience form when it has a reasonable meaning for the problem space covered by the charter. An extreme approach would be to make [] translate to named variables, just the system gets to choose the names so they don't clash with any named variables and don't appear in "SELECT *" Andy
Received on Monday, 21 August 2006 16:35:58 UTC