AppropriateLinks

From oaibp

Revision as of 20:31, 26 June 2007 by Khage (Talk | contribs)
(diff) ←Older revision | Current revision (diff) | Newer revision→ (diff)
Jump to: navigation, search

Main Page >> Shareable Metadata

[edit] Linking from a Record to a Resource and Other Linking Issues

Note to Reviewers: Naomi Dushay edited this page on Sept 20 2005
Note: Summary of best practices added. Jenn Riley 10/11/05
Note: Added character encoding reference. Sarah Shreeves 10-12-05

[edit] Summary of Best Practices

  • URIs in OAI metadata records should permanently point to the resource being described.
  • URIs in OAI metadata records should include indication of the protocol used.
  • Provide a single URL pointing to a resource in appropriate context.

For the most part, the metadata exposed via OAI describes internet accessible resources, i.e. the metadata contains a URL(s) that leads a user to the digital resource. This is not always the case: some OAI repositories contain metadata that describes analog resources which are not available digitally. Either way, appropriate links are an important piece of the ultimate shareability of the record. In the case of metadata describing digital resources, the location to which users are sent after clicking on a URL is of critical importance for the end users, but also affects the credibility of both the data and service providers. It is the URL(s) that most often links the metadata record in the service provider's aggregation with the actual resource in the data provider's repository. Send the user to the wrong place ' or to an empty page ' and they may leave both the data and the service provider's sites altogether. End users may also become frustrated if they must wade through many layers of indirection (i.e. many mouse clicks) before viewing the resource itself.

A metadata record may describe a single resource available as a single digital file. As discussed in the section on [[DigitalTactileResource]|Describing Versions and Reproductions]], a single intellectual resource can have multiple representations or versions. Resources may also have multiple parts (as discussed in Granularity of Description, such as multi-page texts. A metadata record describing an analog resource may have a URL pointing to the institution's homepage. Metadata records may also include URLs to pages describing conditions of use or copyright information for the resource. Thus, numerous links may be included in a single metadata record.

As a result of this variability, the specific level of representation a URL should point to can not easily be prescribed but the following best practices should be followed whenever possible.

In all cases, it is best practice to use some form of permanent URL (such as a PURL or a resolvable DOI) if possible. If this is not possible, it is best practice to keep URLs up to date within the metadata available via an OAI data provider. Link rot is a significant problem for service providers, and one that is entirely out of their control except through the reharvest of metadata from the data provider.

Strictly speaking, a URL (http://www.w3.org/Addressing/URL/Overview.html) must be a valid URI (http://www.ietf.org/rfc/rfc2396.txt and http://www.ietf.org/rfc/rfc2732.txt; also see http://www.ietf.org/rfc/rfc3986.txt). Implementers should refer to the most current documentation to determine which characters are reserved and unreserved and which may need to be escaped. URIs require that non-ASCII characters and some ASCII characters be escaped. In practice, this may require special treatment of certain characters, such as spaces, in URLs. See also Character Encoding Issues.

It is a best practice to include the appropriate scheme prefix (i.e. http://, ftp://, etc.).

URLs that point to digital resource(s)

It is best practice to provide one, primary URL that is a link to the resource with its contextual material (e.g. metadata, navigation to the collection homepage). For example, in the case of a Dublin Core record, a single <dc:identifier> element should contain the URL that points to the resource. In the case of a MODS record, that element would be <location> with the sub-element <url>. These elements would not be repeated unless with information that is not a URL (for example, an ISBN).

The use of one primary URL allows service providers to know what URL to provide as the link to the resource. In cases of multi-part resources or resources with multiple manifestations, this best practice means that data providers must make a decision about what is the most relevant or appropriate place for a user to get access to the resource. Secondary URLs that take users to other versions or manifestations of the resource should be included in other elements (such as <dc:relation>).

Contextual material is important because many service providers do not display the full metadata record harvested from a data provider. Thus, if the primary link to a resource is to a stand-alone version of the resource (such as a JPG image only), an end user will have no context except for the metadata on the service provider's site. This does not serve the end-user well nor does it serve the data provider well as the end-user cannot easily navigate to other parts of the data provider's collection. At minimum, the URL should point to a page that contains the resource and a navigation bar that allows user to reach the collection homepage. It is highly desirable that this page also include the descriptive metadata for the resource.

If it is not possible to provide a URL that links to the resource, the end-user should be able to access the resource with a minimum number of clicks (at most 2) with a minimum amount of effort. For example, in the case of the arXiv.org data repository, the URL provided takes the user to a page with basic metadata and a selection of formats to choose from (see http://arxiv.org/abs/chem-ph/9403001 as an example) - the resource is only one click away.

It is particularly bad practice to include as the primary URL for a resource the collection homepage with the expectation that the end-user will conduct what is probably an additional search to find the relevant resource. End-users' frustration with this particular practice is described in Shreeves and Kirkham 'Experiences of Educators Using a Portal of Aggregated Metadata' in Journal of Digital Information, http://jodi.tamu.edu/Articles/v05/i03/Shreeves/:

[The subjects] reported a significant slowing of their efforts when a pointer, or active link, within a record led them to another institution's Web site in which they had to execute an additional search. The subjects clearly believed that a live URL in a search result should immediately display the digital object of interest. One student described the interaction as being comparable to going to McDonald's "and upon walking up to the counter the employee hands across directions to Burger King across town".

Metadata records describing analog resources

If there is not a digital object available, this should be indicated in the metadata and either contact information for the institution or collection or a URL to a page with this contact information should be provided. However, it is best practice to clearly distinguish this URL from those that will lead a user to digital content. For example, in a Dublin Core record a URL to an institution or collection homepage should not be included in the <dc:identifier> element but in the <dc:relation> element. In a MODS record, the <location> element and <physicalLocation> sub-element should be used, not the <url> sub-element. This helps to mitigate confusion for users and service providers.

Other links in metadata records

There are other links that may be included in metadata records including:

  • conditions of use
  • copyright information
  • access restrictions
  • collection or institution homepage
  • email addresses for contacts
  • related resources or collections

In all cases, the links should be current and clearly distinguished from the primary URL for the resource described by including these in elements other that that used by the primary URL.

See also Identifiers.

Personal tools