Contextualization of Resolution BOF (c15n) Tuesday, December 12 at 1700-1800 ================================= CHAIR: Michael Mealling 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")