PERSISTENT IDENTIFICATION
SYSTEMS
Part 2 : Persistent Identifiers and the NLA
There are three aspects to the issue of persistent naming in the context of distributed digital information systems that must be addressed by the NLA:
- the semantics of the identifier itself.
- the issue of resolving the identifier to a resource or to further information on how to access the resource (metadata, another file, an html file etc. )
- the issue of encouraging others to share responsibility for maintaining persistence of citations and to join a national system.
Of these, the more difficult are those relating to the issue of resolution in a distributed system. All numbering systems posited which match the URN requirements accept as a basic premise that the naming and assignment rules are the domain of the owner of the resource, or naming authority, and they prescribe no semantics other than a basic syntax to enable the number to be identified uniquely in a global context (and to give some clue as to how the identifier might be routed for resolution). Beyond that, all that is required is that the name be unique within the area of responsibility of the naming authority.
2.1 Requirements for a national persistent identifier system in Australia
In developing a national persistent identifier system, the following questions need to be considered:
- What are the optimal organisational arrangements for a national persistent identifier system?
- What should be the syntax of the persistent identifier?
- What are the options for resolution?
2.1.1 Organisational arrangements
Australia has a federal system of government with a traditional distrust of central control. It is therefore likely that a model in which responsibility for the management of the system is devolved to the owners of the resources is likely to be more widely acceptable than a fully centralised system, provided that it is well supported and easy to maintain. Such a system also has the advantage that it encourages organisations and individuals to take responsibility for the persistence of the resources they own rather than fostering the assumption that once registered with another agency, all responsibility for the management of the resource is discharged.
It is therefore recommended that any model adopted by the NLA for a persistent naming service to Australian institutions should be a distributed one in which NLA takes responsibility for:
- Managing the naming system and registering participating organisations as naming authorities.
- Establishing, at an appropriate time, a resolving service that would redirect requests based on the persistent identifiers to the appropriate naming authority for local resolution by the naming authority.
- Providing the option of central resolution for those who cannot undertake it locally.
- Providing advice and support for users of the service.
Organisations wishing to participate in such a system would be responsible for:
- Registering with the central body at NLA.
- Identifying those resources they believe merit long term attention to maintain persistence of access.
- Assigning persistent identifiers to those resources.
- Establishing procedures to maintain a local resolving service to direct requests for resources they have named to their current locations.
2.1.2 Syntax and semantics of a national identifier
There should be no requirement for uniformity beyond that required for a URN, namely that the namespace identifier or naming authority be globally unique and that the namespace specific string be unique within an authoritys namespace. Different organisations have different naming requirements for different categories of material and maximum flexibility and autonomy within the system is more likely to encourage early adoption.
2.1.3 Resolution of a national identifier
It is not desirable that all persistent identifiers in a national system are resolved centrally. Ideally, if NLA plays a role in resolution, it should be through a resolver discovery service redirecting requests for local resolution by the naming authority that named and manages the resource.
This will involve operating a registration system that will record the allocation of namespace identifiers together with a resolution system that will allow identifiers to be resolved into the resource itself or to meaningful citations.
2.2 Options for a [national] system
There is no obvious path for NLA to follow in the area of persistent identifiers. No identifier systems today will provide the functionality required for a national distributed digital archive, and any system implemented at the present time will have at least some aspects which make it less than ideal until current browsers are able to recognise and route location and protocol independent identifiers.
The issue of resolution of the identifiers remains problematic.
As stated earlier (See Section 1.3.3), currently there is no deployed resolution system for URNs, or other name style persistent identifier systems such as DOI or handles without the use of a proxy server. This means that identifiers such as urn:nbn . or hdl: or doi:10.1006/rwei.1999.0001 cannot be resolved unless the address of a proxy server is included as part of the identifier in the link. The result is identifiers such as http://urn.nbn.org.au/urn:nbn:au.nla/12345 or http://hdl.loc.gov/ or http://doi.org/ . This defeats the purpose of having location and protocol independent identifiers, since the protocol and address of the proxy server are present with the identifier when a link is created.
If a proxy server is not used, systems such as the Handle system and DOI, which have a built in resolution scheme, require the installation of a browser plug-in to enable a standard web browser to recognise the identifier and make the appropriate routing to a Handle server. Many users are reluctant, or do not have the confidence, to download and install plug-ins.
There are a number of options currently available to the NLA to implement a persistent identifier scheme. None of these are ideal for reasons discussed earlier, nor are any of the models discussed sufficiently compelling to totally exclude consideration of the others. The possible options considered here are:
- Use standard redirects
- Continue with a simple resolving system such as PURL
- Proceed with a URN style implementation using a proxy server
- Implement a handle server
- Adopt the DOI system
All of the options provide varying degrees of location independence, (i.e. the name of the item is unrelated to the physical location of the item) and persistence if the links are properly managed. It is important to note in this context that persistence is a function of organisation and management, not technology. Whatever system is used will require commitment to manage the naming and maintain the relationship between the name and location of the resource.
2.2.2 Use standard redirects
The simplest option is to use standard redirects to map all requests to the current location of a resource if it is moved from its original location. This is used at present on the NLA and many other websites.
Advantages
- It is the simplest to implement
- Standard redirects require no software changes or new standards.
- It is low cost and low risk
Disadvantages
- There is no indication from the URL that the link is a managed link that is maintained by an organisation with a commitment to persistence of access to the resource.
- It can supply one on one resolution only and cannot support multiple resolution
- It is tied to existing protocols
- It is a single site option and does not facilitate development of distributed naming systems
- Because there are no management tools, it can be difficult to keep track of redirects.
2.2.3 Continue with a simple resolving system such as PURL
The NLA has already installed a PURL server. As a national system, this has not been particularly successful, partly because it has not been widely publicised and partly because the publicity it has been given has been largely in the context of archiving material, rather than in the broader context of persistence of citation.
Advantages
- The Library already has experience with a PURL resolver system.
- PURL indicates commitment on the part of the assigner of the identifier to the persistence of the name, and by extrapolation, the resource.
- It is a simple solution with minimal investment. It uses standard HTTP redirects and URLs
- It can be deployed in a central or decentralised model with many organisations installing their own PURL server.
- PURL server has an advantage over a standard redirects in that it comes with a collection of utilities that support the management of URLs by allowing users to update their own resource, a critical aspect of assuring the integrity and maintenance of links.
- May be migrated to another URN system with the caveat that a dual system would be required indefinitely to support older PURLs.
Disadvantages
- Is not location independent
- Is protocol dependent - it is a URL implementation using standard http redirect.
- It can only support a one to one resolution as it is based on a redirect; it would be difficult to support one to many resolution, e.g. multiple instances or multiple versions.
- Standard browsers return the URL in the location field. This would in many cases become the citation unless the PURL is clearly indicated on or in the object itself or browsers are modified to display the persistent URL that was requested rather than the actual URL representing the current location of the resource.
Use of the PURL option would be the simplest option and would require little effort beyond more active promotion and a closer examination of its use on the NLA site together with the development of implementation guidelines for the NLA site. If PURL were adopted, and the Library intends to provide a service for others, it might be worthwhile to generalise the domain name to be used for non-NLA resources by removing the nla and replacing it with something like purl.org.au. This may be more attractive to users.
If the NLA were to follow this path, it would also be worthwhile to encourage others to set up their own PURL resolvers to assist in managing their resources.
2.2.4 Proceed with a URN style implementation.
URN
As outlined earlier, there is no resolution infrastructure that can support URN or any other name style identifiers. If URN were implemented in the near to medium term, the identifiers could only be resolved using an http proxy server. Nevertheless, the use of URN style identifiers would have some advantages over the use of a URL as a persistent identifier.
Advantages
- Flexibility of the naming system.
- Independence of a particular protocol and location.
- A URN used this way could still refer to multiple instances of an item.
- Supports centralised and decentralised model.
- Can accommodate existing identifier schemes easily.
- Will differentiate from URL and address based schemes and implies commitment to persistence of access on the part of the assigner.
Disadvantages
- No significant deployment and no resolution service for URN identifiers.
- Uncertain deployment prospects (See section 1.3.4)
- Not accessible using standard browsers except through a proxy server.
- No browser plug-in available.
- No administration and management tools currently available.
NBN (National Bibliography Number)
If the National Library opts for an URN style implementation, it may feel committed to the use of the NBN, having agreed to support its registration and further development at a meeting of CDNL. There is some advantage to be gained from using the NBN:
- It identifies a namespace with the qualities required, i.e. it is maintained by stable organisations committed to the persistence of the resources for which they use the identifier.
- It fits within the URN syntax [but see below].
On the other hand:
- There is as yet (as with other URNs) no resolution service available for resolving the identifiers.
- The name National Bibliography Number is a little limiting and does not fit well with the full range of resources described by NLA. NPI (National Persistent Identifier) or NPN (National Persistent Name) might be a better option and more accurately reflect the range of resources which will be described using the identifier.
- The use of the namespace identifier (NID) NBN adds a level of indirection for what are essentially many separate namespaces defined by a combination of the NID and the country code prefix of the namespace specific string (NSS), which is designed to be transparent and resolvable locally. Resolution of the NBN to the correct local national library or naming authority will require some decision based on the country code in the namespace specific string itself. An alternative might be to register the names as separate namespaces or sub namespaces, e.g urn:nbn.fi:fe12345, urn:nbn.au:nla.pic56789 urn:nbn.lccn:200034567. CDNL could still act as the owner of the extended namespace(s).
If the NBN is used how does it fit into the general requirements?
Bearing in mind the above, it would be possible to implement the NBN to accommodate the distributed service model envisaged for Australia. NBNs in Australia could be further divided by the name of the naming authority, e.g.
urn:nbn.au:nla
urn:nbn.au:101
urn:nbn.au:tas200
The NLA could take responsibility for routing all requests for such names to the appropriate organisation for resolution.
The use of a proxy server would be required. The NLA would register a domain name such as nbn.org.au to which all Australian NBNs (nbn.au) could be sent for redirection and local resolution.
2.2.5 Implement a Handle server.
The NLA has installed and trialled a Handle system and has determined that it is a technically feasible option. The implementation of a Handle system has the potential to meet the requirements of a distributed national system.
Advantages of the handle system:
- Flexibility of the naming system
- Naming system is URN compliant.
- Independence of a particular protocol
- A handle can refer to multiple instances of an item.
- Software and management tools are available from CNRI
- It was developed specifically for digital library applications
- Can support a centralised or decentralised model.
- Implemented in major applications which share the requirements of the NLA (Library of Congress and DOI)
- Easier interoperability with DOIs if the system takes off.
- Can accommodate existing schemes easily.
- Has a built in resolution infrastructure
Disadvantages of the handle system:
- More complex than the other systems to establish
- Not yet useable through standard browsers without plug-in software for the client - but can be used with a proxy server as an interim measure (See Section 1.4.3)
CNRI have stated that they have not registered the Handle system as a URI or URN scheme because the procedures for doing so are unclear and the relative advantages of registration as either a URI or URN are also unclear. One of the work items identified by a W3C interest group set up to look at URI issues is to clarify and streamline the URI administration and registration processes to ensure that they are easily negotiated and thus encourage the registration of additional URI and URN schemes. If this effort is successful, it may open the way for schemes such as Handles to be formally recognised and implemented by standard browser developers. On the other hand, Handles may be registered as a URN namespace, so that if standard browsers recognise URNs, they can be routed to the Global Handle registry. Either way, such a development would remove a major impediment to the use of Handles.
CNRI is a research initiative, which raises the question of support for the handle system if funding is withdrawn and the body ceases to exist. Given the investment of LC and the IDF (International DOI Foundation) in the system, it is unlikely that, should this happen, the system will suddenly die. The IDF has negotiated guaranteed levels of support and service level standards with CNRI, who have, as a result, moved support for the system to a commercial agency and now guarantee a 24 x 7 operation.
2.2.6 Adopt the DOI system
It would be possible for the NLA to become a user of the DOI system, either as a Registrant or as a Registration Agency (See section 1.4.4). The administrative, organisational and financial arrangements of the DOI system have recently been revised, and the exact long-term costs and requirements are not clear.
The costs associated with becoming a Registration Agency are specified until December 31st 2001, but thereafter will be subject to change. The costs of becoming a Registrant remain uncertain at this stage. As outlined in Section 1.4.4., there is no defined business model to which the Registration Agencies must adhere, and until a number of Registration Agencies are established, it is impossible to second guess what their charging mechanisms will be. One further option for the Library is to become a registrant directly under the IDF. Currently, this involves one time payment of US$1,000 for a prefix, which allows an unlimited number of DOIs to be allocated.
However, there is little advantage in the NLA becoming a registrant simply to register its own resources. The Library is quite capable of managing its own resources and creating its own identifier system and resolving its identifiers. Therefore the following comments on advantages and disadvantages are based on the scenario of the NLA becoming a Registration Agency
Advantages
- As a handles implementation, the DOI inherits many of the advantages of the Handles system
- Flexible naming system that can accommodate existing schemes easily.
- Has a built in resolution infrastructure
- Independence of a particular protocol
- A handle can refer to multiple instances of an item. (multiple resolution)
- Supported by freely available software
- Supports centralised and decentralised model.
- The real advantages of using the DOI for the NLA lie not in allocating DOI to its own resources, but in becoming a Registration Agency. The requirement to lodge metadata with the registered DOIs and the ability of Registration Agencies to define application profiles for that metadata would enable the NLA as a Registration Agency to build value added services on the metadata, e.g. to use the data as a component of a metadata registry. It would also acquire a great deal of knowledge of what was being published.
- The development of the system will be done co-operatively and many of the features needed by the NLA in a persistent identifier system (multiple resolution, automatic identification based on associated metadata) are being developed by the IDF for the DOI implementation.
- Involvement in a system which is likely to become widely deployed for digital resources of all kinds, especially in the commercial publishing fields. Many of the archival items the NLA will have custody of will have DOIs allocated.
Disadvantages
- The high costs of start up (Fees, negotiations, business plan, IT and business systems set up)
- Not yet useable through standard browsers without plug-in software for the client - but can be used with a proxy server as an interim measure (See Section 1.4.4)
- There could be a degree of loss of autonomy involved and a level of uncertainty about the degree to which the interests of large commercial publishers will impact adversely on those of archival institutions. On the other hand, close work with these organisations may lead to increased mutual understanding and co-operation.
- Charging structures may make it unacceptable for smaller publishers/website owners
- The link with rights management may make it unacceptable to some of the constituency that the NLA wishes to engage in the task. Many not-for profit organisations are suspicious of the commercial nature of the system and see it as the domain of the big publishing houses.
It is still unclear that NLA could apply DOIs to other peoples intellectual property. Discussions with Norman Paskin indicate that there are differing views within the IDF on this issue and it is not clear from the DOI manual that these have been reconciled. The DOI Handbook (Version 1.0.0 February 2001) states:
Currently the rules relating to the registration of DOIs are relatively loose; there is an implicit assumption that any organisation that has acquired a DOI prefix is unlikely to register a DOI for an intellectual property entity in which it does not have a legitimate interest. -P. 39
This leaves the issue wide open. Unless the definition of legitimate interest is circumscribed, an archival institution could reasonably argue that it has a legitimate interest in any resource which it is archiving in the public interest.
The uncertainty concerning long-term costs and the governance issues associated with the establishment of a DOI registration agency make it an unattractive option at this time. It may be worth re-examining this option when the new charging structure is made available in January 2002. The pattern of activity and take up levels will also be clearer at that time, allowing for a better informed judgement to be made.
2.2.7 ARK Persistent identifier
If it is accepted as a standard, the ARK is a promising avenue for the identification of digital archival materials. (See Section 1.4.5)
Advantages
- It is designed for custodians of digital archival materials
- It is location and protocol independent
- Can be used with standard browsers today
- It can support multiple resolution
- Associated services are based on metadata
Disadvantages
- Too new to judge the likelihood of acceptance.
- Requires a resolution discovery service at a later date and there is no guarantee that this will be developed.
As the proposal was only issued in March 2001, it is too early to determine what will become of it. Nevertheless, it is worthy of detailed consideration and support.
The concept of making the Name Mapping Authority Hostport (NMAH) optional and mutable and recognising only the NAAN and assigned name components as the ARK identifier is elegant in its simplicity. If it works and is accepted, it can be used today and will only require minor adjustments to browsers to enable them to substitute the http string for the ark string for resolution. Development of the alternative resolver discovery facility based on the NAAN will take a little longer, but is feasible with support from archival institutions. The metadata required to support the services can easily be derived from the existing metadata created by custodial institutions for their internal management and access purposes.
The Library should encourage discussion of the proposal, possibly at CDNL.
2.3 Choice of a resolution system
There is an inherent risk in embarking on a particular course of action when the standards and processes involved are not settled and the various technologies are untested. The Library wishes to work within international standards and in cooperation with other agencies with like interests and needs. However the options at present are limited and any implementation that is more than simple URL management would need to be embarked upon with caution. This is not an area where a single organisation can successfully go it alone and just doing something is not a sensible way of proceeding.
As outlined at length in this document, there is no ideal solution at present. If we want to do more than offer managed URLs in the current environment, any system we use will have to operate using an http proxy server at least in the short to medium term. This reduces the value of the system, since all identifiers, and therefore citations, will effectively be URLs. Of the systems available at present, only the Handle and DOI offer a built-in resolution system.
The Handles test undertaken by the Library has shown that the system, although not well developed in terms of user interface, is a technically feasible option, and that by extension, the Library would be capable of operating a handle service as a DOI registration agency. Thus both the Handles and DOI options are technically feasible for the Library.
Given this, overall, the use of the Handle system seems at present to offer the best option. It offers a naming scheme which is flexible and extensible and which will support distributed naming and resolution with an option to resolve centrally. It has deployed systems in LC and DOI. It has the capability for multiple resolution which will be further developed and exploited by the IDF and we may be able to take advantage of theses developments. There is the possibility that it may be registered either as a URI scheme or a URN namespace. It also has management, security, registration and resolution capabilities.
However I hesitate to recommend the adoption of the Handle system until such time as it is registered as a URI scheme and is on the way to attaining recognition by standard web browsers. In addition, if the ARK is adopted and accepted it may be a better alternative.
Recommendation 1
That the Library postpone a decision on implementation of an external resolution mechanism for persistent identifiers and that, for the time being, persistence of our own resources be achieved through a combination of managed URLs and a resolver system based on directing query strings to our application delivery mechanisms for digital materials. (See Appendix 2)
That this decision be re-examined in the first quarter of 2002 in the light of developments in the intervening period.
2.4 Development of local and national naming systems
2.4.1 Identification of NLA resources
In the absence of a fully operational system of naming authorities, the most useful option for identifying NLA digital resources is to use a system of unique identifiers that are not dependent on a domain name to provide unique identification of the resource. Although not derived from an existing scheme, the identifiers should nevertheless be compatible with such schemes. The identifiers should be globally unique outside the context of a container such as a URL or a Handle or a DOI. They would uniquely identify the file or digital object and could therefore be used in a number of applications or contexts, including a URL. It would not rely on a domain name or a namespace identifier to make it unique, but at the same time could be used as the namespace specific string in the context of any naming system implemented at a later date.
A unique identifier of this kind could be used in the context of a number of identification schemes; in a straight URL, as a PURL, or as the NSS in a URN or as a Handle or an ARK, or some other scheme.
For example, the identifier nla.pic-12345-t could be used in the following ways:-
http://www.nla.gov.au/nla.pic-12345-t
http://diglib.nla.gov.au/nla.pic-12345-t
http://purl.nla.gov.au/nla.pic-12345-t
urn:nbn:au-nla.pic/nla.pic-12345-t
urn:<SomeOtherNamespace>:nla.pic-12345-t
hdl://1703/nla.pic-12345-t(or hdl://1703.001/ nla.pic-12345-t if we go for a national system)
http://hdl.nla.gov.au/1703/nla.pic-12345-t(if a proxy server is used)
doi://<NamingAuthority>/nla.pic-12345-t
http://www.nla.gov.au/<NAAN>/nla.pic-12345-t
ark://<NAAN>/nla.pic-12345-t
In all of these examples, the inclusion of a complete identifier means that the identifier will be unique prior to any decision on a global resolution system and the identifier is readily identifiable as the same in all these containers even automatically. Because it is a unique identifier, it could be used as a search parameter in its own right in search engines and databases.
A proposed system of numbering for the Librarys own digital resources which is currently being used in the NLAs digitisation program is attached at Appendix 1.
2.4.2 Towards a cooperative national identifier system.
There is also a case to be made for the development of an identifier with these characteristics for general use by publishers and archival institutions. As described above, the identifier would uniquely identify a resource and could be used in a variety of contexts as a search key in databases and search engines and in URIs for access.
The Library should develop an identifier for digital archival resources in cooperation with other custodial institutions, e.g. the state libraries and archives. Cooperative development would assure a greater chance of acceptance and more effective promotion of the concept and the identifier scheme could, if carefully constructed, eventually form the basis of a national system of persistent identifiers.
An identifier developed for national use should follow the pattern described in RFC 1737. It should consist of a naming authority component to provide uniqueness and a local string which would be determined by the identifying institution to meet its own needs. The naming authority component would be registered centrally to avoid duplication, and the assignment of the local strings would be decentralised and undertaken by the naming authorities. (Centrally in this context would mean within a particular state if the naming authority substructure were delegated on a state based model). Use of this pattern would have the double benefit of guaranteeing uniqueness and facilitating identification of the naming authority, thus acting as a guide to possible resolution at a later date. Naming and resolution are separate issues in name style identifiers, but in the real world, hints on routing are needed. If the identifiers contain some structure that aids resolution, it increases the chances that future software will be able to make use of it.
It is also advisable that in a national system, the naming authority component be numeric, or at least have minimal semantics associated with it, to accommodate the frequent change in the names and relationships of government departments and authorities. It is anticipated that these bodies will be users of such a system. It is also recommended that the syntax of the identifier specify the separation of the naming authority component from the local string in a way that will allow machine identification of the two components, e.g. <naming authority>/<locally assigned name> or <naming authority> : <locally assigned name>. This will facilitate migration to another system at a later date if one of them is implemented. In the short term, it will be accessed using standard URIs, i.e. http://<domain name>/<persistent identifier>.
Recommendation 2
That the Library formally adopts the naming guidelines outlined in Appendix 1
That the Library develops a naming scheme for archival resources in consultation with the state libraries and archives. The scheme should be designed for distributed assignment based on a pattern of naming authority and local string to guarantee uniqueness and that the syntax of the identifier separate the naming authority component from the local string in a way that will allow machine identification of the two components. This will facilitate migration to a global system at a later date if one of them is implemented. In the short term, it will be accessed using standard URLs.
2.5 Continued monitoring of developments
In the absence of a recommendation on resolution at this time, there will be a temptation to try to simplify the persistence issue by treating the problem of resolution and access and the issue of identification as separate issues and concentrating only on identification. The development of a naming system as described may be seen as the solution. However, to ignore the issue of resolution would be to reduce the value of the development of a naming system. The aim of persistent identification is to reduce failure of access over time and, as stated elsewhere, this cannot be achieved simply by assigning unique identifiers. Thus, the issue of resolution for location and protocol independent identifiers must be addressed, or at the very least be taken into account when identification schemes are considered.
2.5.1 Developments of particular interest
It is important that in pursuing the development of a cooperative national naming system, the Library should not consider the task complete. As stated earlier, an identifier system alone will not reduce access failures over time. It will be advisable to assiduously monitor developments in the next year or so in the area of resolution and access with a view to implementing a more location and protocol independent resolution and access system if one should emerge as the front-runner.
In particular, the Library should note:
- Whether a W3C working group on URI issues is established. (The
notional time frame for completion is 2 years!). There is some doubt as to
whether this will happen, as there is no real commitment from W3C to support
it. Most of the interest is coming from the IETF members of the Interest Group.
The Library should join W3C working group if one is established and support
rationalisation of URI and URN procedures to assist acceptance of standards and
development of URN enabled browsers.
- The progress of DOI deployment and the establishment of Registration
Authorities. In particular, it should note whether the DOI begins to take off
rapidly and whether there is a registration agency established in Australia. It
will be a question of judgement as to whether the NLA should apply to become a
registration agency. Technically, the Library can support a Handles service,
but the cost of establishing a Registration Agency is high. It would also be
worthwhile to make use of this period to canvas the The progress of DOI
deployment and the establishment of Registration Auth
- The Library should also monitor the progress and possible deployment
of the latest IETF proposals on the Dynamic Delegation Discovery System (DDDS)
issued as an Internet draft in February 2001. The DDDS approach is to use the
DNS to locate "resolvers" that can provide information on individual resources,
potentially including the resource itself. If this becomes a standard, it may
be possible for an interested group of custodial institutions to support
resolution of their identifiers using the domain name sThe Library should also
monitor the progress and possible deploy
- Monitor ARK developments. As outlined above (See Section 2.2.7), the ARK has the potential to be a significant development for libraries, archives and other custodial institutions. Although it is too early to tell whether it will be accepted and implemented, if it is, it will meet the needs of the Library for an identifier which is location and protocol independent and which can be resolved by whatever current standards are commonly in use.
Recommendation 3
That the Library actively monitor developments relating to existing identifier schemes, in particular, the issues outlined above.
2.5.2 CDNL Group
The library may wish to revisit discussions in CDNL. There are two fronts on which CDNL might make progress.
Firstly, there is no reason why CDNL should not support a number of approved and registered namespaces that might be used by cooperating national libraries and this would offer a more flexible approach than supporting a single namespace (NBN). CDNL should look to supporting a number of URN namespaces used by National Libraries. For example, LCCN might be registered as a separate namespace and possibly resolved to a number of institutions e.g. to a Z39.50 query on the LC database, OCLC or on Kinetica, all of which have LC tapes loaded. The Australian system recommended above (Section 2.4) might also be registered with its own prefix(es).
Secondly, CDNL needs to seriously consider work on developing shared resolving services for name style identifiers if it is to make any significant progress towards either a viable shared URN namespace, or the registration and use of other name style identifier schemes. This will not be an easy task, as it will require commitment of resources for the long term in an uncertain environment and possibly requiring contractual agreements. The CDNL group has in the past focussed on identification and paid little attention to the more difficult area of access. If it is to be productive, it must widen its focus to encompass the issue of persistent access and resolution.
In this context, CDNL might wish to discuss and evaluate the ARK proposal or explore the possibility of taking part in experiments with DDDS.
Recommendation 4
That the Library revisit discussions in CDNL with a view to:
i) affirming support for a number of identifier systems used by national libraries and.
ii) exploring the possibilities of developing and trialling shared resolution systems for identifiers used by national libraries and other custodial institutions.
2.6 Other related issues
2.6.1 Issues related to metadata and metadata structures
There are a number of issues related to the kind of metadata that needs to be stored with, or linked to, a persistent identifier. What information about the files, the objects they make up and the aggregates they are part of needs to be stored in structural metadata to support direct citation at the level of granularity sought and the selection of the appropriate copy or version? How can versions and relationships be recorded and made available to the user? How can selective resolution be supported? How can a user discover if a particular work has a persistent identifier?
It is worth noting in this context that both the DOI and ARK recognise the importance of a minimum set of metadata associated with the identifier and the resource.
What to resolve to?
Many of the aggregates to which we will wish to apply a persistent identifier have no tangible manifestation, i.e. a virtual digital object made up of other digital objects. A manuscript collection is made up of hundreds of page images that will be organised into documents, series, or collection; there may be several images which make up a map. Some form of meta-object or structural metadata would generally represent such aggregates. However to assist direct citation, the persistent identifier needs to be linked to the logical object. These aggregates might be dealt with in various ways. e.g. the persistent identifier might resolve to:
- A software program which can parse the identifiers (if intelligent numbers) and create an object for display which represents the serial issue, diary, letter, etc to which the persistent identifier refers.
- As above, using structural metadata from which an object can be created for display, including links to the objects making up the object
- An object such as an html page
- A point within an EAD finding aid.
- A metadata description with links to the sub-objects.
Decisions on this are problematic for some digital surrogates. Although the structure of the aggregates and objects are static and evident at the time of creation of the files, the ability to directly cite groups of files will be dependent on metadata.
For compound objects on the www server and in Pandora, this is initially simpler, since in most cases, the digital objects are self-referencing, i.e. there is an object (html page) which represents the logical collection containing links to the various files and this object can be addressed by the persistent identifier.
Identification of the persistent identifier
The full value of persistent identifiers to ensure persistence in citations can only be realised if they are actually used by people when citing documents/objects. In order to use them, people must know that there is a persistent identifier and must be able to discover what it is. At present this is difficult because of the nature of the redirects used in most existing systems.
For example, the PURLs on the items in Pandora are not evident. They are present in the NLA catalogue and Kinetica and can be found by looking at the links on the alphabetical listing on the site, but if an item had been found by following a reference from another object or by serendipity, it is unlikely that the user would find the PURL, and would cite the URL found in the location box on the browser.
The same scenario would apply to any object accessed via a proxy server while standard browsers display the actual URL in the location window and print the actual URL when documents are printed rather than the target URL.
Possible ways of facilitating lookup need to be explored. Possibilities include inclusion of the information in the document/object itself. This document has a persistent identifier and should be cited as /be linked to as This would be possible in pages which are constructed on the fly and pages owned by the NLA, but would be difficult in digital objects hosted for others (Pandora). Other possibilities are allowing the user to do a reverse lookup on the resolver database, i.e. do a search on the URL currently displayed and be given the persistent identifier currently associated with it. Metadata associated with the persistent identifier to allow remote lookup can be facilitated by a metadata database.
Versions and relationships
Many relationships can only be recorded in a way which is actionable and meaningful using metadata. Appropriate metadata will be required to select between versions. E.g. is X the same work as Y even though it is in a different file format? And where should the relationship be recorded. The information may be needed by users, presentation software, or those responsible for preservation of the resources.
Selective resolution.
Persistent identifiers may represent multiple copies of a resource held in different locations. Often decisions are required to determine the most appropriate copy. There are a variety of conditions on which a decision may be based including:
- Access privileges, e.g. a user may have the right to access a local copy held by an institution to which she is affiliated
- Choice between free and paid copies
- Format, e.g. text or pdf or word document
- Location, e.g. a local mirror site may be preferred
- Live or archival copy. The user may be directed to the publishers site for more recent material, or to the archive for older material that may no longer be available on the publishers site
In many of these cases, decisions can only be made based on local conditions e.g. an organisation might use a proxy server to route all requests for a particular item to a local mirror site or direct all requests from its clientele for a paid service to which it subscribes via whatever mechanism is used locally to access that service. All requests for archived copies may also be directed to the publishers site this way.
Although it is not an immediate concern, it may be worthwhile revisiting metadata standards used in the Library to evaluate how the structural, descriptive and administrative metadata will support various functions related to the uses envisaged for persistent identifiers.
2.6.2 Relationships with publishers data
The Library must also keep a watching brief on the progress of the DOI system from a user perspective. If the IDF plans are successful, it is likely that major publishers will begin to use the system seriously. There are already signs that the publishers see citation linking in serials databases as the killer application which will see the DOI take off. This is evidenced by the development of services by Cross Ref, and the fact that Cross-Ref has recently become the first DOI Registration AgencyThe
The full implementation as envisaged in the IDF documents will take time to achieve because of the complexity of the applications needed to support fully fledged rights management systems, but libraries will need to be able to deal with DOIs as identifiers of materials deposited in their collections.
It is too early to say how this will be done, since it is not clear what publishers will require and how rights management systems associated with DOI will work over the networks. Possibilities include using the multiple resolution capabilities of the DOI system to record the archiving institution as a second location for deposited material and possibly at a later date the only one if the publisher decides to abandon its interest in it. Access restrictions for items held locally can be enforced with a proxyIt
The IDF have stated publicly that the DOI may be used in local systems and databases (in much the same way as we use ISSN and ISBN). In the meantime, if items with a DOI are encountered the DOI should be used as an identifier of the item if it is an exact copy or at the very least be recorded as an identifier associated with the item.
This is equally true of other forms of identification used by publishers of online materials. The relationship between the publishers identifier and the archival copy of the resource must be recorded, maintained and made evident to users.
Recommendation 5
That the Library continue to address the outstanding issues of metadata, publishers identifiers and their relationship with archival copies and their identifiers.
| Return to Table of Contents | Proceed to Part 3 |
| About This Site | Copyright | Privacy | Accessibility | Site Map | Site Search | Content A-Z | Contact Us |