Re: Constructive mapping semantics for SPARQL

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