First RDF Data Access Working Group Face-to-Face Meeting

Leiden, Netherlands, 22-23 april 2004

The main goal of this first face-to-face meeting was to discuss the use cases and requirements that will compose the first working group document (RDF Data Access Use Cases and Requirements) and to explore existing technologies in the light of these requirements.

Use Cases

Different use cases already proposed (either to the mailing list or during audio conferences) have been further discussed. Finally, the group voted for their "top 5" use cases. The results were:

• Finding an email address
• Finding information about motorcycle parts
• Finding unknown titles (media)
• Monitoring news events
• Avoiding traffic jams

Requirements

In order to be able to solve the above problems, the following requirements have been adopted:

• Queries with optional triples
• Queries supporting comparison of numbers and dates
• Queries expressible as URLs.
• Queries serializable as text.
• Query results as a sub-graph of the queried RDF graph
• Queries for the non-existence of triples in a graph.
• Queries expressible in a human-friendly syntax.
• Queries independent of any network protocol.
• Query results can be returned as 0 or more variable bindings .
• Query results may return source/provenance.
• The language shall be extendable (function calls, namespaces).
• The query protocol shall address bandwidth issues.
• The query language supports limiting the number of results.

Technologies

Bryan Thompson presented how to use XPointer and HTTP "range" header as a RDF Data Access protocol. Howard Katz and Rob Shearer presented the XQuery language. None of these solutions fully answered the above requirements.

More complete minutes of this meeting are available at the following URL: http://www.w3.org/2001/sw/DataAccess/ftf1#min

Afterword

The method adopted (draw requirements from optimistic use cases) can lead to incompatible requirements. On the other hand, it may be positive to have as ambitious requirements as possible before restricting our wishes.

It appears now that some requirements were incompatible (as we have shown, by example, in the last Knowledge Web meeting). The language actually developed by the working group, SPARQL, dropped some of the above requirements (negation, datatypes). Bandwidth issues are still being studied.