-
- -$Id: UseCases.html,v 1.39 2004/05/04 14:40:50 kclark Exp $ +$Id: UseCases.html,v 1.40 2004/05/10 16:24:19 kclark Exp $
The W3C's Semantic Web Activity RDF is based on RDF's flexibility as a - means of representing data. While there are several standards covering RDF - itself, there has not yet been work done to create standards for accessing - RDF data. There is no formal, publicly standardized language for querying RDF - information. Likewise, there is no formal, publicly standardized data access - protocol for interacting with RDF storage servers, whether remote or - local.
+The W3C's Semantic Web Activity is based on RDF's flexibility as a means + of representing data. While there are several standards covering RDF itself, + there has not yet been any work done to create standards for querying or + accessing RDF data. There is no formal, publicly standardized language for + querying RDF information. Likewise, there is no formal, publicly standardized + data access protocol for interacting with remote or local RDF storage + servers.
Despite the lack of standards, developers in industry and in open source projects have created It may be only a small exaggeration to say that there are as many different methods of accessing remote RDF storage servers as there are distinct RDF storage server projects. Even where the basic access protocol is - a standard—HTTP, SOAP, or XML-RPC—there isn't much common ground - upon which generic client support to access a wide variety of such servers - might be developed.
- -The following use cases characterize the most important and most common - motivations behind the development of existing query languages and protocols. - The use cases, in turn, inform decisions about requirements, that is, the - critical features that a standard RDF query language and data access protocol - require, as well as less urgent objectives.
+ standardized in some sense—HTTP, SOAP, or XML-RPC—there is little + common ground upon which to develop generic client support to access a wide + variety of such servers. + +The following use cases characterize some of the most important and most + common motivations behind the development of existing RDF query languages and + access protocols. The use cases, in turn, inform decisions about + requirements, that is, the critical features that a standard RDF query + language and data access protocol require, as well as less urgent + objectives.
-
- George wants to send email to a person named "Johnny Lee Outlaw". George's personal address book, which includes contact information for a "Johnny Lee Outlaw", is stored in RDF using the FOAF - vocabulary Specification. George's email client queries his local address - book service and, since there is only one match, sets the query's result as - the value of the "To:" field.
+ vocabulary Specification. + + + +George's email client queries his local address book service and, since + there is only one match, sets the query's result as the value of the "To:" + field.
Since Smiley's query will operate over knowledge bases structured by at
@@ -149,8 +151,6 @@
like dc:title, doi:title, and
mods:title.
Niel has to drive every day from home to his office during heavy rush hour - traffice in Atlanta, GA.
+ traffic in Atlanta, GA.But his new car has Bluetooth and wireless internet access. Using his cell - phone, Niel asks his car to query public RDF storage servers on the Web for - an up-to-date description of Atlanta road construction projects, traffic - jams, and roads affected by inclement weather.
+ phone, Niel asks his car to query public RDF storage servers on the Web for a + description of current Atlanta road construction projects, traffic jams, and + roads affected by inclement weather.Based on the information retrieved from the Web, Niel uses the mapping program in his cell phone to plan a different route to work, cutting his @@ -239,79 +239,84 @@ checking it. Writing a query, feeding it to a query processor is much quicker than writing a custom program to do the same.
-The following technical requirements are features or characteristics of + either the query language or data access protocol (or, in some cases, of + both) that are mandatory in the specification.
A query language must include the ability to match paths through an - RDF graph where the number of arcs traversed is greater than one, as well - as single one-edge paths. The query language may still only have paths of - fixed length in the query or may cover paths of variable length (e.g. - transitive closures).
-The query language must include the capability to restrict matches on + a queried graph by providing a graph pattern, which may consist of one or + more RDF triple patterns, to be satisfied in a query.
+It must be possible for queries to return zero or more bindings of - variables to values. Each such binding is one way that the query can be - satisfied by the query graph.
+ variables. Each binding is one way that the query can be satisfied by the + queried graph. +One common way to associate variables with values for a binding is as - a tuple of values, where the variable name for each item in the tuple is - known beforehand or is part of the results format.
- - -The query language must have a mechanism—whether function calls, - namespaces, or some other— to allow extensibility in calculating - with and testing of values.
- -Some application domains have specific value-processing requirements; - for example: the concept of "distance" in geospatial data and calculating - the gravitational attraction of two masses, given their mass and the - distance between them. Value processing can be done more efficiently when - domain specific functions are used to test and calculate based on values - in the dataset.
-The query language must make it possible—whether by way of + function calls, namespaces, or in some other way—to extensibly + calculate with and test values.
+ +Many application domains have specific value testing requirements; for + example: the concept of "distance" in geospatial data or calculating the + gravitational attraction of two masses, given their mass and the distance + between them.
+It must be possible for query results to be returned as the subgraph - of the original query graph that the query matches. Executing the query + of the original queried graph that the query matches. Executing the query on such a subgraph would yield the same subgraph; if obtaining variable bindings, the same variable bindings would be obtained.
It must be possible to select an entailed subgraph of a queried graph, + in which case the query results are an RDF graph.
+The query langauge must not depend on the access protocol and should - be suitable for use in accessing local—that is, the same machine or - same system process—RDF data.
-The query language must be suitable for use in accessing local RDF + data—that is, from the same machine or same system process.
+It must be possible to express a query that does not fail - when some nominated part of the query - specifying "optional triples" 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.
+It must be possible to express a query that does not fail when some + named part of the query specifying "optional triples" 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.
The set of operations possible on values obtained from the RDF graph - must include date and time operations "equal", "before" and "after".
+The query language language must include support for a subset of XSD + datatypes and operations on those datatypes.
The query language or protocol must be able to place an upper bound on - the number of results returned.
+The query language or protocol must be able to specify an upper bound + on the number of results returned.
-* There must be a text-based form of the query language which can be - read and written by users of the language (typically application - writers). c.f. SQL. -* Query results may return source/provenance -* Queries expressing arbitrary RDF data types -* Queries for the non-existence of one or more triples in a graph. -* Query results in user-selectable Internet Media Types. --
The following design objectives differ from the preceeding requirements in + that the query language and data access protocol specification may be + considered complete if none, some, or all of these design objectives are + achieved. In other words, design objectives are optional features or + characteristics of the query language or data access protocol.
+ +There must be a text-based form of the query language which can be + read and written by users of the language.
+It should be possible for query results to include source or + provenance information.
+It should be possible to query for the non-existence of one or more + triples or triple patterns.
+It should be possible to specify, either in the query or in the data + access protocol, the serialization format of the query results; this + design objective is meant to be orthogonal to the semantics of query + results, whether subgraph, variable bindings, or some other type.
+It should be possible to specify two or more RDF graphs against which + a query shall be executed.
+ +This objective may be understood in two ways: first, as an aggregate + query, which is unioning the results of executing the query against two + or more graphs; second, as union query, which is a query against the + union of two or more graphs.
+It should be possible to query the RDFS structure of an RDF graph to + find, for example, the parents and instances of a class or the class + tree.
+See the survey of existing RDF query language implementations: RDF Query and Rules
@@ -380,6 +434,21 @@
If you have questions about specific problems or issues in
this document, contact Kendall Grant
+-----
+Some Terms for an eventual glossary...
+query results
+queried graph
+query results format
+query results serialization type
+data access protocol
+query language
+query server
+query client
+aggregate query
+union query
+-----
+
+ 
+