- From: Patrick Stickler <patrick.stickler@nokia.com>
- Date: Wed, 17 Mar 2004 15:08:38 +0200
- To: public-rdf-dawg@w3.org
> > On Thu, 2004-03-11 at 07:23, Seaborne, Andy wrote: > > Let's start with a simple case as much to find out what a use case is: > > > > Suppose an application wishes to find the resources in a knowledge base for > > people with the name "John Smith". The knowledge base is a collection of > > vCards in RDF (see [1] for RDF version, see [2] for the definition) e.g. an > > address book or an enterprise directory. > > > > vCards have a property vcard:FN (FN is "Formatted Name" I think) so we want > > those things with a value of "John Smith" for property vcard:FN. > > This is a good start, but it's not clear to me how the customer/client > gets value yet. > > If you take the system I work on, cwm, and ask it > ?WHO vcard:FN "John Smith". > it'll dutifully bind ?WHO to _:bnode23o4u23 and report > > [ vcard:FN "John Smith" ]. > > i.e. yes, there is somebody/something that has vcard:FN "John Smith". > Gee thanks. The user probably wants his contact info, if he's > using the vcard namespace. Exactly. The default behavior that is defined for RDFQ [1] is to return the description of the matched target, i.e. all the info about the person with the name "John Smith". The typical end goal that I see lurking in just about every use case I've encountered thus far is to find out some information about some thing which is identified by the query. It may be that the ultimate information desired is known, or the user may not be completely clear what information about the resource will be useful. I think that there are three primary forms of response to a query: 1. A set of variable bindings 2. A matched subgraph 3. A set of descriptions of matched targets I think that most software applications which know exactly what bits of information they need to accomplish some task (generate some GUI, render/present some content, invert some switch), will want #1 most of the time; and most reasoning agents (or humans) will want #3 most of the time. The matched subgraph (#2) seems to me to offer the least utility for most applications and often is really just an artifact of trying to get to either #1 or #3 (and I expect that to be reflected in the use cases, to which I plan to be adding to shortly). Patrick -- Patrick Stickler Nokia, Finland patrick.stickler@nokia.com
Received on Wednesday, 17 March 2004 08:12:10 UTC