[gk@ninebynine.org: http://www.w3.org/TR/2004/WD-rdf-dawg-uc-20040602/]

Some interesting comments from  Graham.

Kendall
----- Forwarded message from Graham Klyne <gk@ninebynine.org> -----

To: public-rdf-dawg-comments@w3.org
From: Graham Klyne <gk@ninebynine.org>
Subject: http://www.w3.org/TR/2004/WD-rdf-dawg-uc-20040602/

I like the way this document is presented.

Some thoughts about some of the pending issues.  I agree with all the 
points marked "ACCEPTED" (though I'd suggest that the level of XSD Datatype 
testing support required of any implementation be kept as small as 
reasonably possible).

...

[[
3.6 Optional Match

It must be possible to express a query that does not fail when some 
specified part of the query fails to match. Any such triples matched by 
this optional part, or variable bindings caused by this optional part, can 
be returned in the results, if requested.

Status: Pending.
3.6 Optional Match (variant)

It must be possible to express a query with optional parts such that the 
query does not fail to match when one or more optional parts of the query 
fails to match. Any such triples matched by this optional part, or variable 
bindings caused by this optional part, can be returned in the results, if 
requested.

Status: Pending.
]]

In one of my own query implementations, this is a feature that I have found 
to be very useful.  I have an application that uses query to drive the 
generation of reports and non-RDF data from RDF input, and I found the 
introduction of optional (and alternative) query sections made the system 
much easier to use.  I return results as variable bindings, and the 
optional sections (may) simply result in additional variables being 
bound.  The calling program makes considerable use of the existence or not 
of a variable binding in response to a given query.

...

[[
3.8 Bookmarkable Queries

It must be possible to express a query as a URI. The result of 
dereferencing the resource identified by this URI will be a representation 
of the query results. This form of the query is not assumed to be humanly 
readable. This requirement does not preclude other mechanisms for issuing 
queries.

Status: Pending.
]]

It seems to me that this is an orthogonal issue.  Given a protocol it 
should be possible to construct a URI to represent it.  (BTW, a few months 
ago, I had some experience with long URIs -- over 4K. or maybe 8K -- 
causing a popular web browser to fall over.)

...

[[
3.10 Result Limits

It must be possible to to specify an upper bound on the number of query 
results returned.

Status: Pending.

3.10a Iterative Query (variant)

It must be possible to handle large result sets of any size by iterating 
over the result set and fetching it in chunks.

Status: Pending.
]]

Maybe this should be an application-specific issue?  I think it might be 
useful to have a common way to indicate that not all possible results were 
returned (which I think is a smaller problem).

If you've going to take partial results seriously, then it may also be a 
requirement to indicate how the results should be ordered?

My feeling is that there's a can-of-worms here, and that providing suitable 
hooks for extensibility may be better than trying to devise a solution to 
these issues.

...

[[
4.1 Human-friendly Syntax

There must be a text-based form of the query language which can be read and 
written by users of the language.

Status: Pending.
]]

In practical terms, I think this will be important.  Less clear is whether 
it needs to be standardized.  Maybe start with a NOTE covering a proposed 
human-friendly format, which can maybe later advance to REC if it's 
sufficiently useful?

...

[[
4.2 Provenance

It should be possible for query results to include source or provenance 
information.

Status: Pending.
]]

Could this be covered by extensibility hooks?

...

[[
4.3 Non-existent Triples

It should be possible to query for the non-existence of one or more triples 
or triple patterns.

Status: Pending.
]]

Isn't this just a variation on result limits?

...

[[
4.4 User-specifiable Serialization

It should be possible to specify the serialization format of query results; 
this design objective is meant to be orthogonal to the semantics of query 
results, whether subgraph, variable bindings, or some other type.

Status: Pending.
]]

This looks like a possibility for unhelpful scope creep.  I'm not sure 
about variable binding and subgraph results -- I understand there may be 
significant semantic difference but I'm not sure what -- but I don't think 
syntaxes should be proliferated.  If the data model is clear, private 
applications may choose to use a different syntax locally (like many people 
using N3).

...

[[
4.5 Aggregate Query

It should be possible to specify two or more RDF graphs against which a 
query shall be executed; that is, the result of an aggregate query is the 
merge of the results of executing the query on each of two or more graphs.

Status: Pending.
4.6 Additional Semantic Information

It should be possible for knowledge encoded in other semantic languages—for 
example: RDFS, OWL, and SWRL—to affect the results of queries executed 
against RDF graphs.
4.6a Additional Semantic Information (variant)

It should be possible for a query to indicate that the answers should take 
into account knowledge encoded in RDF semantic extensions such as RDFS, 
OWL, etc.
]]

These look like issues that should be addressed orthogonally from the basic 
query+access.

Essentially, it seems to come down to specifying the graph that is being 
queried, which I'd expect to be just a URI.  If standard aggregation 
mechanisms are required later, then I could imagine standard forms of URI 
construction might be introduced.

...

#g


------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact


----- End forwarded message -----

Received on Friday, 4 June 2004 09:29:18 UTC