ROADS

Using ROADS for Web-site Metadata Management

Introduction

This document proposes a way in which a ROADS database can be used to manage Dublin Core metadata across a Web-site. It suggests that records describing local resources are stored in a ROADS database and then embedded into HTML META tags using a Server Side Include (SSI) script as the pages are served.

A similar system, based around SOIF records, is currently in use at UKOLN to embed metadata into Ariadne articles for the NewsAgent project. That system was described in some detail in Metadata Management in Ariadne Issue 10. It uses a Microsoft Access based front-end to create the SOIF records that are stored next to HTML or other resources in the Web-site file system.

ROADS

The ROADS software provides a set of primarily Web-based tools for creating, maintaining and searching collections of descriptions of Internet resources. Descriptions are held in ROADS records, typically based on the DOCUMENT and SERVICE ROADS templates. The ROADS software is commonly used to build 'subject gateways'; searchable indexes of Internet resources in a particular subject area.

The DUBLINCORE Template Type

The proposed DUBLINCORE ROADS template type means that the ROADS software can be used to build a simple 'Dublin Core' database. The DUBLINCORE template contains attributes for all 15 DC elements and for all the sub-elements proposed by the DC sub-groups set up after the 5th Dublin Core meeting in Helsinki. Some attributes have an associated SCHEME as proposed in Dublin Core Qualifiers/Substructure : a proposal.

As with other ROADS templates, each DUBLINCORE record contains a 'Handle' that uniquely identifies that record.

Server Side Include Scripts

An SSI script is a script or other program (typically a Perl script) that is run by a Web server as it serves a Web page. The 'call' to the SSI script is embedded into the Web page using a syntax that is specific to the Web server. Any text produced by the script is embedded into the Web page at the point that the script was called. Often such scripts are used to wrap standard HTML headers and footers around every page on a Web server.

A Perl script is available, roads2metadc.pl, that reads a ROADS DUBLINCORE template and converts it to HTML <META> tags.

The script can also be used as an SSI script. However, when it is used in this way it must have some method of determining which ROADS template to convert for a particular HTML page. Two ways of doing this are proposed:

When a Web server runs an SSI script, it provides the URL of the HTML page that it is serving as part of that process' environment. The script can read this information from its environment, use it to search the ROADS database, and convert the resulting 'hit' into embedded HTML META tags.
Alternatively the 'Handle' (identifier) of the ROADS record associated with each HTML page could be explicitly passed to the SSI script as an argument by embedding the 'Handle' into the HTML source of the page. This approach will be much more efficient because the SSI script can read the ROADS record directly from disk, assuming that it knows where records are found, without having to search the database first.

The above script will implement both options - it currently only implements the second one. The second option is recommended for use on real Web servers.

Unique Identifiers

The ROADS record 'Handle' has been proposed as the way in which a resource (an HTML Web page) and its metadata (ROADS record) can be tied together. The ROADS database could also be used to maintain a set of unique identifiers, for example DOIs or PURLs, for the resources on a Web-site. Such identifiers could be based on the ROADS 'Handle' or could be generated according to some other scheme. For example a ROADS 'Handle' of:

    885679460-360

might be used to form a new PURL:

    http://purl.ukoln.ac.uk/885679460-360

or DOI:

    10.1352/885679460-360

The new identifier would be stored in a second 'Identifier' attribute, along-side the URL.

Identifiers held in a ROADS database in this way could be used as the basis for the data loaded into a PURL server or sent to the DOI Agency.

Usage scenario

How will the system be used?

A Web author will create an HTML page in the normal way.
They will then use the normal ROADS tools to create a DUBLINCORE description of the page. This can be as simple or as complex as required. The 'Title' and one 'Identifier' (the URL of the page) should be considered mandatory. Other 'Identifier's can be supplied if necessary (see above).
The author then re-edits the Web page, embedding the call to the SSI script somewhere in the <HEAD> section of the page, optionally giving the 'Handle' allocated to the record in the previous step as an argument.
If the ROADS database is also being used as the basis for an identification system then some mechanism for updating that database will have to be followed, for example updating the PURL database or sending a new DOI to the DOI Agency.

Example of use

The 'UKOLN Web pages' ROADS database contains a DUBLINCORE record for the UKOLN metadata home page. The record looks like this:

Template-Type:	DUBLINCORE
Handle: 885679460-360
Template-Version: 1
Title: UKOLN Metadata
Title-Alternative-v1: 
Title-Alternative-v2: 
Creator-v1: Andy Powell
Creator-v2: Michael Day
Creator-Address-v1: a.powell@ukoln.ac.uk
Creator-Address-v2: m.day@ukoln.ac.uk
Creator-PersonalName-v1: 
Creator-PersonalName-v2: 
Creator-CorporateName-v1: 
Creator-CorporateName-v2: 
Creator-PersonalName-Address-v1: 
Creator-PersonalName-Address-v2: 
Creator-CorporateName-Address-v1: 
Creator-CorporateName-Address-v2: 
Subject-v1: metadata, BIBLINK, DESIRE,NewsAgent, ROADS, Dublin Core, DC, Z39.50, Whois++, RDF, XML, CDF
Subject-v2: 
Subject-Scheme-v1: 
Subject-Scheme-v2: 
Description-v1: 
Description-v2: 
Publisher-v1: UKOLN, University of Bath
Publisher-v2: 
Publisher-Address-v1: 
Publisher-Address-v2: 
Publisher-PersonalName-v1: 
Publisher-PersonalName-v2: 
Publisher-CorporateName-v1: 
Publisher-CorporateName-v2: 
Publisher-PersonalName-Address-v1: 
Publisher-PersonalName-Address-v2: 
Publisher-CorporateName-Address-v1: 
Publisher-CorporateName-Address-v2: 
Contributor-v1: 
Contributor-v2: 
Contributor-Address-v1: 
Contributor-Address-v2: 
Contributor-PersonalName-v1: 
Contributor-PersonalName-v2: 
Contributor-CorporateName-v1: 
Contributor-CorporateName-v2: 
Contributor-PersonalName-Address-v1: 
Contributor-PersonalName-Address-v2: 
Contributor-CorporateName-Address-v1: 
Contributor-CorporateName-Address-v2: 
Date-v1: 
Date-v2: 
Date-CreationIntellectualContent-v1: 
Date-CreationIntellectualContent-v2: 
Date-CreationModificationPresentForm-v1: 
Date-CreationModificationPresentForm-v2: 
Date-Available-v1: 
Date-Available-v2: 
Date-Valid-v1: 
Date-Valid-v2: 
Date-Acquisition-v1: 
Date-Acquisition-v2: 
Date-Accepted-v1: 
Date-Accepted-v2: 
Date-DataGathering-v1: 
Date-DataGathering-v2: 
Type-v1: Text.Homepage
Type-v2: 
Format-v1: text/html
Format-v2: 
Identifier-v1: http://www.ukoln.ac.uk/metadata/
Identifier-v2: 
Identifier-Scheme-v1: 
Identifier-Scheme-v2: 
Source-v1: 
Source-v2: 
Source-Scheme-v1: 
Source-Scheme-v2: 
Language-v1: en-uk
Language-v2: 
Language-Scheme-v1: 
Language-Scheme-v2: 
Relation-v1: 
Relation-v2: 
Relation-Scheme-v1: 
Relation-Scheme-v2: 
Coverage-v1: 
Coverage-v2: 
Coverage-PeriodName-v1: 
Coverage-PeriodName-v2: 
Coverage-PlaceName-v1: 
Coverage-PlaceName-v2: 
Coverage-T-v1: 
Coverage-T-v2: 
Coverage-X-v1: 
Coverage-X-v2: 
Coverage-Y-v1: 
Coverage-Y-v2: 
Coverage-Z-v1: 
Coverage-Z-v2: 
Coverage-Polygon-v1: 
Coverage-Polygon-v2: 
Coverage-Line-v1: 
Coverage-Line-v2: 
Coverage-ThreeD-v1: 
Coverage-ThreeD-v2: 
Rights-v1: 
Rights-v2: 
Rights-Scheme-v1: 
Rights-Scheme-v2: 
To-Be-Reviewed-Date: 
Record-Last-Verified-Email: 
Record-Last-Verified-Date: 
Comments: 
Destination: 
Record-Last-Modified-Date: Sat, 24 Jan 1998 22:08:17 +0000
Record-Last-Modified-Email: unknown@ppp12-annex.bath.ac.uk
Record-Created-Date: Sat, 24 Jan 1998 22:08:17 +0000
Record-Created-Email: unknown@ppp12-annex.bath.ac.uk

The HTML source for the UKOLN metadata home page contains the line

    <!--#exec cmd="/opt/metadata/roads/ukoln/bin/roads2metadc.pl 885679460-360" -->

somewhere in the HEAD section of the page. This tells the UKOLN Apache Web server to run

    /opt/metadata/roads/ukoln/bin/roads2metadc.pl 885679460-360

when the page is served. roads2metadc.pl produces

<!-- Start of roads2metadc metadata -->
<META NAME="DC.Identifier" CONTENT="http://www.ukoln.ac.uk/metadata/">
<META NAME="DC.Publisher" CONTENT="UKOLN, University of Bath">
<META NAME="DC.Title" CONTENT="UKOLN Metadata">
<META NAME="DC.Subject" CONTENT="metadata, BIBLINK, DESIRE,NewsAgent,
ROADS, Dublin Core, DC, Z39.50, Whois++, RDF, XML, CDF">
<META NAME="DC.Creator" CONTENT="Andy Powell">
<META NAME="DC.Creator" CONTENT="Michael Day">
<META NAME="DC.Type" CONTENT="Text.Homepage">
<META NAME="DC.Creator.Address" CONTENT="a.powell@ukoln.ac.uk">
<META NAME="DC.Language" CONTENT="en-uk">
<META NAME="DC.Creator.Address" CONTENT="m.day@ukoln.ac.uk">
<META NAME="DC.Format" CONTENT="text/html">
<!-- End of roads2metadc metadata -->

which is then embedded into the page.

Resource Description Framework (RDF)

The above script also, experimentally, supports the generation of an XML representation of RDF. By issuing the command

    /opt/metadata/roads/ukoln/bin/roads2metadc.pl -r 885679460-360

we get

<?xml:namespace href="http://purl.org/RDF/" as="RDF"?>
<?xml:namespace href="http://purl.org/RDF/DC/" as="DC"?>
<RDF:RDF>
  <RDF:Description RDF:HREF="http://www.ukoln.ac.uk/metadata/">
    <DC:Identifier>http://www.ukoln.ac.uk/metadata/</DC:Identifier>
    <DC:Publisher>UKOLN, University of Bath</DC:Publisher>
    <DC:Title>UKOLN Metadata</DC:Title>
    <DC:Subject>
      metadata, BIBLINK, DESIRE,NewsAgent, ROADS, Dublin Core, DC, Z39.50,
      Whois++, RDF, XML, CDF
    </DC:Subject>
    <DC:Creator>Andy Powell</DC:Creator>
    <DC:Creator>Michael Day</DC:Creator>
    <DC:Type>Text.Homepage</DC:Type>
    <DC:Language>en-uk</DC:Language>
    <DC:Format>text/html</DC:Format>
  </RDF:Description>
</RDF:RDF>

Note that this is of no practical value! RDF is still under development so this representation is likely to be completely wrong! It is offered here for example purposes only. Furthermore, the RDF shown here is a simplified view of the metadata in the original ROADS record. More work is needed on RDF generation.

Maintained by: Andy Powell
Last updated: 10-Jun-1998

[Metadata] [UKOLN]