This document provides a high level overview of information and ideas collected by the PILIN team. It is derived from stakeholder input on usage scenarios, use cases, suggestions for services, existing practice, common questions related to persistent identifiers.

The document is intended to stimulate a conversation about priorities for the project. It is also intended to elicit new ideas and directions for the project.

Infrastructure

The PILIN team has identified a number of potential service types that could be supported in a persistent identifier infrastructure.

The diagram includes core services such as

• Global Handles mirror

• Australian branded handles proxy, e.g. http://hdl.handle.edu.au

• Administer Australian Handles prefix (102)

• Administer Australian Handles licenses

Hosting and support services

• Services to support management of handles

• Host Local Handle services to support institutions and entities who wish to access handle management services rather than locally manage

• Development support to establish good practice and take up

• Last Resort Services for projects that are deceased

Value added services that extend the identifier infrastructure. See the next section for examples.

Governance and business models

PILIN is tasked with report on options and proposals for sustaining, supporting and governing shared persistent identifier management infrastructure. A possible breakdown is shown in the following diagram:

The model proposes an Australian namespace registration and licencing activity. This would manage the relationship with CNRI and the international Handles advisory board. One possibility is to negotiate a blanket licence for use of handles for Australian e-research and e-learning.

Value added services

PILIN currently defines “value-added” services as services that are enabled by identifier infrastructure, but are not a core part of that infrastructure. They often combine basic identifier services with other infrastructure services such as repository services, registry services, rights services, tracking services, etc.

PILIN hopes to pilot some value-added services during the project. It is also hoped that stakeholders will independently pilot value added services.

Value added services already identified by our stakeholders include:

• Relationship services, e.g. managing drafts, derivative works, and FRBR relationships.

• Metadata services, linking metadata to an entity through the entity’s identifier.

• Aggregation services that create aggregations of entities by aggregating their identifiers. The aggregation itself may have metadata associated with it and contain sequencing information.

• Appropriate copy services that determine which instance of a resource is appropriate in a certain context. Rather than presenting all instances to the end user for browsing, the service determines which instance the end user should be directed to. Choices could be based on accessibility, location, version, licences, FRBR category, …

• Resource movement services that support movement and copying of resources between repositories.

• Discovery services such as federated metadata registries and distributed search services. Identifiers can be used by these services to identify duplicates, show relationships, discover metadata etc.

Policy guidance

The PILIN stakeholders have identified a number of policy and best practice questions they would like guidance on. These include:

• Creating identifiers

  • Should identifiers have human understandable semantics, such as “102.Monash/psychology/101/overview”, or be meaningless to humans such as “102.100/E8D4A51000”

  • What characters are safe to use in an identifier?

  • Is there a service for creating handles suffixes?

• What to identify and when

  • What objects should have persistent identifiers?

  • Should an object’s metadata have a separate identifier?

  • If a resource is made up of more than one object, should each object have an identifier?

  • Should I identify the abstract notion of a resource as well as concrete instances (copies) of a resource?

  • Is there any best practice for identifying and tracking derivative works?

  • At what point do I associate a persistent identifier with an object?

• Improving persistence

  • Does the shared infrastructure play a role in persistence?

  • Guidance on mirroring, backing up handles servers, moving handles between servers.

  • Documenting persistence policies

• Storing metadata in a Handles record

  • What metadata should be stored in a Handles record?

  • Is there best practice for storing information about who created and who can manage an identifier in a Handles record?

  • What metadata shouldn’t be stored in a Handles record? Why not?

• Hosting and curation models

  • Should I host my own handles server, or use someone else's?

  • My DSpace repository already uses handles, can I re-use those?

  • Should I have my own namespace or share it with someone else?

  • When should I create a new namespace?