W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > June 2004

On Requirement 3.6 (Optional Match)

From: <massimo@w3.org>
Date: Wed, 23 Jun 2004 16:47:23 -0400 (EDT)
Message-ID: <3607.>
To: public-rdf-dawg-comments@w3.org
Cc: massimo@w3.org

DanC asked me to post the following to the DAWG wg,
as this was so far only part of the internal W3C team

This regards requirement 3.6 "optional match"
(http://www.w3.org/TR/2004/WD-rdf-dawg-uc-20040602/#r3.6 ).
In order to have an appropriate judgment on this
requirement, some clarifications would be needed,
so to know more precisely what the meaning of
the requirement (and its possible future impact) is.

An example DanC sent is the one from the Algae documentation:
Example 6: query with optional terms (extends Example 2: query with
multiple terms)

ns vcard=<http://www.w3.org/2001/vcard-rdf/3.0#>
ask (?vcard  vcard:FN "John Smith" .
     ?vcard  vcard:N  ?name .
     ?name   vcard:Family  ?family .
     ?name   vcard:Given  ?given .
     ~?vcard foaf:mbox ?mbox .
     ~?vcard foaf:mbox_sha1sum ?sum)
A particular vcard entry may or may not have FOAF [4] data attached.

This query will retrieve two FOAF properties if present, but will still
return vcard entries without this vcard information.

Likely meaning: optional queries are to obtain *optional bindings*, and
not as a filtering tool (at least, that's my guess).

Point is, what does one do with these "optional bindings" then?
How are they treated? In case of a compositional semantics,
for instance, this forces a two-valued interpretation fork
(existent data / nonexistent data), similar to the NULL state
in databases and other prog languages.
So anyway, this would have to be specified, because what is
apparently simplified with the "optional binding" part
(no need for explicit test guarding) might come back with a
higher price in terms of complication of the language to
handle in every expression this extra state (nonexistent data).
If this gets too complex, and one is to re-introduce
explicit handling of the NULL values, then optional
queries might just go away.

So, apart from a single example of optional bindings (like
the Algae one), how are these "potentially nonexistent data"
planned to be treated in the language? Can anybody provide
more data/examples/design ideas?

Note I'm not expressing a judgement on optional match,
just trying to better figure out what the proposed requirement
is, so to evaluate the pro/con and be able to express a proper judgment.

Received on Wednesday, 23 June 2004 16:47:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:05 UTC