W3C home > Mailing lists > Public > www-rdf-interest@w3.org > November 2003

Re: Semantic Web Phase 2 Activity - Protocol - Query Language

From: Damian Steer <pldms@mac.com>
Date: Thu, 13 Nov 2003 14:49:55 +0000
To: Jeen Broekstra <jeen@aduna.biz>
Cc: "Seaborne, Andy" <Andy_Seaborne@hplb.hpl.hp.com>, 'Steve Harris' <S.W.Harris@ecs.soton.ac.uk>, www-rdf-interest@w3.org, sesame-devel@lists.sourceforge.net
Message-ID: <m23ccss4q4.fsf@evila.danbri.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Asleep at the keyboard here. I had the same issue in my extension
of squish (called esquish [1]) for rubyrdf. It started with optionals (to
make my life easy) then I began adding wackier things...

Jeen Broekstra <jeen@aduna.biz> writes:

> [Cc also sent to sesame-devel, since we discussed this problem there
>   today]
>
> Seaborne, Andy wrote:
>
>> Hi there - I have an example query with optional triples and I wondered what
>> the various systems do with it:
>> Thanks to Jeremy Carroll for this example.
>> Consider the data:
>> <x> <p> <y> .
>> <x> <q> <z> .
>> and the query:
>> [ <x> <p> ?a ]
>> [ <x> <q> ?a ]
>> where [] is an optional match.
>> ?? Does the query match the data?
>
> I have earlier sent a reply on this to Andy alone, on how SeRQL
> currently handles it, but I've spent some time thinking about this and
> discussed it on the sesame-devel list a bit further.
>
> I think the example query is ill-defined: regardless of the actual
> dataset being queried it is not possible to assign an unambiguous
> semantics to it. The problem is that a variable is shared across
> several optional path matches, neither of which definitely assign the
> variable a value.
>
>> ?? What does it return?
>
> I'm heavily leaning towards saying that the query engine should return
> a "malformed query" error.
>
> In the discussion on sesame-devel, Jacco van Ossenbruggen came up with
> a constraint on optional path expressions: reuse of a variable across
> optional paths is allowed if and only if the variable is also used in
> a non-optional path in the same query. This disambiguates the use of
> the shared variable in optionals, since optional paths will no longer
> have to instantiate the shared variable, they will only have to
> validate the current instantiation.

Yes. That was my conclusion to the issue - essentially 'sanity
checking'. It doesn't seem unreasonable.

I should add that I did consider returning graphs rather than variable
bindings, which has the virtue that the results are
unambiguous. However this, in my case, was essentially useless as I
was trying to retrieve information from a graph, and returning a graph
seemed a little perverse.

Damian

[1] <http://rdfweb.org/people/damian/esquish/>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iD8DBQE/s5oSAyLCB+mTtykRAsn9AJ9S6A+e9YllXmdQEdv+QGczNeM2XACg1lpr
YkNpV4D2hgEahYVyqmu5lac=
=Xy8r
-----END PGP SIGNATURE-----
Received on Thursday, 13 November 2003 11:08:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:52:03 GMT