Contextualization of Resolution BOF (c15n)

Tuesday, December 12 at 1700-1800
=================================

CHAIR: Michael Mealling <michaelm@netsol.com>

DESCRIPTION:

The URN WG's Dynamic Delegation Discovery System (DDDS) describes 
a generalized architecture for 'top down' resolution of identifiers 
such as URIs.  This works well when a (software) client wants or 
needs to dynamically determine the explicit authoritative delegation 
of resolution.  However, there are times when it is desirable to
incorporate other elements of contextual control information in
determining, for example, the  "appropriate copy" of a resource --
preferrentially finding a "local" copy of a journal rather than
(re)purchasing one from the authoritative publisher.  This is generally
applicable to all URI resolution, but it is more specific than "web
caching".  Software systems being built to solve this in today's
deployed systems are using specialized, non-interoperable, non-scalable 
approaches.

Some current experimentation and a straw proposal are described below.

This BoF is chartered to determine if there is interest/wherewithal to
determine a standard vehicle to process contextualized resolution that

   a) is not application- or protocol-specific and
   b) ties in with global resolution systems (such as DDDS) in order 
      to preserve authoritative resolution chains, where applicable

Beyond the "appropriate copy" scenario, this should equally be
applicable in non-document contexts -- e.g., IP-telephony (enterprise
dialing schemes taking precedence over, but linked to, global
numbering).

While the focus of this BoF is on standardized resolution
steps/mechanisms, not "metadata" or "knowledge transactions",
discussion must reflect that "context" generalizes beyond
location/area (e.g., to "who's paying for this", etc).

AGENDA:

  . Agenda bashing [2 min]
  . Introduction/Overview of C15N [10min]
  . Discussion of Straw Proposal (below) [20min]
  . Relationship to other work -- at IETF, W3C, etc [5min]
  . Discussion of proposed charter [20min]
  . Yes/no

All of the above should be considered in relation to the web-caching,
proxying, and content-delivery BoFs also occurring this week
(OPES, CDNP, WEBI).


Sample current implementation
-----------------------------

Some experiments have been carried out elsewhere -- e.g., the SFX
project described at:

http://www.dlib.org/dlib/october99/van_de_sompel/10van_de_sompel.html

and in

http://www.doi.org/workshop_19sep00/doi_wkshp_0900_llversion.ppt

Today, this work uses HTTP cookies -- so that the (web) client asks the
global resolution for an identifier (from a reference), and sends
a cookie which is a key for the appropriate context.  The
global system uses this key to redirect the query to the appcopriate
local knowledge server (address), which makes the judgement
about where an appropriate copy of the resource shall be obtained.


Straw proposal
--------------

As the starting point for discussion of how to solve this problem,
we propose the following optional additional steps for resolving
URIs in a contextualized fashion:

There are 3 primary elements:

      . context object -- the identifier and some description of
        context

      . local knowledge server [_not_ defined by us, or even
        by application; rather, we define the abstract operations
        for interacting with it]

      . application linkage to a global resolution authority
        (e.g., DDDS for URNs, http resolution standard, etc)

In order to ground the discussion in some semi-concrete proposal
a strawman proposal based on XLink for link typing and RDF for
context object expression will be used. In this case, the extended
XLink would relate three resources - the local resource, the desired
remote resource, and the RDF info containing the context. Each locator
will have a typed arc that determines the types of traversals
available. Additional discussion may include how this context object
may be passed to various proxies/caches for resolution based on that
context -- strictly as a tie-in with other replication, caching and
content delivery work under discussion at the IETF.

Xlink is described at http://www.w3.org/XML/Linking
RDF is described at http://www.w3.org/RDF/


Open questions
--------------

These currently include:

      . Can/should this be transparent to the client software, or
        must/should it be an external negotiation in a separate
        protocol?

      . Is this configured or dynamically controlled?

      . Is this "get appropriate copy", or "get appropriate
        transformation" (i.e., to a new identifier, appropriately
        contextualized)

      . Can this support multiple, overlapping contexts (e.g.,
        location and "who's paying for this")