globally accessible local URIs - discussion ideas

Version 1, 4/6/2008
Alan Dix, Akrivi Katifori, George Lepouras

This is a discussion document and will be updated: see latest
To discuss this use Alan's blog entry on "local URIs … mashing up the desktop"

Motivation and Concepts

Mashing the Desktop

URIs allow mashing of data at the level of web page links, SemWeb open data, etc. need same for local resources. Three kinds (at least):

desktop mashing
links to desktop resources accessible from desktop apps on the same machine.
workgroup mashing
links that can be shared between local configurations of several devices, but not necessarily persistent beyond a collaborative session.
global mashing
links that can be embedded or referred to on the web or as persistent reference points on devices other than the originating machine.

Desktop Mashing and Desktop URIs

The first stop is t be able to refer to desktop resources form within the same machine. For example, a calendar application should be able to have a link to the mail message which informed of the event.

The "file:///" URL allows this for filesystem resources, but this is also required for all desktop entities: mail messages, calendar entries, address book, etc.

This was an active topic for the Gnowsis project [S08].

For desktop mashing the key requirements are:

persistent identity (local)
being able to refer to an entity over a period of time
navigation (local)
being able to in some way click or open links and be directed to the relevant resource opened in an appropriate application

Note the above only has to work within the context of a single machine.

The Gnowsis DURI proposal includes the application name in the URI scheme. Given, say, an IMAP mail message may be accessible via several apps, maybe the URI should be more focused on the data type … however for most current data this will only be interpretable by the creation app. so this is a moot point until desktop data is more openly accessible.

Temporary Workgroup Mashing

Scenario – people at meeting with tabletop display, wall displays, PDAs, tablet PCs, wanting to drag documents back and froth between devices.

Key requirements:

session identity (non-local)
being able to refer to an entity during the working session from any device and have the same meaning.
to be able to give credentials for access to a resource as part of giving reference to it (but not necessarily permanent, just whilst the originating device remains within the workgroup.
data access (non-local)
being able to obtain the data referred to by the reference. (This may lead to independent copies of the item)

The Gnowsis proposal allows the possibility to include an IP address in the DURI. This may not persist over long time periods (e.g. DHCP), but may well be sufficient for session URIs.

Web Mashing of Local Resources

Scenario – looking at mail message and want to Snip portion. It is added to Snip!t with a form of URI. Later on the same machine I click the link I should get to the mail message. That is, I should be able to freely use my local URIs in web resources that I access. However, if on another machine I should either (a) see some sort of message telling me that the resource is not valid for the context or (b) be directed to some alternative local representation (e.g. same IMAP mail message, but viewed on different mail user agent).


persistent identity
being able to refer to an entity over a period of time over a global namespace
context independent identity
the same identifier should not be confusable with different entities on different machines (i.e.. not like "file:///")
being able to in some way click or open links and be directed to the relevant resource opened in an appropriate application when on the originating machine - with some appropriate refusal or alternative form in other contexts
access control
to be able to protect access to sensitive metadata connected to the URI but allow full access to the originating user. authority – to be able to give permanent or temporary credentials for access to some aspects of the resource metadata.
privacy and anonymity (?secondary requirement)
to protect access to sensitive metadata even within the URI (e.g. not having mail URIs that include the email address of the sender/recipient, obfuscating file names in file URIs).
data access (secondary requirement)
being able to obtain the data referred to by the reference. (This may lead to independent copies of the item)
copy resolution (secondary requirement)
being able to identify that an identifier originating on one device refers to the same resource on another (e.g. IMAP mail). This is a special case of the issue of uniqueness of URIs. Arguably as soon as the resource is copied to another device it is a different resource as it could be edited locally. So this may become an issue of provenance … being able to identify alternative resources that in some way are related to or derived from the original resource. In the case of an IMAP URI there is arguably a difference between the reference to the local copy of the mail message (a local URI) and that to the globally identifiable IMAP URI which is a private URI. The Magnet URI scheme [M02] would partially address this as it allows references to resources by content-related info such as SHA digest.

Possible Framework for GLOIs


Not sure of the right name for the this, have adopted GLOI (below) mostly becasue it sounds nice! ... but other options:

Globally accessible Local Object Identifier - pronounced "Glowee"
Globally accessible Local Resource Identifier - don’t know how to prononce … I keep wanting to say "girlie", but that is perhaps a sign of my own slight verbal dyslexia!
Universally accessible Local Resource Identifier - either "ulree" with 'u' as in "but" or "gull", or maybe more Scandinavian "oolree" (roll the 'r' for best effect)


Assume that a local agent manages description and navigation at the level of the desktop but that independent web-accessible registration and resolution authorities manage the GLOI itself. The GLOI then becomes a URL within a resolution authority’s domain.

Attempting to access the URL gives meta information about the resource as an XML (RDF) document with a file extension and mime type that is recognized by local agents. The data returned depends on authentication and may be inaccessible (400 response) or reveal limited metadata depending on authentication and access rights (normal web practice).

The local agent interprets the metadata and determines if it refers to one of its own resources. If so it uses the relevant metadata attributes to invoke the relevant application passing it additional metadata sufficient to locate the precise resource.


Phase I – GLOI Creation

step 1.
Based on user request or some other event, an originating application (OAP) needs to generate GLOI for local resource
step 2.
OAP creates metadata that will enable it to relocate the resource (e.g. in file system the file path, in mail app may add unique id to message header and use that)
step 3.
OAP asks local GLOI resolution agent (LRA) (which may be partially embedded in OAP) to add any additional information it needs to re-identify the application … or steps 2 and 3 combined in some cases
step 4.
Local agent sends request to global resolution authority (GRA) for GLOI. The request has four main parts (a) client id or similar data to uniquely identify the local device, (b) metadata or desktop URI sufficient to identify the resource on the device (c) optionally additional information (e.g. MD5, IMAP URI) to match with potentially identical resources on other devices, (d) some form of authentication/access data to say who can access the metadata in the GLOI.
step 5.
GRA stores the metadata persistently and creates an obfuscated URI. For example, if the GRA were at "", the URI might be of the form "" where "97A3E526C" is a unique id generated by the GRA.
step 6.
The LRA or APP uses this in some way, for example to post on a web site or embed in an email message.

steps in GLOI creation
Figure 1. Architecture of GLOI Creation

Phase II – GLOI Resolution

step 1.
Some event require resolution of GLOI, for example I user visits web app with GLOI and clicks link. The recipient application (RAP) therefore needs to resolve the GLOI.
step 2.
The GLOI is accessed just like any URI … indeed at step 1 the RAP may be unaware that it is special and, for example, simply launch a browser with the URI, so that the browser becomes the secondary RAP.
step 3.
A request is sent to the registration authority GRA, which checks the authentication of the sender. If not suitably authenticated some form of request for authentication, or partial metadata may be returned depending on permissions, preferences etc.)
step 4.
If the authentication is successful, the GRA sends back a response with a special extension and mime-type. The response content is an XML version of the metadata (a, b & c) given to the GRA when the GLOI was created at I.4.
step 5.
The LRA is registered with the OS and browser to receive fields with the special extension and so the RAP passes the XML metadata to the LRA. (Or some RAP may have aspects of LRA embedded in library etc.)
step 6.
The LRA reads to the metadata then: (i) checks that the client id is indeed this device. If not it may attempt to match using data (c) if present; (ii) identifies the appropriate originating application (OAP); (iii) passes the metadata to the OAP (possibly reformatted appropriately, for example as apple script request on MacOS)
step 7.
The OAP uses the metadata to identify and open the requested resource.

steps in GLOI creation
Figure 2. Architecture of GLOI Resolution

References and Resources

[S08] Leo Saurmann (ed.). Desktop URIs. (accessed May 2008).

Gnowsis Semantic Desktop environment. Knowledge Management Lab, DFKI, Germany.

[M02] Gordon Mohr. MAGNET v0.1, (Created 2002-06-12; Revised 2002-06-17, Accessed June 2008)

TIM - Task-centered Information Management.

Alan Dix 4/6/2008