W3C home > Mailing lists > Public > www-webdav-dasl@w3.org > July to September 1998

Updated scenarios document

From: Rick Henderson <rickh@netscape.com>
Date: Fri, 04 Sep 1998 20:22:16 -0700
Message-ID: <35F0AE68.36E4E5B4@netscape.com>
To: DASL List <www-webdav-dasl@w3.org>
Attached is the updated scenarios document in txt and html form.

Rick Henderson            (Netscape)(650)937-3152

INTERNET-DRAFT                                        Rick Henderson
draft-dasl-scenarios-00.html                 Netscape Communications
September 4, 1998
Expires Mar 4, 1999

Scenarios for DASL

Status of this Memo
  This document is an Internet draft. Internet drafts are working
  documents of the Internet Engineering Task Force (IETF), its areas and
  its working groups. Note that other groups may also distribute working
  information as Internet drafts.
  Internet Drafts are draft documents valid for a maximum of six months
  and can be updated, replaced or obsoleted by other documents at any
  time. It is inappropriate to use Internet drafts as reference material
  or to cite them as other than as "work in progress".
  To learn the current status of any Internet draft please check the
  "lid-abstracts.txt" listing contained in the Internet drafts shadow
  directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  munnari.oz.au (Pacific Rim), ds.internic.net (US East coast) or
  ftp.isi.edu (US West coast). Further information about the IETF can be
  found at URL: http://www.ietf.org/.
  Distribution of this document is unlimited. Please send comments to
  the mailing list at www-webdav-dasl@w3.org, which may be joined by
  sending a message with subject "subscribe" to
  Discussions of the list are archived at

  The Distributed Authoring and Versioning protocol [WEBDAV] defines
  simple mechanisms to assign and retrieve values for properties. This
  document presents scenarios for a WebDAV extension to support
  efficient searching for resources based on WEBDAV properties and
  content. These scenarios are intended to suggest some of the uses that
  DASL could be put to. This may in turn motivate decisions on what is
  essential to DASL and what may be considered extra.

1. Introduction
  The scenarios below are intended to provoke discussion of what DASL
  should and shouldn't do. It is not necessarily true that DASL should
  support all of these or to what extent DASL should support them and to
  what extent DASL is a small piece of what it would take to support
  them. At least one is probably impossible. These scenarios should

Henderson                                                      [Page 1]
Internet Draft              DASL Scenarios               September 1998

  encompass most of the sorts of things that we expect DASL to play a
  part in.

2. Scenarios
  The scenarios below are roughly grouped into scenarios dealing with
  the following topics: Document Management, Seeking Information,
  Navigation, Controversial Scenarios, Document Management Alliance, and
  Various types of documents DASL could search over.

2.1 Document Management
  Search could be used to help keep track of what is going on with a set
  of DAV resources. Some DASL queries that might help with this:
     * Search for all the documents that are locked.
     * Search for all the owners of locked documents.
     * Search for documents that have been locked for more than 1 week.
       [Though desirable this is impossible since DAV does not record
       the time when a document was locked]
     * Search for documents that have not changed in the last year.
  These queries could help find documents that are likely to be
  undergoing changes, who is changing them, what documents have been
  locked for too long, what documents aren't dynamic anymore.

2.2 Seeking Information

2.2.1 Finding a specific document by phrase
  A user remembers a document that they liked and want to see again but
  doesn't have it book marked or remember the location. They do remember
  a key phrase from the content though. They can search for the phrase
  such as "invisible car", and find the document without picking through
  a large number of irrelevant documents.

2.2.2 Finding a specific document by author and date range
  A user's information need may be expressed something like this: "I
  need that trip report that John Doe wrote last spring." They don't
  know its location or its title. They can search for documents with
  author equal to "John Doe" and create date greater than 1998/01/01 and
  less than 1998/06/01. This may yield few enough documents to easily
  find the one of interest.

2.2.3 Finding a specific document using content search
  Another user's information need may be like this: "I need that article
  I saw a while back that made a connection between epilepsy, migraines,
  and zinc." They can do a content based search using the words,
  epilepsy, migraine, and zinc.

Henderson                                                      [Page 2]
Internet Draft              DASL Scenarios               September 1998

 2.2.4 Finding a specific document using both content and property
  The user who wanted to find the trip report that John Doe wrote last
  spring may find that John Doe was very prolific and wrote several
  hundred things last spring. The user may do better using both content
  and property search. They can search for documents with author equal
  to "John Doe" and create date greater than 1998/01/01 and less than
  1998/06/01 that contain the some of the words IETF, Redmond, and DASL.

2.2.5 Finding documents of a particular kind
  DASL could be used to find documents of a particular kind such as
  images. This could be used directly by an end user looking for
  interesting images, or by a program that does some kind of processing
  on the images like select gif images that are portraits. A query that
  asked for mime-type = image/* could gather that data.

2.2.6 Finding documents in a particular language
  Assuming that a language attribute is set, then a search could be
  restricted to documents that are in a particular language, say German.
  It would be possible for a site to automatically set this tag using
  language recognition technology.

2.2.7 Searching for information on multiple servers
  A user seeking information of some sort may not know what server(s)
  contain the information they are seeking. The DASL client program can
  send the content based query to a several servers without having to
  translate the query into a different query syntax for each server. For
  property queries, the DASL client can query the attribute schema on
  the DASL servers and send a property query or a mixed property and
  content query to a set of DASL servers that have common property
  schema. The results from such a cross server search can be sorted
  according to property values or according to relevance score.

2.2.8 Stemming
  If a user is searching for information about the hobby of building
  model cars, documents that are likely to contains various forms of
  those words, model, models, modeling, as well as car and cars.
  Stemming saves them from entering all the various forms of the words
  they may want to match. Entering all these forms can be much more
  problematic in more inflected languages than English.

2.2.9 Word proximity
  In the stemming example our user was searching for fairly common
  words, car and model, in an effort to find information on building
  model cars. Many documents that have nothing to do with model cars or
  building models of cars might contains both words. What the user wants

Henderson                                                      [Page 3]
Internet Draft              DASL Scenarios               September 1998

  is documents where model and car are close together. A search that
  takes into account the proximity of the search terms would help filter
  out the irrelevant documents.

2.2.10 Query By Example
  A user has done a search and found some relevant or nearly relevant
  documents and some clearly irrelevant documents. Desiring a broader
  and more specific set of documents, they specify one or more of the
  relevant result documents and one or more of the irrelevant documents
  to a query by example type operator. The result is a new set of
  documents having more overlap in keywords than the irrelevant
  documents. This type of operator saves the user the considerable
  trouble of constructing a new query that will filter out the
  irrelevant documents while expanding the set of keywords from he
  relevant documents.

2.3 Navigation

2.3.1 Site Navigation
  While DAV itself is sufficient for basic site navigation, DASL can
  support fancier site navigation, where documents are sorted on the
  server, or filtered out on the server.

2.3.2 Browse Tree for exploring a document space
  A DASL application could present a browse tree for a set of documents.
  In a browse tree some property is selected at each level of the tree
  to branch on. Thus if the top level property selected were document
  type, then the unique values of the document type property for all the
  documents would be the branches of the tree and would be presented to
  the user. So the user might see a list of document types, say
  "Administrative memo", "Design spec", "Requirements spec", "Test
  plan", "Project schedule". Beneath that another property could be
  selected, say Project, which might display project names with values
  such as "Tuolemne", "Calaveras", "Russian", "Sacramento", "American",
  "Merced". At that point the user might want to view the list of
  documents within these categories and there might be only a few or
  just one project schedule for project Russian. The same document space
  might also be explored using properties like Date and Author. (Note:
  DASL will most likely not explicitly support browse trees, but
  searches like 'docType = "Design spec" AND project = "Tuolemne" sorted
  by date' could be used to gather the raw data to generate the
  information for a node in the browse tree)

Henderson                                                      [Page 4]
Internet Draft              DASL Scenarios               September 1998

 2.3.3 Finding information on a particular topic in an organized
  A collection may have been organized according to some taxonomy and
  the keywords chosen accordingly. The user, knowing or having scanned
  the taxonomy, presents a query for general subject equal to gardening
  and subordinate subject equal to bonsai.

2.3.4 Finding information on a particular topic in an unorganized
  A collection may not have been organized according to some taxonomy or
  the taxonomy may not be detailed enough for the user's purposes, or
  may be irrelevant to the user's interest. In this case content based
  search becomes crucial. A user could search for documents containing
  all three of the words "small", "Japanese", and "trees", and likely
  obtain articles on bonsai. If the collection were organized with a
  taxonomy that the user didn't know about they could then discover the
  keywords from the document found and use that to find other documents
  with the same categorization.

2.3.5 External taxonomy to view a DASL collection
  A user could view various DASL supporting collections according to the
  user's own taxonomy. Here we assume that the user has a taxonomy where
  for each category there is a complex query for which the relevance
  score returned establishes a documents degree of membership in the
  category. A DASL application could issue a series of these queries on
  a collection resource and thus categorize the documents within the

2.4 Controversial Scenarios
  These are scenarios where there is great doubt as to if they will be
  supported in the protocol.

2.4.1 Finding the right information by looking at the hit highlights
  Natural language being so context dependent means that content based
  search inevitably retrieves false positives if it is getting very many
  of the true positives. The user is left to pick through the documents
  returned to find the ones that are actually relevant. Highlight
  information can be used to make this easier. A DASL application could
  present a list of the sentences that had the hit words in them. This
  is likely to allow the user to discard most of the false positives
  without having to view the whole document.

2.4.2 Finding the information in a large document
  The user may do a content based search that returns a large document
  of many pages but the relevant part of the document is in only one or
  a few parts of the document. Hit highlighting will help the user find

Henderson                                                      [Page 5]
Internet Draft              DASL Scenarios               September 1998

  those parts. A smart DASL application could present links to jump to
  the next hit or concentration of hits.

2.4.3 Saved query result
  A user does a search and gets a very large set of results. The user
  then progressively narrows the search down by adding constraints to
  the previous search.

2.4.4 Saved query result II
  A user does a search and spends some time improving the query so that
  it catches a large set of information on a particular topic without
  bringing in much noise. The query is made available to other users
  with similar information needs. The others are likely to combine that
  query with their own more temporary constraints to achieve their own
  information needs. If saved searches are explicitly part of the DASL
  protocol, it may be easier for servers to recognize repeated queries
  and avoid full re-execution of a search.

2.5 Document Management Alliance
  The DAV/DASL capabilities could be implemented via an implementation
  of the Document Management Alliance (a document management API
  standard). This would allow the documents from a feature rich document
  application to be exposed on the web via DAV and DASL.

2.6 Various types of "documents" that DASL could search over
  Many different sorts of documents and types of information can be
  searched for using the DASL protocol. Besides the usual notion of
  documents written by a person with the intent of conveying some kind
  of information, other possibilities are:

2.6.1 Source Code
  Computer program source code contains a large amount of information of
  a somewhat structured nature as well as unstructured natural language
  comments. Much structured information can and is extracted and could
  be made available to CASE tools or actual programmers.

2.6.2 Phone conversations
  Phone conversations are often recorded. They could have voice
  recognition applied allowing content based search on the contents of
  the conversation along with property search on information about the
  call, e.g. caller, callee, time of call, possibly voice recognition or
  voice separation info.

Henderson                                                      [Page 6]
Internet Draft              DASL Scenarios               September 1998

 2.6.3 Mug shots
  Any standardized type of image could have a lot of structured
  information extracted and made available for search. There might be
  applications in law enforcement, talent search, or genealogy.

3. References
  [WEBDAV] Y. Y. Goland, E. J. Whitehead, Jr., A. Faizi, S. R. Carter,
  D. Jensen, "Extensions for Distributed Authoring and
  Versioning on the World Wide Web", April, 1998. internet-draft,
  work-in-progress, draft-ietf-webdav-protocol-08.txt.

4. Authors' Addresses
  Rick Henderson
  Netscape Communications
  501 E. Middlefield Road
  Mountain View CA 94043

Henderson                                                      [Page 7]
Received on Friday, 4 September 1998 23:29:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 22 March 2009 03:38:04 GMT