This document is an informal artifact of the W3 Data Access Working Group and, as such, has no formal status. The most recent version of this document is available at http://www.w3.org/2001/sw/DataAccess/UseCases. The current working version is marked:
$Id: UseCases.html,v 1.24 2004/04/16 21:44:17 kclark Exp $.
DAWG members are using this document to structure and organize discussion about use cases related to RDF query language and data access standardization efforts.
The Semantic Web effort is mature enough that the existing implementations of RDF data storage servers require a standardized query language and data access protocol in order to achieve widespread data interoperability. A standard RDF query language might coalesce the technology intended for querying RDF data in much the same way that SQL did for RDBMS data. A standard way to access remote RDF storage servers might accomplish for the Semantic Web and data interoperability much of what HTTP did for the Web itself.
Because there are no formal standards in these areas, developers in industry and in open source projects have created many query languages for RDF data. These languages lack both a common syntax and a common semantics. In fact, the extant query languages implement a significant semantic range: from declarative, SQL-like languages, to path languages, to rule or production-like systems. The existing languages also exhibit a range of extensibility features and builtin capabilities, including inferencing, distributed query, and domain-specific semantics.
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 ground upon which generic client support to access a wide variety of such servers might be developed.
Use cases are used to determine and publicize the scope of the working group's technical work. Each use case describes a concrete application of the future DAWG recommendation, setting a user-oriented context in which the query language or protocol or both are used to solve a real problem. In this way the Working Group describes the principle benefits of DAWG, while at the same time creating a map of the problem space.
George wants to send an email message to John Smith. His personal address book, which includes John Smith's contact information, is stored in RDF using the FOAF vocabulary Specification. George's email client queries his local address book service and, if there is only one match, sets the query result as the value of tthe "To:" field; otherwise it prompts George to choose the best match.
Marshall needs to update some personal financial information every day; he programs an off-the-shelf web agent program to execute a query every morning before he gets to work and every evening before he goes to bed. Marshall uses a wizard to formulate the query, which the web agent constructs as an HTTP URI. In order to fulfill Marshall's information gathering requirement, his web agent simply resolves the query URI.
Kate wants to be notified whenever there is a news item about her favorite television show. She is accustomed to visiting web sites every day to search for and read about news items that match her interests.
...
Frannie and Zoe live in different countries and keep in daily contact via IRC. Zoe wrote an IRC bot that they use to keep track of things they say about web pages. Frannie wants to be able to republish some of the things she says in IRC on her weblog. So Zoe tells her about a server that accepts and agrees to host documents that describe what they say about web pages, and their IRC robot sends those documents periodically to the server.
Frannie programs her weblog software to query the server that hosts their annotation documents. The server returns all the assertions Frannie and Zoe have made about webs page that Frannie writes about in her weblog; Frannie's weblog software then publishes the things they've said as comments.
Abelard, an independent publisher of web publications, often needs to query an arbitrary list of RDF storage servers for assertions about a set of URIs he cares about; the URIs identify Abelard's web publications. The RDF storage servers are RSS feed aggregators. Abelard wants to use RDF to keep track of the things people say in weblogs about his publications.
Abelard's client software includes support for three different query languages. Abelard's client software connects to each RDF storage server and determines whether it supports one of the three query languages it knows about. Abelard's client software chooses, based on priorities set by Abelard, to send different queries to different servers.
Heloise, an aggregator of RSS feeds, publishes RDF (extracted from RSS feeds) on the Web using an RDF storage server. Heloise's server supports several RDF query languages.
Heloise's server publishes its supported query language available in a machine readable form. It negotiates with clients in order to choose the most appropriate query language that they have in common.
Bartleby manages an accounting firm that has aggressively adopted Web and
Semantic Web technology. The firm stores information about its customers,
other companies, and competing accounting firms in an RDF storage server; and
it relates these entities via predicates acct:accountsFor and
acct:hasCustomer. Bartleby wants to retrieve the names of all
the firms which either maintain accounts for military suppliers or maintain
accounts for the military itself.
Jose learns that the U.S. Census Bureau provides some very interesting geographic data in its public domain Tiger database. Jose moves to a new home in the Thomas Circle neighborhood of Washington, DC. Jose wants to find out the latitude, longitude, name, and type of everything within 50 miles of his new home.
Rather than downloading all the Tiger database files, unziping them, reading the docs, writing some software, and so on, Jose sends a DAWG-QL query to the Census Bureau's new RDF storage server and requests that the results be passed to an XSLT transformation service so that he can print the resulting XHTML.
...
Smiley works for a governmental intelligence agency. As part of his job as an analyst of raw human intelligence, he needs to be notified whenever the knowledge base contains information about people matching various properties: last known location, often visited web sites, and political associations.
Smiley uses his web browser to setup a regular query over several knowledge bases by filling out a web form. Whenever there are new matches for Smiley's query in the knowledge base, Smiley receives an email with URIs to resources about the new matches; and Smiley's personal RSS feed is also updated with the new matches, since he uses an RSS aggregator to gather news every day.
Since Smiley's query will operate over knowledge bases structured by
several different ontologies, Karla, the staff programmer for Smiley's group,
builds Smiley's query to look for rdfs:subPropertyOf foaf:Person
(expecting to find properties like
terror:RegisteredForeignAgent,
terror:TerroristSuspect, and
humint:UnidentifiedPerson). Smiley's staff programmer uses the
DAWG-QL and the foaf:Person predicate, as well as several
others, to formulate Smiley's query.
rdfs:subPropertyOf to find knowledge rooted at
foaf:Person, which government agencies have agreed to use as a
common parent property to represent natural persons.Endeavour, a Triumph Motorcycle dealer, maintains a database that describes spare and replacement parts, including their properties and relationships, needed to repair its motorcycles. Ev, a Triumph repair person, is working on a motorcycle and a diagnostic tool produces a report that identifies a faulty part.
Ev goes to a query interface to the vendor's parts database and asks "tell me about this part". In response, Ev recieves a humanly-readable description of the part, which provides sufficient information to determine how to obtain the part and whether any other dependent parts must also be replaced at the same time.
Nada, a Semantic Web developer, has had a bug report from a valued user that indicates that a software tool is failing to correctly the N3 representation of some of the RDF core test cases correctly. Nada wants to create a list of input and output documents for each of the approved test cases from the RDF core test suite. The list of tests resides in a single file.
The value is the systematic processing of the RDF core manifest file with a result which is one line per input/output pair so that a script can easily be written to create the next stage - reading the input document, writing it and checking it. Writing a query, feeding it to a query processor is much quicker than writing a custom program to do the same.
Grace, an open souce developer, is developing a new email client, and the
system uses a lot of configuration settings and data, some of which may be
relevent to any email client and some of which is specific to this particular
one. Grace would like to record all configuration data as RDF. She
understands the basic RDF data model and knows precisely the structure of the
information she's interested in: local-username email:hasAccount
account, account email:hasServer server, and server
email:usesProtocol protocol. But she has no expertise in programming
graph algorithms or manipulating RDF programmatically. She would like to
retrieve those aspects of the configuration files in which she is interested,
i.e. the server and its protocol for a particular account or username.
Demonstrates the value of programmatic access to local RDF repositories.
Niel wants to drive, during heavy rush hour traffice in Atlanta, GA, from his home to his office. His new car has both Bluetooth and wireless internet access. His car makes three queries to public RDF storage servers on the Web: the first for a up-to-date description Atlanta road conditions and construction projects; the second for an updated description of traffic jams; the third for an updated description of Atlanta roads suffering inclement weather.
Based on this information, Niel's car suggests a different route to work, cutting his commute time by 12%.
...
...
Amy, an oncologist, enters an order for a chest x-ray. She works in a large, multi-campus hospital with multiple radiology departments. The hospital complex uses RDF to describe the properties of its departments and the relations between them. For example,
Amy doesn't know or care about all of these relations or rules. She only wants to place an order and then learn where it will be executed.
This use case shows the need to add constraints in the query and shows the need for not only querying for information but also for a resolution of a problem: given constraints, imposing a sort order on some criteria. The difficulty is that that 'criteria' is not necessarily a data element in the rdf document but implied in the rules within the document.
A company classifies employees into three groups: management, support, and
engineering. Each employee is assigned to exactly one of these groups. There
exists an RDF store which encodes information about employees. This
information also includes the office in which the employee works. For
example, #David hasGroup #Engineering and #David
worksInOffice #Carlsbad.
The information is not complete; e.g. there may be employees whose group is not explicitly stated in the RDF store. The company also builds an OWL ontology to supplement their RDF data with semantic information. Among other things, this ontology contains the assertion that certain corporate locations contain no engineers, only management and support. A user wishes to query the RDF store to find all employees who are in either the management or support groups (and print out their names).
While inferencing and OWL may be beyond the scope of this working group, this use case demonstrates the continuity from RDF queries to OWL queries. The user's question can be answered fairly well by a simple RDF store (with no OWL), but precisely the same query (in terms of the user's desire for information) can retrieve even better information if OWL data is available.
Note that this use case is *not* subsumed by any other we are considering. The use of disjunction makes the OWL ontology incompatible with the naive "inferred triples" model.
DAWG use cases are a pool from which to extract technical requirements. These requirements frame the technical scope of the working group's activities, including the delivery of a strawman query language at the end of the first phase of the working group. The working group will use the strawman query language as the starting point for design work in its second phase.
See the survey of existing RDF query language implementations: RDF Query and Rules Framework.
If you have questions about specific problems or issues in this document, contact Kendall Grant Clark.