Re: Use case: AFS-1: "Find the resource for the person called 'John Smith'"

  >
  > 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