The User Interface of URNs and URCs

Abstract

1 Introduction

This report gives an overview of the URN and URC issues currently being investigated with an emphasis on how an Internet user should expect to use and interact with these new technologies. A sample scenario is presented to demonstrate this interaction, as well as identifying migration issues which still need to be addressed.

2 Background of URLs

• protocol,

• hostname,

• port number (optional),

• directory, and a

• filename.

http://www.acme.edu.au:8080/projects/oil.html

As can be seen, the syntax is strongly coupled to a number of system-dependant factors. Although URLs were designed to specify the location of a resource, they have become the de facto standard for identifying resources. This has led to many problems as URLs frequently change and become invalid. Problems with the user interface to URLs have been reported by Hoffman (1995) and include:

• long URLs are difficult to type;
• some characters are difficult to represent in printed form (for example, the tilde character);
• changing hostnames, port numbers, directories, filenames; and
• little support for international character sets.

It is important that we learn from these experiences when we design and implement the next generation of naming schemes if we wish to maximise the success and minimise the frustrations.

3 Uniform Resource Names and Characteristics

The main idea behind the use of URNs and URCs is that the combination of

• a unique naming system (URN), and
• a flexible metadata scheme (URC)

3.1 URN Requirements

• Global scope. A naming scheme must be applicable in a global context. This is obvious due to the global distribution of the resources
• Global uniqueness. Names must be unique. No two names can be the same. In a global system, the names must be globally unique. This raises issues on the allocation of new names, and how to ensure that global uniqueness is maintained.
• Persistence. Names should persist forever, even after the lifetime of the resource it names. This has implications on the administration of the naming scheme, and the responsibility of naming authorities.
• Scalability. It must be possible to assign a name to any conceivable resource.
• Legacy support. There is a need to support existing naming systems. This allows the investment in current systems to be preserved and made available to the new system. The process of adopting a naming scheme must be made as easy as possible.
• Extensibility. The naming system must be extensible, so that it can cope with future needs. Extensibility is making the system scalable in its scope, and extends its useful lifetime.
• Independence. Naming authorities are given sole responsibility for issuing names. A system which fosters dependency restricts the use of names and fails when the dependent body is unable to operate successfully.
• Resolution. The naming scheme must not be a barrier to resolution, that is, getting access to the resource. There must be a mechanism for obtaining the resource given its name.

3.2 URN Encoding

• having a single encoding,
• having a simple comparison algorithm,
• being human transcribable,
• being friendly to network transport mechanisms, and
• being able to be automatically processed and recognised.

3.3 URN Syntax

URN:NID:NSS

For example:

urn:isbn:123456789X
urn:inet:dstc.edu.au:tr0088
urn:telecom:61733654310

3.4 URN Resolution

3.5 Uniform Resource Characteristics

Metadata is 'information about information'; that is, it effectively describes a resource for a particular purpose. For example, if we were to describe the metadata for this paper, we may come up with the following description:

Title: The User Interface of URNs and URCs
Author: Renato Iannella
Subject: Uniform Resource Names and Characteristics,...
Identifier: http://www.dstc.edu.au/RDU/reports/AUUG96WWW/index.html

urn:inet:dstc.edu.au:tr0088

• title
  
• subject
  
• author
  
• publisher
  
• other agent
  
• date
  
• object type
  
• form
  
• identifier
  
• relation
  
• source
  
• language
  
• coverage
  

URC-Type: DublinCore
URC-Date-Created: 199501011200Z
URC-Date-Modified: 199501011230Z
URC-Created-By: Mary Smith (smith@dstc.edu.au)

Another benefit from using URCs is that WWW indexers (such as Lycos and Alta-Vista Alta-Vista) can then begin to index the metadata and not the whole document itself. This will improve the quality of the WWW indexed data and improve the retrieval of information via resource discovery tools.

Current work on URCs include the standardisation of a syntax protocol (Burnard et al. 1996] and a transport infrastructure for metadata packages. Most of this work is the result of the Warwick Dublin Core Workshop (Lagoze 1996).

4 URN/URC Scenario

The DSTC decides to use the Dublin Core metadata set to describe their resources. Entries for each technical report are stored in a database. The DSTC also decides on some administrative metadata that captures information about the creation and management of the URC.

The URN resolver is able to resolve any requests for the INET namespace identifier and use the naming authority 'dstc.edu.au' in the namespace specific string. The DSTC sets guidelines on the allocation of the namespace specific string (in this case the Technical Report number). Requests to resolve the above URN will return all the Dublin Core attributes, including the administrative metadata.

The requesting client can verify that it understands the metadata returned by examining the value of the URC-Type attribute. This will then enable a client who can support, in this case, the Dublin Core metadata set, to extract the values from the attributes and process or display them appropriately. In many cases, the main aim of resolution is to get to the location of the resource. In this case, the URLs in the metadata will be used by the client to retrieve the resource.

Figure 1 shows an HTML document listing a number of technical reports published by the DSTC. Each report title is actually a link to a URN. For example, the bottom of the window displays the URN:

urn:inet:dstc.edu.au:rdu/tr007

Figure 1: Technical Report List

When the user selects this URN link on the HTML document, the URC information is then displayed (see Figure 2).

Figure 2: URC for Technical Report

The window shows the metadata describing the resource (in the top part of the window). The bottom section of the window shows the administrative metadata used. As can be seen in the Identifier attribute, there are two URLs for this conference paper, indicating that an HTML and Postscript version exists. The user can then choose which version of the paper they prefer and click on the link.

In future versions of WWW browsers, the URC information may not be seen directly by the user. For example, the user may customise their browser to indicate that they prefer to see the HTML version of any document received. Hence, in the above example, the user may have gone directly to the HTML version of the document.

The work described here has been undertaken as part of The URN Interoperability Project.

5 Migration to URNs and URCs

• Readily available URN resolvers. Toolkits should be made available to support the resolution of URNs. This could be part of the W3C Reference Library.

• WWW browser support for URNs. The current WWW clients need to support URNs in HTML documents. They should also provide mechanisms for the user to specify preferences on the types, formats, and locations of resources that they would like to be automatically retrieved.

• URC management software. Extensive software needs to be developed to support the management of document metadata. This will enable flexible metadata sets to be supported and also direct interaction with the URN resolvers. Spectrum (Vizine-Goetz 1995) is an example of a prototype system to support the description of metadata.

• Metadata research. Clearly work on different metadata sets needs to undertaken to support a wide range of resource types. In particular, administrative metadata should be investigated. For example, URC services based on SGML (Beckett 1995) metadata schemes have been proposed.

• URN interoperability experiments. With many different protocols available and useful for URN resolvers, a standard interoperability testbed should be developed and supported. (For example, see The URN Interoperability Project .)

<head>
<title>Dublin Core Syntax - DSTC Comments</title>
<meta name="DC.title" content="Dublin Core Syntax - DSTC Comments">
<meta name="DC.author" content="Renato Iannella">
<meta name="DC.subject" content="Metadata, Dublin Core, URN, URC">
<meta name="DC.date" scheme="ISO" content="1996-05-21">
<meta name="DC.identifier" scheme="URI" content="http://www.dstc.edu.au/RDU/reports/dc-imp.html">
<meta name="DC.form" scheme="IMT" content="text/html">
</head>
<body>
...
</body>

Two issues that are of key importance is that the window of opportunity is closing on URN deployment and that competing systems are being developed. Large commercial companies with browser products are in need of URNs - and could do it their own way if the IETF working groups are not ready to demonstrate deployable solutions. Other naming systems, like Persistent URLs are making claims for widespread adoption as a naming standard.

6 Conclusion

However, there are still many areas that need to be addressed. One key point is that we need to learn from the experiences with URLs and overcome these limitations in any future systems that will be deployed. URNs and URCs will become the foundation to many new and innovative services on the Internet. Hence, the need to fully support effective URN and URC management systems.

Acknowledgements

Bibliography

1

Beckett, D. (1995) IAFA Templates in use as Internet Metadata in Proceedings of the 4th International WWW Conference. Boston, Massachusetts, USA.
URL: http://www.w3.org/pub/Conferences/WWW4/Papers/52/

2

Berners-Lee, T. (1994) Universal Resource Identifiers in WWW: RFC1630, IETF Network Working Group.

2

Berners-Lee, T., Masinter, L. & McCahill, M. (1994) Uniform Resource Locators (URL). Request for Comments: 1738, IETF Network Working Group
URL: http://ds.internic.net/rfc/rfc1738.txt

3

Burnard, L., Miller, E., Quin, L. & Sperberg-McQueen, C.M. (1996) A Syntax for Dublin Core Metadata in Recommendations from the Second Metadata Workshop
URL: http://info.ox.ac.uk/~lou/wip/metadata.syntax.html

4

Daniel, R. (1995) An SGML-based URC Service. Internet Drafts.
URL: ftp://ietf.cnri.reston.va.us/internet-drafts/draft- ietf-uri-urc-sgml-00.txt

5

Dempsey, L. (1994) Network Resource Discovery: A European Library Perspective in Smith, N. (ed.) Libraries, Networks and Europe: A European Networking Study. British Library Research & Development Department, London.

6

Vizine-Goetz, D., Godby, J. & Bendig, M. (1995) Spectrum: a Web-based tool for describing electronic resources in Computer Networks and ISDN Systems, 27:985-1000.

7

Hoffman, P. (1995) The User Interface of URLs in Proceedings of INET95 - Annual Meeting of the Internet Society, Hawaii, 1:123-126.

8

Lagoze, C. (1996) The Warwick Framework - A Container Architecture for Aggregating Metadata Objects.
URL: http://cs-tr.cs.cornell.edu/~lagoze/warwick.htm

9

Lycos Catalogue of the Internet (1995).
URL: http://www.lycos.com/

10

Persistent Uniform Resource Locator (1996).
URL: http://purl.oclc.org/

11

Pitkow, J. & Jones, R. (1995) Towards an intelligent publishing environment in Computer Networks and ISDN Systems, 27:729-737.

12

Sollins, K. & Masinter, L. (1994) Functional Requirements for Uniform Resource Names: RFC1737, IETF Network Working Group.

13

The URN Interoperability Project (1995).
URL: http://www.dstc.edu.au/ RDU/TURNIP/

14

Alta Vista WWW Index (1995).
URL: http://www.altavista.digital.com/

15

W3C Reference Library Code (1995)
URL: http://www.w3.org/pub/WWW/ Library/

16

Weibel, S., Godby, J., Miller, E. & Daniel, R. (1995) OCLC/NCSA Metadata Workshop Report, Dublin, Ohio, USA.
URL: http://www. oclc.org:5047/oclc/research/conferences/metadata/dublin_ core_report.html

Return to Conference Proceedings