PRIDE Requirements and Success Factors Work Package 2 of Telematics for Libraries project PRIDE (LB 5624)

Title page Table of Contents Previous - Next

2.6 Meta-Information

2.6.1 SGML

2.6.1.1 Introduction

SGML is the Standard Generalised Markup Language, the international standard for defining descriptions of the structure and content of different types of electronic document. Essentially, SGML is a method for creating interchangeable, structured documents. It allows one to:

• assemble a single document from many sources (such as SGML fragments, word processor files, database queries, graphics, video clips, and real-time data from sensing instruments);
• define a document structure using a special grammar called a Document Type Definition (DTD);
• add markup to show the structural units in a document; and
• validate that the document follows the structure that was defined in the DTD. It is important to note, however, that SGML is not:
• a predefined set of tags that can be used to markup documents
• a standardised template for producing particular types of documents.

2.6.1.2 The components of SGML

SGML is based on the concept of document being composed of a series of entities. Each entity can contain one or more logical elements. Each of these elements can have certain attributes (properties) that describe the way in which it is to be processed. SGML provides a way of describing the relationships between these entities, elements and attributes, and tells the computer how it can recognise the component parts of a document.

SGML requires users to provide a model of the document being produced. This model, called a Document Type Definition (DTD), describes each element of the document in a form that the computer can understand. The DTD shows how the various elements that make up a document relate to one another.

To allow the computer to correctly identify where each part of a document starts and ends SGML requires that the user declares, in an SGML Declaration, how the computer is to identify markup, and what codes have been used to identify and delimit markup sequences.

2.6.1.3 SGML Systems

There are four general classes of tools in an SGML system, namely Editors, Conversion Tools, Document Managers, and Formatters.

• Editors use the SGML declaration to set the ground rules, the Declaration Subset to determine which tags are allowed to occur, and in what order they should occur, and may use an output specification for how they display the document to the user on screen or in a printed proof. Having this information allows the Editor to assist the user in creating valid document instances by allowing data to be entered with tags in the manner prescribed by the DTD. Additionally, some Editors include the function of a print formatter, in which case they will use a separate output specification for printing.
• Conversion tools typically have a mechanism for specifying how the elements and/or tags of a document are to be converted. Additionally, when conversion tools are being used to filter SGML data to some other format they typically need to take as input, the SGML declaration, declaration subset and instance. Having the declaration subset allows the conversion tool to know what to expect in the data, and to enable the tools to act on entire elements.
• Document managers come in many varieties. Some document managers work with whole documents. These tools often do not need any information about the contents of a file as they are just concerned with the management of the file. Other document managers will break the documents into components, based on user input and the declaration subset, and manage those components. Whether or not a document manager needs your DTD is a good clue to how the document manager will be working with you data.
• Formatters also come in many varieties. A common scenario is for the formatter not to use the DTD but just to act on the tags as they are encountered. These formatters use some type of output specification, which describes the formatting actions to take when encountering the tags. For example an electronic book product may have a style sheet which controls the generation of a table of contents and the screen presentation.

2.6.1.4 DSSSL

DSSSL (Document Style Semantics and Specification Language) is an International Standard, ISO/IEC 10179:1996, for specifying document transformation and formatting in a platform- and vendor-neutral manner. In particular, DSSSL can be used to specify the presentation of documents marked up according to the SGML standard.

DSSSL consists of two main components: a transformation language and a style language. The transformation language is used to specify structural transformations on SGML source files. For example, a telephone directory structured as a series of entries ordered by last name could, by applying a transformation spec, be rendered as a series of entries sorted by first name instead. The transformation language can also be used to specify the merging of two or more documents, the generation of indices and tables of contents, and other operations. While the transformation language is a powerful tool for gaining the maximum use from document databases, the focus in early DSSSL implementations will be on the style language component.

Within the style language, it is possible to identify a number of capabilities that for one reason or another should be considered optional for early implementations. Recognising this, the designers of DSSSL designated certain features of the style language as optional and created a Core Query Language and a Core Expression Language specifically in order to make more limited implementations possible. However, they did not define any particular subset of the style language component within the standard itself, but rather left that task to industry organisations and standards bodies.

2.6.1.5 Software

SP <URL:http://www.jclark.com/sp/index.htm> for SGML parsing and entity management. Here is a brief summary of its features:

• Provides access to all information about SGML document
  Access to DTD and SGML declaration as well as document instance
  Access to markup as well as abstract document
  Sufficient to recreate character-for-character identical copy of any SGML document
• Supports almost all optional SGML features
• Sophisticated entity manager
• Supports multi-byte character sets
  Parser can use 16-bit characters internally
  16-bit characters can be used in tag names and other markup
  Supports ISO/IEC 10646 (Unicode) using both UCS-2 and UTF-8
  Supports Japanese character sets (Shift-JIS, EUC)
• Object-oriented
• Written in C++ from scratch
• Reentrant
• Fast
• Portable
• All major Unix variants
  MS-DOS
  Win32: Windows 95/Windows NT
  OS/2
• Free
  Includes source code
  No restrictions on commercial use
• Disadvantages
  Programmer-level documentation only for generic API and not for native API.

SP and Jade can be used for conversion of SGML documents into other formats, such as XML, RTF, TeX, MIF, as well as to perform SGML transformations.

2.6.1.6 References

2.6.2 XML

XML is an abbreviated version of SGML, to make it easier to define custom document types, and to make it easier for programmers to write programs to handle them. It omits the more complex and less-used parts of SGML in return for the benefits of being easier to write applications, easier to understand, and more suited to delivery and interoperability over the Web. But it is still SGML, and XML files may still be parsed and validated the same as any other SGML file.

XML is designed "to make it easy and straightforward to use SGML on the Web: easy to define document types, easy to author and manage SGML-defined documents, and easy to transmit and share them across the Web."

It defines "an extremely simple dialect of SGML which is completely described in the XML Specification. The goal is to enable generic SGML to be served, received, and processed on the Web in the way that is now possible with HTML."

"For this reason, XML has been designed for ease of implementation, and for interoperability with both SGML and HTML."
<URL:http://www.w3.org/TR/REC-xml]>

2.6.3 HTML

2.6.3.1 Introduction

The Hypertext Mark-up Language (HTML) covers a set of standards defining document type definitions (DTD) corresponding to the various "official" versions of HTML. The standardisation procedure is W3C based though a number of Internet Drafts and RFCs represent the earlier evolution of HTML.

The latest W3C recommendation is HTML 4.0, which includes support for style sheets, frames, tables and forms. Internationalisation and accessibility issues are also represented in its design.

Although focus for the future has turned to XML, HTML will still be a key part of the web for some time. Notable developments in the evolution of HTML are covered below.

2.6.3.2 Forms

Forms where introduced in HTML 2.0 to interoperate with the CGI standard. A form is a template for a form data set (data captured by the browser which is sent to the server), an associated method (the HTTP method for uploading to the server) and an action URI (a reference to a server program that will process the form). The form data set is a sequence of name/value pairs, specified using form INPUT elements. Form submission usually results in the data set being transferred to the web server for processing.

2.6.3.3 The META element

Broadly, the META element can be used to identify properties of a document (e.g. author, expiration date, a list of keywords etc.) and assign value to those properties. Each META element specifies a name/value pair using the attributes name and content. Such usage is often used to provide keywords for indexing purposes, for example:

<META name="keywords" lang="en" content="national centre, network information support">

Note that in cases where the value for some property is a reference outside the document itself, the LINK element may be used, i.e. the following are equivalent:

<META name="DC.identifier" content="ftp://ds.internic.net/rfc/rfc1866.txt">

<LINK rel="DC.identifier" type="text/plain" href="ftp://ds.internic.net/rfc/rfc1866.txt">

Alternatively the http-equiv attribute can be used in place of the name attribute to create a header in the HTTP response. The value of the name attribute specifies the header name and the value of the content attribute its value. For example:

<META http-equiv="Expires" content="Sat, 31 Oct 1998 13:00:00 GMT">

will produce the following HTTP response header:

Expires: Sat, 31 Oct 1998 13:00:00 GMT

Some user-agents support the use of the refresh value for the http-equiv attribute to implement a simple form of client-pull.

The lang attribute can be used within the META element (as it can in many other HTML 4.0 defined elements) to specify the (human) language of the content attribute (this could be used, for example, for speaking browsers to pronounce words in various languages correctly).

The scheme attribute provides user agents with a context in which to interpret metadata. For example, to differentiate between different formats or to specify types of identifier. For example:

<META scheme="Month-Day-Year" name="date" content="08-24-98">

The META element may also be used to specify the defaults for scripting language, style sheet language and document character encoding.

The HEAD element may contain the profile attribute to specify the location of a metadata profile. Its value is a URI that is used by a user agent. Actions may then be taken by the user agent based upon definitions within the (dereferenced) profile.

2.6.3.4 Image maps

Image maps are inline images that include "hotspots" that operate like hyperlinks. An image map has three components: an image, appropriate HTML to specify an image map and map data.

Server-side maps appeared first, where maps are interpreted by the web server (i.e. the browser sends the server a set of coordinates corresponding to the clicked image region). Client-side maps have largely replaced these, where the map data is stored within HTML and the browser interprets the map. With the introduction of Java support within browsers, there is also the possibility of Java-based image maps.

2.6.3.5 Tables

HTML 3.2 implemented a widely deployed subset of the specification given in RFC 1942 - "HTML Tables" and can for the mark-up of tabular material or for layout purposes (although with the recent advent of style sheets and various accessibility issues this type of use is discouraged).

2.6.3.6 Frames

Frames were not an official HTML standard until the W3C HTML 4.0 specification but were deployed as browser extensions to the Netscape browser (and also later implemented by Microsoft Internet Explorer). Frames enable browser windows to be split into multiple independently scrollable windows with separate objects in each window.

2.6.3.7 Inline scripting languages

Support was introduced in the Netscape browser for the JavaScript scripting language developed by Netscape and Sun Microsystems. Javascript offered client-side scripting embedded within HTML and could be used to develop simple applications and to enhance user interfaces. Later Microsoft developed a version of JavaScript known as Jscript and provided support for Jscript and VBScript within their browser. Interoperability concerns prompted the standardisation of a scripting language by ECMA and the ECMAScript Language Specification was released in June 1997.

Initially, the scope of such object-oriented scripting languages within the HTML framework was limited due to the lack of an object model for the HTML language. The Document Object Model (DOM), developed by the W3C, addresses this issue by providing a non-proprietary API to a standard set of objects representing HTML and XML documents.

Dynamic HTML (DHTML) refers to the use of a scripting language within the DOM to remove previous restraints on functionality. DOM also addresses the inclusion of objects such as Java applets and ActiveX controls.

2.6.3.8 Style sheets

Style sheets were introduced to address the problem of layout within a document (since custom layout was not originally a concern of HTML). Cascading Style Sheets 1 (CSS1) was an initial W3C recommendation, but was only partly supported by Microsoft Internet Explorer. CSS2, released as a W3C recommendation in May 1998, provides a great deal of control over document appearance.

2.6.3.9 Implementation

2.6.3.9.1 HTML delivery

Flat HTML files were traditionally entirely written by hand. This results in problems such as invalid HTML (i.e. non-conformance to a DTD) and so the use of an HTML is generally recommended, a number of which a number now exist (including WYSIWYG systems). An editor can also better deal with large or complicated documents, provide versioning control and generate complex scripts. Packages such as Microsoft FrontPage integrate with a Microsoft server to provide many useful administrative and functional features.

HTML documents are traditionally stored as files accessible to server software that can serve resources via HTTP. There is however increasing use of storing (perhaps fragmented) HTML in a "back-end" database and serving the results of some database query to the client.

Prior to transfer of a document, scripting may be undertaken by the server to generate HTML (or other resources) which may entirely comprise what is served or add to other resources. Different servers (and platforms) may implement different kinds of server-side scripting, for example PHP, SSI and mod Perl under the UNIX apache server and ASP for Microsoft servers.

The CGI standard is also implemented server-side. On receiving a data set from a client, the server may operate on this and return a document, usually dynamically generated from the results of processing the data set. Java-based technologies may be used to provide richer functionality than CGI but at the cost of being more complicated to implement.

A web browser usually requests an HTML document from a server using the HTTP protocol. After receiving the contents (which may have been dynamically generated server-side), the browser can then process any objects such as scripts or style sheets (which may result in a client-side dynamic document).

A cache or proxy may bridge the route between client and server. It is possible that resources may be altered or generated at this stage.

Push technologies have recently become popular, where the traditional request-response paradigm is replaced by automatic delivery of resources to a suitable client (for example, news reports may be delivered to an "active desktop"). This may include HTML documents.

2.6.3.9.2 Accessibility

As the users of the Web continue to grow and become more diverse, various communities will have different abilities and skills. It is important to recognise that HTML needs to reflect this, for example being more accessible to those with disabilities. HTML 4.0 addresses a number of such issues, however much is down to the author of documents and guidelines exist covering the creation of accessible HTML.

2.6.3.9.3 Internationalisation

Internationalisation issues are important for creating a functional international Web. Issues broadly split into:

How characters within the text (not mark-up) should be able to represent non-western alphabets

Explicitly defining the language for a segment of text.

HTML 4.0 includes a number of internationalisation features and incorporates RFC2070. Features include support for rendering text written right to left and the LANG attribute for many HTML elements used to specify language. There are also features for specifying the character encoding of a document. Importantly, the ISO/IEC:10646 has been adopted as the document character set for HTML. This standard deals most inclusively with issues of representing international characters, text direction, punctuation and other world language issues.

2.6.3.10 Standards

Standards were initially deployed via Internet drafts and RFCs. Later the standardisation procedure became W3C recommendation based. Standards are not necessarily fully adhered to by browser manufacturers.

2.6.3.11 Comparisons and relevance

PRIDE will obviously be using HTML. Issues that may arise with this use include:

• Version of HTML to use
• Use of proprietary extensions/browser support
• Accessibility
• Internationalisation
• Design
• Use of HTML technologies (e.g. the META element)

2.6.3.12 Future developments

The W3C is now looking at the next generation of HTML. There is demand for HTML to provide support for television and mobile devices and to integrate more closely with database applications. It is considered that XML will provide the foundation for further HTML development.

There is work on defining HTML as a modular application of XML. Modularity will allow the integration of HTML with specialised tag sets for various applications (e.g. Maths) and to define profiles tailored to different device capabilities. There would also be back compatibility with previous HTML versions. Interoperability is also a key concern and this may be achieved with tools to transform documents into a form suitable for different browsers (e.g. transformed at an intermediate proxy). Core HTML elements would be complemented by modular specialised domain element sets. Accessibility, Internationalisation and standards issues would continue to be reflected in HTML development.

2.6.3.13 Related information

World Wide Web Consortium, <URL:http://www.w3.org>

Internet Engineering Task Force, <URL:http://www.ietf.org>

XML, <URL:http://www.w3.org/XML/>

HTML specifications and history, <URL:http://www.w3.org/MarkUp/>

RFC 1942: HTML Tables

JavaScript, <URL:http://developer.netscape.com/docs/manuals/index.html?content=javascript.html>

JScript

VBScript

ECMAScript

DOM, <URL:http://www.w3.org/Press/1998/DOM-REC/>

Java, <URL:http://java.sun.com/>

ActiveX

Style sheets, <URL:http://www.w3.org/Style/>

HTTP, <URL:http://www.w3.org/Protocols/>

HTTP-NG, <URL:http://www.w3.org/Protocols/HTTP-NG/>

PHP, <URL:http://www.php.net/>

Apache, <URL:http://www.apache.org/>

Microsoft IIS, <URL:http://www.microsoft.com/>

Resource Description Framework (RDF)

2.6.4.1 Introduction

The Resource Description Framework (RDF) is being developed by the W3C as a metadata framework that can be used by a variety of application areas such as: resource discovery, site-maps, Web collections, content rating, e-commerce and rights management, collaboration, privacy and Web-site management. RDF has been developed over the last year or so as part of the W3C's Metadata Activity and has received input from several communities including those working on content rating using PICS, Web collections, digital libraries (particularly the Dublin Core initiative), digital signatures (DSig) and Web privacy (P3P). RDF provides a generic metadata architecture that can be expressed in XML. The ultimate aim is that a machine understandable Web of metadata will be developed across a broad range of application and subject areas.

RDF is based on a mathematical model that provides a mechanism for grouping together sets of very simple metadata statements known as `triples'. These triples formally consist of a subject, a predicate and an object. The subject is the resource being described. The resource may be a Web page, a part of a Web page or a collection of pages (e.g. a whole Web-site). A resource may also be an object that is not directly accessible using the Web, for example a book. All resources described using RDF must be assigned a URI. The predicate is a property of the resource. The property is some aspect, attribute or characteristic used to describe a resource. The object is the value of the property. The value may be a literal (a string or number) or it may be some complex structure represented by other RDF triples.

The RDF model is often represented using node and arc diagrams. However, in order that RDF can be processed by computers, a serialisation syntax has been developed using the Extensible Markup Language (XML-RDF). A very simple example follows:

<rdf:RDF>
  <rdf:Description about="http://www.ukoln.ac.uk/">
    <Title>The UKOLN Home Page</Title>
  </rdf:Description>
</rdf:RDF>

The RDF model requires the semantics of metadata to be defined in an RDF schema. The schema allows software to take actions on RDF such as validation, mapping and value prompts. The RDF Model and Syntax Working group of the W3C are developing the RDF data model. The RDF Schema Working Group are developing an RDF Schema Definition Language.

2.6.4.2 Implementation

Several tools and software toolkits are beginning to be developed that support the creation and manipulation of RDF. These include:

2.6.4.2.1 Reggie

Reggie is a metadata editor that can output metadata in various formats, including XML-RDF. Reggie is implemented as a Web application using Java. Reggie allows the use of a schema to specify that structure of the metadata to be created. New schemas can be developed and referred to by URL within the editor. Reggie is being developed by DSTC.

2.6.4.2.2 DC-dot

DC-dot is a Web-based Dublin Core generator that automatically extracts metadata from a resource and then presents it for editing. DC-dot outputs Dublin Core in various formats including XML-RDF. DC-dot is being developed by UKOLN.

2.6.4.2.3 SiRPAC

SiRPAC is an RDF parser and compiler by Janne Saarela (W3C). It is written in Java. The SiRPAC compiler takes XML-RDF and generates the RDF triples of the underlying data model.

2.6.4.2.4 RDF for XML

RDF for XML is "a Java implementation of the RDF specification for creating technologies that search for, describe, categorize, rate, and manipulate data". RDF for XML is being developed by IBM Alphaworks.

2.6.4.3 Standards

The Resource Description Framework (RDF) Model and Syntax Specification and the Resources Description Framework (RDF) Schema Specification are both in the "last call" phase of W3C working draft documents.

2.6.4.4 Comparisons and relevance

The Dublin Core Data Model Working Group has been developing a data model for Dublin Core based on RDF. An example of the anticipated syntax for representing Dublin Core within RDF is given in the Dublin Core section of this document.

2.6.4.5 Future development

All metadata related activity within the W3C will be based on RDF from now on. It is expected that many other activities (for example the DOI developments related to metadata) will also use RDF as the basis for their work.

2.6.4.6 Related information

RDF Model and Syntax Specification, <URL:http://www.w3.org/TR/WD-rdf-syntax/>

RDF Schema Specification, <URL:http://www.w3.org/TR/WD-rdf-schema/>

Reggie, <URL:http://metadata.net/dstc/>

DC-dot, <URL:http://www.ukoln.ac.uk/metadata/dcdot/>

SiRPAC, <URL:http://www.w3.org/RDF/Implementations/SiRPAC/>

RDF for XML, <URL:http://www.alphaworks.ibm.com/formula/rdfxml/>

Dublin Core Data Model Working Group, <URL:http://purl.org/dc/groups/datamodel.htm>

2.6.5 Uniform Resource Identifiers (URIs)

2.6.5.1 Introduction

A Uniform Resource Identifier (URI) is a short string of characters that identifies a resource (in the abstract or physical sense). A URI provides a simple and extensible means for identifying a resource that can then be used within applications. The specification is derived from concepts introduced by the World Wide Web [RFC1630 - "Universal Resource Identifiers in WWW"] and builds upon previous notions such as URLs. URIs are a superset of Uniform Resource Locators (URLs), Uniform Resource Names (URNs) and Uniform Resource Citations or Uniform Resource Characteristics (URCs).

The URI specification implements the recommendations of RFC1736 - "Functional Recommendations for Internet Resource Locators" and RFC1737 - "Functional Requirements for Uniform Resource Names".

The following definitions from RFC2396 characterise the URI:

Uniform

The uniformity of URIs provides several benefits:

It allows different types of resource identifiers to be used in the same context (even though the mechanisms used to access the resources may differ).

It allows uniform semantic interpretation of common syntactic conventions across different types of resource identifiers (e.g. URLs start with a scheme representing the method of network access).

It allows the introduction of new types of resource identifiers without interfering with the way that existing identifiers are used.

It allows the use of identifiers to be reused in different contexts (this permitting new applications or protocols to leverage a pre-existing set of resource identifiers).

Resource

A resource is anything with identity, not necessarily network accessible. The term `resource' refers to the concept of the identified entity, so that a resource can remain fixed even when its content changes (for example, a noticeboard). An identified resource may not be instantiated at a given time.

Identifier

An identifier is an object that acts as a reference to something that has identity. For URIs, the object is a set of characters conforming to the URI syntax.

2.6.5.2 Implementation

A Uniform Resource Identifier may be a locator, a name or a metadata resource.

2.6.5.2.1 URLs

URLs identify resources via a representation of their access mechanism (usually network location) rather than by any other attribute of the resource. URLs have the most varied use of the URI syntax and often have a hierarchical namespace. A major disadvantage of URLs is that they confuse the name of a resource with its location. In the larger Internet information architecture URLs will act only as locators.

2.6.5.2.2 URNs

Whereas a URL identifies the location or container for an instance of a resource, a URN identifies the resource. The resource identified by a URN may reside in one or more locations, may move, or may not actually be available at a given time.

The URN has two interpretations, the first is as a globally unique and persistent identifier for a resource (achieved though an institutional commitment) that is accessible over a network; the second is as the specific `urn' scheme which will embody the requirements for a standardised URN namespace [RFC2141 - "URN Syntax"]. Such a scheme will resolve names that have a greater persistence that that currently associated with URLs.

RFC1737 - "Functional Requirements for Uniform Resource Names" identifies the following requirements for a URN:

Global scope

A URN is a name with global scope that does not imply a location. It has the same meaning everywhere.

Global uniqueness

A URN will be assigned to exactly one resource.

Persistence

The lifetime of a URN should be permanent (i.e. exist even when the resource no longer exists).

Scalability

URNs can be assigned to any resource available on the network.

Legacy support

The scheme must support existing naming systems. For example, ISBN numbers, ISO public identifiers etc. and allow an embedding that satisfies the syntactic requirements described here.

Extensibility

Any scheme for URNs must permit future extensions to the scheme.

Independence

It is solely the responsibility of a name issuing authority to determine the conditions under which it will issue a name.

Resolution

A URN will not impede resolution. For example, for URNs that have corresponding URLs, there must be some feasible mechanism to translate a URN onto a URL.

Naming schemes and resolution systems

A naming scheme is a system for creating and assigning URNs. A resolution system is a network-accessible service than maps a URN to a resource. A given URN can map to any type of URI (i.e. URL, URN or URC).

Independence of naming schemes and resolution systems

A naming scheme is not specific to some resolution system. Any resolution system is potentially capable of resolving a URN from any given name scheme.

URN registries

Mechanisms must be created for the user of a URN to discover what resolution systems are available to resolve the URN.

Syntax

Syntax has been generally agreed upon and is acceptable in all proposed naming schemes and resolution systems. A number of details still need to be agreed upon.

2.6.5.2.3 URCs

The internet draft "URC Scenarios and Requirements" defines the URC:

"The purpose or function of a URC is to provide a vehicle or structure for the representation of URIs and their associated meta-information".

Initially, URCs where the intermediate that associated a URN with a set of URLs that could then be used to obtain a resource. Later it was decided that metadata should also be included so that resources could be obtained conforming to a set of requirements. Although work has been carried out by the URC-WG, URCs are still not in existence.

URCs are descriptions of resources available via a network. Such a resource may have any number of locations. URCs provide a standard scheme for sites to provide descriptions, rather than relying on a central URC service. Because URCs are likely to describe a wide range of resources, there is no core set of descriptive attributes (such as author, title etc.). URC standards encourage the development of URC subtypes which are description schemes suited to particular domains.

2.6.5.3 Example applications Persistent URLs

Persistent URLs, or PURLs, were developed by OCLC as an interim naming and resolution system for the Web. PURLs increase the probability of correct resolution and thereby reduce the burden and expense of catalog maintenance.

A PURL is a URL. However, a PURL refers to a resolution service, which maps the PURL to a URL and returns this to the client. On the Web, this is a standard HTTP redirect.

2.6.5.4 Standards

Internet addressing standards are IETF based. A number of other standards may form part of private conventions.

2.6.5.5 Comparisons and relevance

PRIDE may want to look at how URNs could be used within its architecture.

2.6.5.6 Related information

RFC1630: Universal Resource Identifiers in WWW

RFC1736: Functional Recommendations for Internet Resource Locators

RFC1737: Functional Requirements for Uniform Resource Names

RFC2141: URN Syntax

RFC2396: Uniform Resource Identifiers (URI): Generic Syntax

W3C addressing page, <URL:http://www.w3.org/Addressing/>

TURNIP, the URN Interoperability Project, <URL:http://www.dstc.edu.au/RDU/TURNIP/>

DOI Foundation, <URL:http://www.doi.org>

PURL homepage, <URL:http://purl.oclc.org>

2.6.6 Digital Object Identifier (DOI)

2.6.6.1 Introduction

The Digital Object Identifier (DOI) has been developed by the International DOI Foundation (IDF) on behalf of the publishing community to provide an identifier for intellectual content in the digital environment. Its goals are to provide a framework for managing intellectual content, link customers with publishers, facilitate electronic commerce, and enable automated copyright management.

The DOI system has two main parts (the identifier and a directory system) and a third logical component, a database.

2.6.6.1.1 The identifier

The identifier has two parts, a globally unique part called the prefix and a publisher assigned part called the suffix. For example, the DOI

10.153/34571

2.6.6.1.2 The directory

The DOI system is based on a distributed central directory. Currently DOIs are usually embedded into URLs. When a user clicks on such a URL, a message is sent to the DOI directory where the URL associated with that DOI is stored. This location is sent back to the user's Internet browser as an HTTP redirect -- a special message telling the browser to "go to this particular URL".

The underlying technology for the DOI directory is the Handle resolution system developed by the Corporation for National Research Initiatives (CNRI). The Handle System is a distributed system that stores names (handles) of digital objects and which can resolve those names into locators (URLs) to access the objects. The system is global and general purpose and is used over networks such as the Internet. The Handle system is currently in use in a number of other prototype projects.

2.6.6.1.3 The database

Information about an object that is identified by a DOI is maintained by the publisher. However, it is planned that the DOI system will also collect some minimum level of associated metadata to enable provision of automated, efficient services such as look-up of DOIs from bibliographic data, citation linking, and so forth.

2.6.6.2 Implementation

It is currently difficult to determine how widespread the implementation of the DOI is. However, IDF members include major industry players in a range of technology and content industries. The Board of the Foundation, elected by and from the membership, currently consists of the Association of American Publishers, International Publishers Association, International Association of STM Publishers, Authors Licensing and Collecting Society, Elsevier Science, European Music Rights Alliance, Microsoft, New England Journal of Medicine, and Wiley.

DOIs are currently embedded into Web pages as URLs. In this way they can be resolved using any Web browser. A Handle browser plug-in is also available which can resolve DOIs directly. Some experimental work has also been done, encoding DOIs as URNs and resolving them using HTTP proxy servers.

2.6.6.3 Standards

The DOI syntax is being standardised within NISO. The IDF is also working closely with ISO (the ISWC working group) and with the URN working group of the IETF. In its discussions about metadata, the IDF is working with the Dublin Core initiative and the W3C RDF working group.

2.6.6.4 Comparisons and relevance

The DOI is closely related to other bibliographic identifiers such as the ISBN, ISSN and SICI. It is currently used in the form of a URL and is resolved in a very similar way to the Persistent URL (PURL).

2.6.6.5 Future development

One aspect of the DOI that is currently under discussion within the IDF is the issue of what metadata about the objects identified by a DOI should be held within the DOI directory. This discussion is bringing together several interested parties, including representatives of the Dublin Core initiative, the W3C RDF working group, publishers and copyright licensing agencies. Some of this discussion is likely to take place within the framework of the European funded Interoperability of Data in E-Commerce Systems (INDECS) project.

2.6.6.6 Related information

* International DOI Foundation, <URL:http://www.doi.org/>

<rdf:RDF
  xmlns:rdf=http://www.w3.org/TR/WD-rdf-syntax#
  xmlns:dc="http://purl.org/dc/elements/1.0/">
  <rdf:Description about="http://www.ukoln.ac.uk/">
    <dc:Title>
      UKOLN: UK Office for Library and Information Networking
    </dc:Title>
    <dc:Creator>
      UKOLN Information Services Group
    </dc:Creator>
    <dc:Subject>
      national centre, network information support, library community,
      awareness, research, information services, public library networking,
      bibliographic management, distributed library systems, metadata,
      resource discovery, conferences, lectures, workshops
    </dc:Subject>
    <dc:Description>
      UKOLN is a national centre for support in network information
      management in the library and information communities. It provides
      awareness, research and information services
    </dc:Description>
    <dc:Publisher>
      Bath University
    </dc:Publisher>
    <dc:Type>
      Text
    </dc:Type>
    <dc:Format>
      text/html - 10907 bytes
    </dc:Format>
  </rdf:Description>
</rdf:RDF>

Item segment<Contribution segment>Control segment