ePIC FAQs

Persistent identifiers (PIDs) are an abstraction layer that arbitrates between the reference of a digital object and its location. Since URLs as location tend to change over time for whatever reason they are obviously inappropriate as stable references, but they are ubiquitously given as locations of digital objects. The abstraction layer of PID can be seen as a pointer to the location and becomes a necessary precondition (but is not sufficient: see ‘Who is responsible for the correct PID resolution?’) for any stable referencing in the web.
The analogy in the library world is the shelfmark and the insight that the mark in the bookshelf is not the correct way to point to the book, because the place of the book in the shelf tends to change over time for whatever reason.
In order to become a real pointer to the location of the digital object a resolution infrastructure for PIDs is necessary. The analogy here is the order of the books depending on the alphanumerical order of the shelfmarks.
ePIC uses Handles, a special kind of PIDs that comes with an intrinsic global but distributed resolution mechanism (see also ‘How is the resolution of a Handle organized?’) and provides therefore a particularly reliable infrastructure.

Resolution systems enable client software to go from an identifier to current state information about the identified object, such as where and how to access the object. Such identifiers can persist over changes to the identified object, like changes in its location(s), ownership, and other attributes – persistence that is vital for maintaining data integrity over time.
Investigations about references to digital objects in the web say that 7 from 10 such references in a scientific context are not accessible anymore for whatever reason (reference rot, see hdl:10.1371/journal.pone.0115253). This means a significant loss of reproducibility of scientific results for instance, and this is expected to become even worse, because the portion of web references will increase especially due to references to data sources in scientific publications.
Persistent identifiers can help to avoid this, because they can be adjusted in the case of changes, and they can make planned changes and obligations like citations transparent.

The Handle system including the Global and Local Handle Server are responsible for the resolution to the content of the URL field in the handle (see also: ‘How is the resolution of a Handle organized?’). This is necessary but not sufficient for proper resolution.
The responsibility for the content of the URL field in the handle however is in the hands of the owner of the PID, which is in most cases the owner of the prefix. PIDs can prevent link rots, because they distinguish the identity of an object from its location on the web. But this only works, if the field pointing to the location on the web is accurately maintained with respect to changes.
Since a necessary location change in a PID is often caused by a more general decision like the change of technology in a repository or the change of the name of an institution, new locations often are needed for a huge amount of PIDs at the same time, such that automated processes are in general used for such changements.
In practice it is therefore often of advantage, that the owner of the PID has also control of the location of the particular object and even more that the owner of the prefix has also control of the location of all the objects, the PIDs under this prefix are pointing to.
This means in general that PIDs should belong to trustful data repositories and not to individuals.

The ePIC Persistent Identifier Consortium for eResearch is an identifier system using the Handle infrastructure. Its focus is the registration of data in an early state of the scientific process, where lots of data is generated and has to become referable to collaborate with other scientific groups or communities, but where it is still unclear, which small part of the data will be cited or should be available for a long time period. But even in the case, that some data has to be cited, an ePIC PID is reliable, because its resolution is guaranteed.
ePIC PIDs are flexible and well suited for references with a fine granularity, because they support fragments for special repository
services, and also for data management purposes, because they provide data types as possible parameters in data management workflows.
Another identifier system, which is widely used by the publishing industry for the persistent identification of journal articles and for tracking cross-linking through citations, is the Digital Object Identifier (DOI). Data citation on the DOI basis is provided by DataCite. DOIs are also using the Handle infrastructure, such that they are compatible with ePIC PIDs on the infrastructure level.
If a later registration of a digital object with a DOI is wanted for some reason, in most cases, depending on the characters used in the suffix, the PIDs can easily be transferred because the identifier systems use the same underlying Handle software and similar database schemata.

ePIC uses the Handle system as underlying infrastructure. Therefore an ePIC PID is an ePIC Handle, both term are used as the same here.

Handles and ePIC PIDs are strings consisting of a prefix on the left and a suffix on the right, separated by a slash “/” (the first slash from the left, if there are more than one). 21.012 is the prefix and xyz-123 the suffix in 21.012/xyz-123 for instance. The prefix consists of alphanumeric ASCII characters together with the dot “.” as delimiter. Whereus Handle suffixes in general allow UTF-8 encoding, the suffix of an ePIC PID consists of a string of printable ASCII characters for disambiguation reasons.
ePIC strongly recommends the use of upper case ASCII characters int the
suffix, because this ensures a possible later transfer of an ePIC PID to
a DOI.

The Handle System is a general-purpose identifier resolution system that has been in place for many years. The prefix is used by client software to find the specific servers within the widely distributed resolution system that will be able to resolve the identifier. Existing identifiers can be easily structured as Handles in order to take advantage of the resolution system.

For the resolution of a Handle (like 21.012/xyz-123) one uses the proxy http://hdl.handle.net with the PID string as appendix (similar to a location) like http://hdl.handle.net/21.012/xyz-123 . For resolution the proxy asks the Global Handle Registries (GHR) for the address of the Local Handle Server (LHS) that is responsible for the resolution of all PIDs with given prefix (like 21.012). Dependent on the answer of the GHR the proxy asks this server to resolve the PID. Redundancy is given by mirroring on each level of this process from the proxy and the GHR to the LHS.

IETF RFC 6570 defines rules for strings (called fragments or templates) appended to the URL to enable additional services on web resources. This allows to identify substructures of a web resource (such as a number of frames in a video).
If one wants to access such services also via the handle resolution, it is necessary to identify the fragment strings in the resolution process and hand them over to the resolved web resource.
Technically this is done by a rather generic pattern matching process in the resolution of the PID that can be defined on a prefix level.
However Fragment or Template Support requires local resolution operations on web resource and cannot be mixed with generally resolvable references and citations.
If this is required by science, one should create more granular digital objects.

Data Types are additional metadata, closely coupled and stored in the PID database.
PID Information Types are special data types intended to be accessible before data processing and access
They are mainly used for state information (what is the data?) and binding information (where is the data, additional metadata etc.?) about data
Typical cases are mime types, checksum, version, previous version, embargo, expiration date, additional metadata location, basic Dublin Core (DataCite mandatory metadata).
See also: ‘What is the ePIC Data Type Registry for?’

Types, especially PID Information Types need standardisation. At such Data Type Registries types are defined and registered with a PID.
ePIC runs a Data Type Registry for PID information types. More can be found at http://dtr.pidconsortium.net .
A PID Information Type Registry for the preparation of types is at http://dtr-test.pidconsortium.net/ and the Candidates and Approved PID Information Types are maintained at http://dtr-pit.pidconsortium.net/ .
See also: ‘What are Data Types and PID Information Types?’

The ePIC Persistent Identifier Consortium for eResearch is an identifier system using the Handle infrastructure. Its focus is the registration of data in an early state of the scientific process, where lots of data is generated and has to become referable to collaborate with other scientific groups or communities, but where it is still unclear, which small part of the data will be cited or should be available for a long time period. But even in the case, that some data has to be cited, an ePIC PID is reliable, because its resolution is guaranteed.
The assignment of ePIC is to set up and maintain a highly reliable joint service with transparent policies for registering, storing and resolving persistent identifiers based on Handles for the research community.

Please ask at support@pidconsortium.net

Please ask at support@pidconsortium.net

The current list of members can be found here

ePIC is controlled by its scientific organizations and user communities to ensure that it is devoted to the needs of the research community at large. This will also ensure that the overhead of the ePIC consortium will be small and restricted to essential services.

A Technical Board is responsible for the technical reliability of the ePIC infrastructure. It furthermore maintains the documentation of the ePIC software stack and an internal wiki for adminstration purposes.

The Management Board of the consortium consists of representatives of the ePIC members.

The chair of the Management Board as well for the Technical Board is elected always for a one year period.

The Global Handle Registries (GHR) in the Handle system consist of the so called Multi Primary Administrator GHR (MPA GHR) in DONA, the Digital Object Numbering Authority. DONA is a Swiss foundation hosting an international consortium, that was founded 2012 in Geneva. The current partners are the Corporation for National Research Initiatives (CNRI), the Chinese Handle Coalition (CHC), International DOI Foundation (IDF), Communications and Information Technology Commission (CITC), Smart Africa Alliance, MISAVA Agency for Digital Identifiers (MISADI), and the Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen (GWDG) on behalf of ePIC. This consortium will moderately grow in future. DONA operates in close collaboration with ITU, the United Nations specialized agency for information and communication technologies. DONA is governed by the DONA Board, which includes experts and stakeholders from around the world.

The Multi Primary Administrators (MPAs) are members of DONA, that are responsible for a certain prefix namespace, which is determined by the numbers leading the first delimiter dot from the left. ePIC for instance is responsible for the 21. namespace. All MPAs of DONA share the information about their namespace with all the other MPA building the mirrors of the GHR this way.

An individual researcher obtains ePIC PIDs through an institution, where she or he is customer and that provides a PID service, which in general includes the ownership of a prefix. The institution is able to maintain PIDs (see also: ‘Who is responsible for the correct PID resolution?’). So if you need an ePIC PID for your digital object please get in contact with your local institution and ask whether such a service is provided and how it can be used.

For a PID like 21.012/1234 use the proxy http://hdl.handle.net with the PID string as location like  http://hdl.handle.net/21.012/xyz-123 . See also ‘How is the resolution of a Handle organized?’ above.

Since the resolution of an ePIC Handle is a general HTTP request (see above) the resolution is operating system or platform independent. The minting and update of ePIC PIDs uses REST interfaces and is therefore operating system or platform independent as well.

Since Handles are strings, they can be shared as strings inside documents. But often not the PID but the underlying digital object is that, what scientists want to share. Therefore it makes sense to share not just the string but the PID via the proxy like http://hdl.handle.net/21.012/xyz-123 . In HTML documents one should use the PID at the proxy as the reference and the PID string as the name of the reference. If the content of the PID and not the data should be shared, one uses  http://hdl.handle.net/21.012/xyz-123?noredirect instead.

ePIC is setup as a highly reliable, persistent and high performance service. This is achieved through a network of strong data centers (see ‘Who is currently member of ePIC?’) that share the same service, the same API and that have implemented a redundancy scheme via mirrors of the Local Handle Systems.

• ePIC PIDs are unique.
• Registered production PIDs will not be deleted. They are used as a kind of tombstone even if the underlying data is not available anymore.
• Those PIDs, that have a prefix with a leading ‘T’ in the ’21.’ namespace of the prefix as ’21.T012/xyz-123′ allow deletion of PIDs. These prefixes are used for instance for testing purposes.
• All production prefixes have at least two mirrors with at least two different locations including the location of the master.
• The resolution is monitored for all production prefixes
• The ePIC data centers have an organisational long term perspective. In the unlikely event that one center gets out of order for some reason, the other centers signed a contract to resolve the affected PIDs and there is a procedure to take over also the PID services.

The idea in ePIC is, to have no costs for PIDs itself, and not to bother individual researchers with these costs, but to have institutions, that offer such services to their users. These institutions then can provide these services themselves or can buy such services from other ePIC members.

Projects and communities can – like an individual researcher – obtain ePIC PIDs through an institution, where they are customer and that provides a PID service, which in general includes the ownership of a prefix. So please in this case get in contact with your local institution and ask whether such a service is provided and how it can be used.

For communities or projects with a certain amount of potential customers however it can be an option to get an PID Service provided by one of the ePIC partners directly or even run a PID service including the ownership of a prefix on its own itsself, if the long term availability can be guarantueed by the project or community. In these cases get in contact with ePIC at support@pidconsortium.net and ask for a PID service or a prefix. The ‘Questions for Institutions’ below are of relevance in this case as well.

Yes, for big communities or projects with a clear long term perspective it is possible to become an ePIC member. This might be of interest, if for example there is a need for a greater amount of PID services and/or if a better coverage of the community interests inside the ePIC strategies is requested. In these cases get in contact with ePIC, for instance at support@pidconsortium.net .

An institution can ask ePIC, whether such a service can be provided by an ePIC member or can maintain such a service itself inside the own institution.

If the institution decides to maintain such a service itself and it is not an ePIC member, the institution can ask for an ePIC prefix from ePIC (at support@pidconsortium.net). The provided service in this case has to be certified by ePIC to become an ePIC service. See ‘How to get an ePIC PID service certificate?’ below in this case.

This depends on the offers that an ePIC member can make and on the relation that this ePIC member has to the requesting institution. If both institution are located inside the same country the costs often can be reduced or even canceled. This is the reason, why we encourage mayor scientific service provider of countries or regions to become an ePIC member, to provide PID services on a cost efficient way for their local researchers.

An institution can require an ePIC prefix through any of the ePIC members (see ‘Who is currently member of ePIC?’) or can ask for an ePIC prefix at support@pidconsortium.net .

The cost of an ePIC prefix is intended as a nominal fee. Some ePIC members will waive the fees according to their own policies, which are usually restricted to users from a specific community or country.
ePIC recommends currently a fee of 45,- € per year and additionally 45,- € for registration,
Please ask any ePIC member (see ‘Who is currently member of ePIC?’) or at support@pidconsortium.net .

ePIC has rules and policies, how to provide PID services and how to ensure the reliability, that is necessary for the persistency of access to digital objects via ePIC PIDs. These rules and policies have to be fulfilled by every PID service, that is provided as ePIC PID service, and an organisation, that provides a PID service and is not an ePIC member, can ask for a certification, that it provides its PID service along the lines of the ePIC rules and policies. This certification includes topics like

• Operation of Services
• Availability of Services
• Monitoring, Accounting
• Incident and Support Management
• Rules for Prefix Assignment
• Policies for PID Minting and Update

For certification of ePIC PID services ask at support@pidconsortium.net .

We have the hope, to find institutions inside the mayor countries or regions, that feel responsible to support the other institutions inside the country or region in providing such services to their customers, and that are willing to join the consortium on this behalf.

Inside the scientific community this is often particularly attractive, because the conditions to provide services for research are inside a country usually much less restrictive than across country boarders.

This might also be of interest, if for example there is a need for a greater amount of PID services and/or if a better coverage of the institutions interests inside the ePIC strategies is requested. In these cases get in contact with ePIC, for instance at support@pidconsortium.net .