Re: Blank node identifiers in FILTER clauses

(Resent with my old e-mail address since my new one causes mails to be
  held up indefinitely)

Fred Zemke wrote:

> The scope of blank node identifiers is not clearly specified.

Depends on what you mean with 'clear' of course but the beginning of
section 2.8.3 (editor's draft) specifically states that the scope of
blank node identifiers is the BGP.

> However, as I have understood conversations in email and telecon, the
> definition of basic graph pattern E-matching in 2.5.1 "General
> framework" provides the only definition for the semantics of blank
> node identifiers, and therefore the scope of a blank node identifier 
> is a basic graph pattern.  My question is whether the scope can also
> extend into a Constraint in a FilteredBasicGraphPattern.

You are perhaps right that is not sufficiently clearly specified but I
think the intent (as also stated in section 2.5.4) is that the filter
condition(s) are considered, syntactically, a part of the BGP and thus
the scope of the blank node identifiers extends to the filter condition.

[snip example]

> I see four possible resolutions:
> 
> 1. (My preference) the scope of a blank node identifier is an entire
> FilteredBasicGraphPattern, not just a basic graph pattern.  To do
> this, we need to extend the definitions in section 2.5 so that they
> define the solutions of a FilteredBasicGraphPattern rather than just
> the solutions of a basic graph pattern.  I can see how to do this
> with the simple entailment mapping definition; I don't see how to do 
> this with the general E-entailment definition.

I'm not sure we should introduce a new concept for this
('FilteredBasicGraphPattern') but a clearer specification of the role of
the filter condition is a good idea, I agree.

> 2. We prohibit blank node identifiers in FILTER clauses as inherently
> meaningless or deceptive syntax.

I can live with either of these and have a slight preference for the
second. To be honest I could live without the blank nodes in queries
altogether. They are confusing and annoying (this discussion is a case
in point), and I find the supposed 'cut&paste' benefit unconvincing. But
  that station is passed I guess.

> 3. We allow blank node identifiers in FILTER clauses, but they always
> raise an error, so that such FILTERs always fail. But in that case,
> why did we permit the syntax?
> 
> 4. We allow blank node identifiers in FILTER clauses, and they
> reference distinct blank nodes, distinct from all blank nodes in the
> dataset.  Thus _:a = _:b is false, and _:a != _:b is true.

Neither of these sound very good solutions to me.

Jeen
-- 
Jeen Broekstra <jeen.broekstra@aduna-software.com>
Senior Software Developer
Aduna (http://www.aduna-software.com/)
Prinses Julianaplein 14-b, 3817 CS Amersfoort, The Netherlands
tel. +31-(0)33-4659987

Received on Wednesday, 28 June 2006 09:16:29 UTC