RE: Unbound vars as blank nodes

> -----Original Message-----
> From: Seaborne, Andy [mailto:andy.seaborne@hp.com]
> Sent: Wednesday, March 23, 2005 9:30 AM
> To: Geoff Chappell
> Cc: public-rdf-dawg-comments@w3.org
> Subject: Re: Unbound vars as blank nodes
> 
> 
> A nearby issue arises for:
> 
>      ?v < 3 .
>      ?x :p ?v .
> 
> SQL has a clear syntactic distinction but it forces more separation than
> necessary and does not address:
> 
>      ?v math:lessThan 3 .
>      ?x :p ?v .
> 
> (I'm ignoring the subjects-as-literals issue).
> 
> It is obvious what the application intended but a system can't naively
> ignore order.

That mostly seems like an implementation issue - not something that affects
the semantics of the language. Probably the most the language specification
has to say is something like -- a constraint is invalid if it mentions a
variable not mentioned in at least one triple pattern within the same
logical factor when the query has been transformed into sum of products form
(in effect recognizing that constraints are always filters, never generators
of values). Of course that's not to say a processor has to convert to sop
form to execute the query.


On the issue of separation of triple patterns and constraints in general....
I think there are pros and cons to separating the triple patterns from the
constraints as that sparql does.

On the pro side:

- works well in a federated model; you can't push down the whole query to a
federated source and ask for results because some of the info necessary to
answer the query may come from other sources -- best you can do is query the
federated source with a disjunction of single triple patterns. You can
however push down the whole constraint clause as a hint because nothing you
learn from another source can change the meaning of the constraint (assuming
no aggregate constraints exist).

- Allows for a functional evaluation of constraints (a la xquery). This is a
plus for those familiar with xquery and not familiar with lp-style
programming.


On the con side:

- Somewhat harder to push a constraint down as a condition of a triple query
(e.g. to use an index lookup into a triple store based upon a comparison)
because of the impedence mismatch between the lp-style of the triple
patterns and the functional style of constraint evaluation. This is just an
optimization issue, though. Implementors may have to work a bit harder to
get good performance on large stores, but...

- The mixture of lp-style and functional style in the same language may be
confusing to some.

- Might make it harder to evolve sparql in some directions. For example,
what happens if variable assignments are allowed - does that break the
model?


-Geoff

Received on Friday, 25 March 2005 13:12:36 UTC