PID architecture for the EOSC : report from the EOSC Executive Board Working Group (WG) Architecture PID Task Force (TF).
Date: 2021-01-04
Institutions: Directorate-General for Research and Innovation
Subjects: cloud computing, directive (EU), open science, open source software, provision of services, report, technical standard

PID 
Architecture for 
the EOSC 

Report from the 
EOSC Executive 
Board Working 
Group (WG) 
Architecture PID 
Task Force (TF) 

EOSC Executive Board 
WG Architecture 
December 2020 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
PID Architecture for the EOSC 

European Commission 
Directorate-General for Research and Innovation 
Directorate G — Research and Innovation Outreach 
Unit G.4 — Open Science 
Contact   Corina Pascu 
Email  

Corina.PASCU@ec.europa.eu   
RTD-EOSC@ec.europa.eu  
RTD-PUBLICATIONS@ec.europa.eu 

European Commission 
B-1049 Brussels 

Manuscript completed in December 2020.  

The European Commission is not liable for any consequence stemming from the reuse of this publication.  
The views expressed in this publication are the sole responsibility of the author and do not necessarily reflect the views of the 
European Commission. 

More information on the European Union is available on the internet (http://europa.eu). 

PDF  

ISBN 978-92-76-27339-4 

doi: 10.2777/525581 

KI-03-20-757-EN-N 

Luxembourg: Publications Office of the European Union, 2020 

© European Union, 2020 

is  authorised  under  a  Creative  Commons  Attribution  4.0 

The  reuse  policy  of  European  Commission  documents  is  implemented  based  on  Commission  Decision  2011/833/EU  of  12 
December 2011 on the reuse of Commission documents (OJ L 330, 14.12.2011, p. 39). Except otherwise noted, the reuse of this 
document 
licence 
(https://creativecommons.org/licenses/by/4.0/). This means that reuse is allowed provided appropriate credit is given and any  
changes are indicated. 
For any use or reproduction of elements that are not owned by the European Union, permission may need to be sought directly 
from the respective rightholders.  
Cover  page:  ©  Lonely  #46246900,  ag  visuell  #16440826,  Sean  Gladwell  #6018533,  LwRedStorm  #3348265,  2011;  kras99 
#43746830, 2012. Source: Fotolia.com.

(CC-BY  4.0) 

International 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
EUROPEAN COMMISSION 

PID Architecture for the EOSC 

Report from the EOSC Executive Board Working 
Group (WG) Architecture PID Task Force (TF) 

Edited by: the EOSC Executive Board 

December 2020 

Authors 

Ulrich Schwardmann (GWDG, ePIC, ORCiD: 0000-0001-6337-8674) 
Martin Fenner  
Maggie Hellström (Lund University and ICOS RI, ORCiD: 0000-0002-4154-2610) 
Hylke Koers (ORCID: 0000-0001-6538-7590) 
Hervé L'Hours (ORCID: 0000-0001-5137-3032) 
Brian Matthews (UKRI-STFC) 
Raphael Ritz (MPCDF and RDA, ORCID: 0000-0003-4615-6804) 
Mario Valle (CSCS, ORCID: 0000-0002-6644-1533) 
Mark van de Sanden (SURF, ORCID: 0000-0002-2718-8918) 
Themis Zamani (GRNET, ORCID: 0000-0003-1148-1738) 

2020  

   Directorate-General for Research and Innovation 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
              
 
PID Architecture for the EOSC 

Table of Contents 

1  INTRODUCTION .......................................................................................................... 4 

1.1  Main Goals and Target Group ............................................................................... 4 
1.2  Overview and Previous work ................................................................................ 4 
PID Strings, PID Records and Resolution ............................................................... 5 
1.3 
1.3.1  Fragment or Template Support 
6 
PIDs versus Intrinsic Identifiers ........................................................................... 6 
PIDs as an Abstraction to Hide Inner Complexity .................................................... 7 
PIDs, Digital Objects and FAIR Digital Objects........................................................ 8 

1.4 
1.5 
1.6 

2  COMPONENTS AND ACTIVITIES IN A PID ARCHITECTURE ................................................ 10 

2.1 

2.2 

2.3 

The PID consumer's view of the global PID architecture .......................................... 10 
10 
2.1.1  Technological Independence 
2.1.2  PID Usage and Administration 
10 
The Global PID Registration and Resolution Framework ........................................... 12 
12 
2.2.1  Administration and Resolution within a PID Platform 
12 
2.2.2  Global Resolvers 
13 
2.2.3  Global PID Registration and Resolution Activities 
13 
2.2.4 
Internals of the Global PID Registration and Resolution 
14 
2.2.5  Namespaces, Governance, Policies and Interoperability 
2.2.6  A Generic Global PID Resolution Architecture 
15 
Types and Profiles in a Global PID Registration and Resolution Framework ................ 15 

3  CERTIFICATION .......................................................................................................... 17 

4  IMPLEMENTATIONS ..................................................................................................... 19 

4.2 

4.1 

The Handle based Systems .................................................................................. 19 
19 
4.1.1  Namespace Governance 
19 
4.1.2  Resolution 
20 
4.1.3  Templates and Fragment Support 
21 
4.1.4  Types 
21 
4.1.5  Generic Global Resolution 
4.1.6  Examples 
21 
The URN PID Framework ..................................................................................... 22 
23 
4.2.1  Examples 
4.3 
The ARK PID Framework ..................................................................................... 24 
4.4  HTTP identifiers.................................................................................................. 24 
24 
4.4.1  Cool URIs 
4.4.2  PURLs 
24 
Intrinsic Identifiers ............................................................................................. 24 
25 
4.5.1  ORCiDs 

4.5 

5  COMPARISON WITH THE DNS SYSTEM .......................................................................... 26 

5.1  DNS versus PID Namespace and Governance ......................................................... 27 
5.2  DNS versus PID technical architecture .................................................................. 30 

6  PERFORMANCE AND SCALABILITY ................................................................................. 34 

7  SECURITY, RELIABILITY AND RESILIENCE ...................................................................... 35 

8  GAPS IN THE EXISTING PID LANDSCAPE AND CHALLENGES FOR INVESTIGATION AND 
DEVELOPMENT ................................................................................................................ 36 

2 

 
 
 
 
PID Architecture for the EOSC 

8.1 

Interoperability between PID systems ................................................................... 36 
36 
8.1.1  Generic Global Resolution 
36 
8.1.2  Reverse Lookup 
36 
8.1.3  Generic PID Minting 
36 
8.1.4  Scaling up 
8.2  Hidden Complexity of Metadata ............................................................................ 37 
37 
8.2.1  Federation and Governance of Data Type Registries 
37 
8.2.2  Kernel Information Types and Profiles 
37 
8.2.3  PIDs for Services 
8.2.4  PIDs and Sensitive data 
37 
Priorities between these Challenges ...................................................................... 38 

8.3 

9  THE USERS/COMMUNITIES’ PERSPECTIVE ..................................................................... 39 

10 SYMBOLOGY OF ARCHITECTURE DIAGRAMS ................................................................... 40 

10.1  Edges ............................................................................................................... 40 
10.2  Nodes ............................................................................................................... 40 

11 DEFINITIONS, GLOSSARY ............................................................................................ 41 

11.1  Categories and Criteria of PID systems ................................................................. 43 

12 REFERENCES .............................................................................................................. 45 

3 

 
 
 
 
 
 
 
 
 
PID Architecture for the EOSC 

1 

INTRODUCTION 

1.1  Main Goals and Target Group 

The Technical Architecture document on Persistent Identifiers (PIDs) describes a high-level 
view  on  components  and  stakeholders  relevant  inside  an  architecture  for  persistent 
identification  based  on  namespaces.  It  is  generic  in  the  sense  that  the  components  are 
described independently of a concrete technical implementation. Not all components are 
realized  or  need  to  be  realized  by  all  concrete  implementations  to  establish  a  PID 
framework. Such components are optional additions to the framework. If they are realized, 
these components can and will be added in a way that ensures not to hamper any other 
functionality of the implementation (Backward Compatibility). In many cases the additional 
components,  possibly  not  used  by  all  stakeholders,  are  already  foreseen  and  have 
backward compatible integrations in the concrete frameworks.  

The  PID  Technical  Architecture  document  will  additionally  identify  opportunities  for  how 
interoperability  between  PID  services  can  be  achieved  within  the  framework  of  the 
European  Open  Science  Cloud  (EOSC).  Drawing  from  the  EOSC  guidelines,  it  identifies 
stakeholders at different levels of PID namespaces, their roles and their ability to enforce 
policies.  

The  PID  Technical  Architecture  document  is  mainly  targeted  at  PID  and  generic  service 
providers and practitioners as guidelines on implementation of PIDs and related services 
compliant with PID Policy within the EOSC. But it may also be of interest for technically 
interested PID practitioners and for policy makers acting on an organisational level. 

1.2 

Overview and Previous work 

A PID is defined to consist of a PID string and a PID resolution system that has to persist 
on  a  technical  and  organisational  level  and  that  resolves  the  PID  string  to  a  structured 
record  consisting  of  a  reference  and  of  well-defined  other  attributes,  called  Kernel 
information  types,  to  allow  machine  actions.  More  details  on  the  nature  of  PIDs  and  its 
resolution can be found in the following and in the glossary at the end of this document, 
and also in the EOSC PID Policy document ([EOSC PID Policy TF 2020]). 

PID Services are technically implemented services to mint and resolve PIDs, PID systems 
are the technical hardware and software components that provide these services and a PID 
Framework describes a governance structure together with the technical infrastructure that 
allows organizations to implement PID Services for their needs within agreed policies.  

The awareness of the importance of PID systems for science, at the beginning mainly for 
scholarly publication, is over twenty years old and has led to a couple of publications. Most 
sources were more or less explicitly restricting the scope to PIDs for publications and data. 
We have chosen five sources with a generic viewpoint: 

  two studies on PIDs of the German Nestor project ([Bütikofer 2009], [Schroeder 2009]),  

  two more recent articles on stability and scalability of PID systems in the data science 

journal ([Golodoniuc e.a.  2017], [Klump, Huber 2017]),  

  the PIDwijzer PID Guide, a query tool that tries to map user requirements to suitable 

PID systems ([PIDwijzer 2017]),  

and three surveys made from a community or research organisation stance: 

  the ENVRIplus report D6.2 on negotiations with publishers, providers of existing data 
citation systems and other scientific organisations on implementing a global data citation 

4 

 
 
 
 
PID Architecture for the EOSC 

system, that evaluates in D4.4.2 a survey of ten questions targeted to Publishers, PID 
service providers, Indexers and Others ([Hellström e.a. 2018]),  

  a survey on data identification technologies and criteria to assign persistent identifiers 

to earth science data ([Duerr e.a. 2011])  

  and additionally, a study of PID experts from the Max-Planck-Society ([Bulatovic e.a. 

2008]).  

These  studies  analysed  the  technical  and  organisational  design  of  PID  systems,  their 
robustness,  trustworthiness,  their  usability  and  their  weaknesses.  Although  all  sources 
were  targeting  a  different  audience  and  had  a  different  final  goal,  the  topics  raised  and 
their  major  viewpoint  are  supplementary  and  give  a  good  overview  over  different 
characteristics of PID systems, such that one can derive some minimal commonalities and 
typical differences from these characteristics.  

An analysis of these sources allows a categorization of the basic criteria for and components 
of a PID Architecture into aspects of Infrastructure and Security and Object management 
which  are  directly  related  to  the  subject  of  this  document,  and  into  the  Organisational 
Framework which has much more relation to the EOSC PID Policy document ([EOSC PID 
Policy TF 2020]) and which emphasizes a strong connection between these two documents. 
Most of the aspects of the categories Infrastructure and Security and Object management 
are discussed more closely in the following. A detailed classification can be found in the 
chapter 11.1 Categories and Criteria of PID systems below. 

1.3 

PID Strings, PID Records and Resolution 

Typically, users perceive PIDs as strings given as a reference. These strings usually have 
an  internal  syntax  that  is  used  to  separate  namespaces  in  order  to  guarantee  global 
uniqueness which is a necessary prerequisite for a proper reference. How namespaces can 
be used to induce policies and how they can indicate a possible interoperability is described 
in section 2.2.5 Namespaces, Governance, Policies and Interoperability below. 

But in order to get the reference for a PID more is needed. Firstly, the referring target of 
this  reference  needs  to  be  stored  somewhere  and  permanently  kept  up  to  date,  and 
secondly there must be a resolution service that gives back the referring target for a call 
with  the  PID  string.  The  referring  target  stored  together  with  the  PID  string  is  called  a 
(minimal) PID  record, stored in the database of a PID repository, the  service that gives 
back the referring target is called a PID resolver. 

The  resolver  again  has  a  certain  address  and  often  these  resolver  addresses  differ  for 
different  namespaces.  From  a  conceptual  and  also  from  a  usability  viewpoint  this  is 
suboptimal, because a PID string cannot be resolved directly, but always needs in addition 
the respective resolver address. 

For some PID concrete  kinds of implementation, here called PID Frameworks, the  same 
resolver address is suitable for all namespaces inside the framework which is then called a 
global  resolver,  but  for  others  this  is  not  the  case.  In  any  case,  global  resolvers  inside 
different  frameworks,  distinguished  by  different  namespaces,  actually  do  not  solve  the 
global resolution problem for all PID frameworks. For this purpose, an additional service, 
often called a global meta-resolver, is needed. 

For example, https://dx.doi.org is the global resolver for the DOI framework based on the 
Handle system, which can also resolve all other  Handle based PID.  Instead  ORCID uses 
the http://orcid.org global resolver, but neither ORCID PID can be resolved by other global 
resolvers, like the DOI one, nor can the ORCID resolver resolve any other PIDs. A more 
generic and universal solution would be beneficial here and is discussed in the chapter 8 
Gaps in the Existing PID Landscape and Challenges for Investigation and Development. 

5 

 
 
 
 
PID Architecture for the EOSC 

1.3.1 

Fragment or Template Support 

Additional to the resolution of a PID to a digital object the reference may point to a target 
that is subordinate to this primary resource, in general provided by an additional service 
on  top  of  the  digital  object.  Typical  instances  are  parts  of  the  objects  like  small  frames 
inside images, pages or words inside text objects or cut-outs in video or audio sequences.  

For  a  URI  (see  also  the  w3c  definition1  and  the  RFC  39862)  the  subordinate  target  is 
identified by adding a "#" sign to the end of the primary resource path followed by the so-
called fragment identifier, which can point to anything, not necessarily just a part of the 
primary resource.  

For PIDs this requires the distinction of a delimiting character (not necessarily the "#" sign) 
that distinguishes between the PID part and a fragment part, and additionally the support 
to append the fragment part after  resolution to the primary object to the location path. 
Since  this  process  is  a  kind  of  pattern  matching  in  the  PID  string  it  is  often  also  called 
template support.  

Several  PID  frameworks  support  this  kind  of  fragments  like  the  URN,  ARK  or  Handle 
system. But it has to be noted that the persistence of the reference cannot be guaranteed 
anymore by the policies of the PID systems itself or their PID service providers, but rely 
additionally on policies of the local resource provider about the stability of the additional 
services that provide the fragments. 

From  an  architectural  viewpoint  the  additional  services  itself,  an  ongoing  monitoring  of 
such services over time or identifying commonalities and divergence, are outside the scope 
of  this  document  for  now,  because  they  are  part  of  the  repository  design.  In  a  future 
version of the PID Architecture valuable practice might be recommended or defined. The 
fragment  support  as  such  however  needs  an  intrinsic  and  generic  mechanism  of  the 
resolution of the PID systems, because the mechanism must work for all possible PIDs in 
the framework and target fragments. 

1.4 

PIDs versus Intrinsic Identifiers 

PIDs are defined in this context as consisting of a unique string and a resolution system 
that can provide globally unique stable references to the objects they identify usually by 
redirection. For most objects it is possible to extract identifying strings directly from the 
designated object, following a standard process like cryptographic signatures. These so-
called  intrinsic  identifiers  (see  [DiCosmo  e.a.  2019])  have  as  main  purpose  to  support 
unique identification in a decentralised way.  Integrity against modification is a by-product 
of the used hash technology. Typical examples here are cryptographic hashes (like MD5 or 
SHA-x),  that  can  be  extended  to  arbitrary  tree  structures  (see  also  [Merkle  2000])  in 
distributed file systems like IPFS, in blockchains, and in distributed version control systems 
like git, mercurial or bazaar, to track and manage changes.  

This approach can be beneficial for use cases, where the objects have a canonical digital 
representation, such that hashes are applicable, and where the stability of the reference is 
of minor importance. This is because the stability of the intrinsic identifier still depends on 
the stability of the repository location, even if the identifier is stable with respect to the 
object itself, as in the case of hashes.  

An  example  of  such  a  use  case  is  software  in  versioning  systems,  where  integrity  and 
identification is the major concern. This approach of intrinsic identification and the question 

1 https://www.w3.org/DesignIssues/Fragment.html  

2 https://tools.ietf.org/html/rfc3986  

6 

 
 
 
 
                                                 
PID Architecture for the EOSC 

on how to provide stable references  for instance for  software publications, is covered in 
the EOSC report on Scholarly Infrastructures for Research Software provided by the SIRS 
taskforce [DiCosmo et.al. 2020]. 

Depending on the use case at hand, PIDs and intrinsic identifiers may offer complementary 
advantages, and further research should be performed to better understand how and when 
they should be used together. 

Both approaches coincide in an abstract way in the special case, where PIDs use hashes 
inside their representing strings or intrinsic identifiers use databases storing the reference 
to the object.  Actually, namespace based PID systems can reference every digital object 
behind an intrinsic identifier simply by using the hash as a suffix together with a prefix of 
choice,  as  it  is  described  in  more  detail  in  the  section  2.2.5  Namespaces,  Governance, 
Policies  and  Interoperability  below.  There  the  general  role  of  thumb  for  the  choice  of 
prefixes is the  organisational granularity, meaning that for  each organisation of  control, 
for instance a repository, a separate prefix should be used. There exist PID systems, like 
the Handle system, that are able to reference directly without any additional intermediate 
technology  to  the  repository  representation  of  the  digital  object  by  a  pattern  matching 
function inside the local PID service. 

The most important distinction between these different concepts is therefore their view on 
persistency: PIDs enable persistency of the reference, hashes enable persistent integrity. 
Both  approaches  can  be  enhanced  by  their  mutual  lacking  part.  But  for  PIDs  it  is  fairly 
simple  to  enable  integrity  checks  by  for  instance  incorporating  the  hash  into  the  suffix, 
whereas  for  hashes  often  the  whole  database  infrastructure  needs  to  be  built  on  top  to 
ensure the redirection needed for persistent reference.  

We will concentrate in the following on the persistence of reference. 

1.5 

PIDs as an Abstraction to Hide Inner Complexity 

Abstraction is a generic way to hide heterogeneity  and complexity by encapsulation and 
virtualization. By encapsulation details are hidden that are not needed at a specific layer 
and  by  virtualization  one  substitutes  objects  by  their  logical  representation.  The  most 
abstract  way  of  such  a  logical  representation  is  the  pointer  that  leads  to  the  object,  a 
classical and often used approach in Computer Science, hiding all complexity behind a pure 
reference to the object. 

Since  data,  but  also  services,  are  and  must  be  available  across  domains  and  sites,  the 
pointer to them has to be a reference that is globally unique. A global reference as a URL 
could  be  seen  as  the  easiest  option,  but  URLs  are  unpredictable  unstable  references, 
because they change if the location of the data changes. See also [Klein e. a. 2014] for a 
deeper analysis of this problem and its consequences for scientific reproducibility.  

An additional level of redirection that decouples location and reference is needed and this 
redirection essentially is the rationale behind persistent identifiers. They are just globally 
unique strings without any semantics, but each such string has a record in the database 
of a PID repository that leads to the object, for instance via URL. If it changes, the database 
record can and should be changed.  

PIDs are broadly accepted as meeting most use cases for identifying objects sustainably 
over time independent of their location. And since we are dealing with global references, 
they need to be globally resolvable, meaning that there must be a simple globally organized 
way that leads to the referred object. Otherwise, these references would not be pointers 
in the sense of a logical representation in Computer Science.  

The following diagram is frequently used to show similarities between the TCP/IP and PID 
layered models and to compare the importance of PIDs for data sources with that of IP for 

7 

 
 
 
 
PID Architecture for the EOSC 

the network technology. It was used for example in the report “Data Management Trends, 
Principles and Components – What Needs to be Done Next?” [Almas e.a. 2015] and dates 
back to a presentation of Larry Lannom in September 2014 at the RDA Plenary session in 
Amsterdam for the Data Foundation and Terminology WG that gave an overview of their 
findings in [Wittenburg e.a. 2014]. 

Figure 1. The comparison of PID and IP both as abstractions and mediators between underlying technology and services 
implemented on top of them. 

The general idea behind this diagram is that components in the diagram at a certain level 
rely  more  or  less  on  the  specifications  provided  for  the  components  below.  The  strong 
hypothesis of the diagram is that the narrow waist, consisting of one component together 
with  a  reliable  interface,  distinguishes  between  lower  and  upper  components.  All  levels 
below the centre of the hourglass can be seen as ‘underlying infrastructure’ and all levels 
above  it  are  leading  to  a  wide  variety  of  applications  with  both  sides  having  maximum 
freedom  to  make  implementation  choices  independent  of  specific  infrastructure 
components.  A  minimal  set  of  normative  standards  to  ensure  connectivity  between  the 
'upper'  and  'lower'  levels,  while  ensuring  freedom  to  operate  within  those  zones,  was  a 
driving force for scaling the internet and could fulfil the same purpose in the realm of data 
management. The  centre of the hour glass is  this  way both, a technical specification as 
well as an abstraction to hide inner complexity. 

1.6 

PIDs, Digital Objects and FAIR Digital Objects 

PIDs play an important role in the concept of Digital Objects (DOs) which is an abstraction 
of data by the identification of minimal elements that are to some degree atomic from the 
perspective  of  data  management  and  reuse.  Already  more  than  twenty-five  years  ago 
these elements have been called digital objects, as described in a reprint of an article from 
1995 [Kahn, Wilensky 2006], which was reused and adapted by the RDA working group 
on  “Data  Foundations  and  Terminology”  [Berg-Cross  2015].  They  can  be  thought  of  as 
some  generalization  of  files  in  local  file  systems  or  streams  of  streaming  providers  for 
instance  with  a  manifestation  as  bit  sequences,  referenced  by  PIDs  and  described  by 
metadata. And they are embedded in a structure of other important data concepts as one 
can see in the Figure below. 

8 

 
 
 
 
 
 
 
PID Architecture for the EOSC 

Figure 2. The View on Digital Objects as described by the RDA working group on “Data Foundations and Terminology”. 

The relevance for PIDs for findability and interoperability was already investigated in 2017 
and  then  extended  and  revised  in  the  context  of  the  well-known  FAIR  principles  by 
[Philipsson  2019],  where  the  importance  of  metadata  again  was  emphasized.  The  FAIR 
principles  and  Digital  Objects  are  conceptually  complementary  approaches,  DOs  are 
technical  abstractions  whereas  FAIR  principles  are  policies,  as  it  was  explained  in 
[Schwardmann 2020].  But a deep interconnection of both approaches can be extremely 
fruitful,  because  concrete  implementations  of  DOs  lead  to  data  structures  that  implicitly 
comply with at least parts of the policies. The term FAIR Digital Objects or FDO refers to 
this  interconnection  and  describes  a  binding  of  persistent  references  with  metadata 
registered as types in so-called data type registries such that such objects can be seen as 
well structured, transparent and atomic elements in a data management landscape. 

9 

 
 
 
 
 
 
 
PID Architecture for the EOSC 

2 

COMPONENTS AND ACTIVITIES IN A PID ARCHITECTURE 

2.1 

The PID consumer's view of the global PID architecture 

2.1.1 

Technological Independence 

The  document  on  PID  policy  for  EOSC  [EOSC  PID  Policy  TF  2020]  requires  technology 
independence of PIDs to allow for technological change and to identify the level of service 
maturity suitable for EOSC adoption. Many, if not almost all references to digital objects 
today rely to some extent on HTTP(S) technology that will not last forever, and when it will 
become obsolete, a gigantic migration will take place. In such a case those parts might get 
lost in the first place that do not have an immediate benefit. This could lead into a big loss 
of digital heritage. It will be crucial in such a case that the technology to reach the digital 
objects from their references will be one of the easiest parts to be migrated. If the reference 
is  resolvable,  at  least  a  former  location  is  visible  and  the  repository  can  be  made 
responsible for further providing access to the digital object by changing the location in the 
reference. 

Strings are generic and completely independent from technology, whereas the resolution 
relies  on  technology.  The  boundary  between  technological  independence  and  concrete 
technological implementation, which is crucial for the long-term maturity of PID services, 
runs therefore between the representation of PIDs as strings and its resolution, mainly at 
the  level  of  the  concrete  PID  record.  Openness  of  the  concrete  implementation  of  PID 
record  storage,  its  universality  and  its  possible  alternatives  of  access  are  an  important 
indicator of this long-term maturity. 

The  diagrams  in  this  chapter  show  the  main  components  and  the  foreground  and 
background activities in a PID architecture. The coding of the edge style gives hints about 
the kind of access control needed for the respective relations in the diagrams. The different 
node  styles  describe  the  inner  complexity  of  organisational  and  technical  entities.  An 
explicit explanation is given in chapter 10 Symbology of Architecture Diagrams below. 

2.1.2 

PID Usage and Administration 

PID usage in the Global PID Architecture and its administration activities are shown in the 
following diagram: 

Figure 3. Actions between the PID consumer and the global PID Architecture 

The labelled edges have the following meaning 

10 

 
 
 
 
 
 
 
PID Architecture for the EOSC 

queries PID: given a PID the consumer asks for the resolution of the PID to its reference 
or the complete content of the PID as maintained in the PID architecture or parts of it. This 
is the most basic activity on the consumer side. 

resolves PID: is the answer  of the PID architecture to such a  PID query above.  It  can 
return  (parts  of)  the  content  of  the  PID  or  provide  by  redirection  a  direct  access  to  the 
special location given in the reference of the PID 

administer PID: the PID consumer registers, often called mints, a new PID or could also 
modify the content of a PID. The PID consumer is the owner or administrator of the PID. 
This  requires  in  general  a  specific  namespace  (here  called  prefix)  to  guarantee  global 
uniqueness  of  the  PID  strings  and  special  access  credentials,  as  indicated  by  the  arrow 
style (see symbology), for write access inside this namespace.3 

request Prefix: is the operation to require a namespace (prefix) for PID registration. This 
implies in general the right to register and modify PIDs under this prefix and is technically 
realized with a prefix credential. The authorisation is contract based. 

issues Prefix Credential: is a shortcut for issuing a credential for a requested namespace 
(prefix). The authorisation is contract based. 

accesses  Prefix:  beside  the  minting  or  update  of  PIDs  inside  a  given  namespace  the 
consumer can get together with the prefix credential the right to access and change records 
about  the  prefix  and  administer  here  additional  configurations  for  the  given  namespace 
like further delegation of access rights, define additional policies and/or profiles that are 
valid for the whole namespace. The authorisation is credential based. 

The  PID  consumer  can  be  any  individual  user  or  organisation  that  conducts  any  of  the 
operations on the global PID architecture, i.e., queries, resolves, registers, modifies PIDs 
or requests or accesses prefixes or issues prefix credentials. Often this picture is too coarse 
and a distinction between individual users and organisations like repositories give a better 
understanding  of  the  processes.  In  the  following  the  PID  consumers  are  therefore 
distinguished as users and repositories.  

Figure 4. A distinction between the user as the PID and data controller and the repository as the reliable PID and data 
processor and maintainer is made here. 

3 There are exceptions to the right to modify possible, like 'no modifications after registration' or delegation of modification rights (to parts) 

of PIDs to others. But such details do not change this possible relation between PID consumers and the global PID architecture, only the 

individuals or their specific rights change.  

11 

 
 
 
 
 
 
                                                 
PID Architecture for the EOSC 

The user's and repository's view of the global PID architecture is given in figure 4. Here a 
distinction between controller and processor (see GDPR) is made on the data level as well 
as on the PID level, where the user is seen as the PID and data controller and the repository 
takes the role of the PID and data processor and reliable maintainer of PID and data. 

Labelled edges are added here with the following meaning: 

requires  administration  of  PID:  the  user  as  the  PID  controller  requires  from  the 
repository as the PID processor a PID registration or a modification of the PID reference or 
additional metadata. 

registers  Data:  a  reliable  data  repository  maintaining  data  is  also  responsible  for  the 
registration of that data, i.e., it has to require not only the upload of the data, but also the 
enrichment of the data with metadata etc. and finally to register a PID for that data. 

accesses Data: the rationale behind the data registration at a data repository is to enable 
reliable access to the data. 

issues Data Credential: for the registration and update of data in a data repository an 
authorization mechanism is required in general. The authorisation is contract based. 

2.2 

The Global PID Registration and Resolution Framework 

2.2.1 

Administration and Resolution within a PID Platform 

As  described  before,  a  PID  is  a  string  that  references  some  digital  object  and  may 
additionally  provide  some  other  information.  The  administration  of  a  PID  is  the 
registration, which is the process to mint the PID string and to establish the reference 
and the additional information, and the maintenance, which is the update of the reference 
and  additional information.  The  resolution  of  a  PID  is  the  process  to  get  the  reference 
and possibly the additional content of the PID and is therefore part of all PID services. 

Existing PID platforms usually have resolution services, but they define their approach in 
different ways - cases with and without a global resolver exist. From a user and even more 
from an automation stance a particular PID has no value or does not even exist, if the PID 
cannot be resolved. This is not only the case, if there is no resolver at all, but also, if the 
resolution  service  is  not  known  to  the  user.  As  a  consequence,  there  are  PID  platforms 
with hidden PID contents, if there is not enough context (like the needed resolver) given 
with the PID. This means that a generic global resolver is a crucial part of all generic PID 
platforms. Therefore, global resolution needs to be described in a PID architecture and 
its  principles  have  to  be  defined  here,  even  if  this  service  is  not  provided  by  all  PID 
platforms. This is described initially in the following as a service inside PID platforms. The 
question for a cross-platform resolution will then be raised in section 2.2.6 A Generic Global 
PID Resolution Architecture below. 

2.2.2  Global Resolvers 

Some PID platforms provide global resolvers for the PIDs in their realm, such that for these 
PIDs one gets a resolution via the global resolver of that platform. 

To ensure scalability for registration and resolution in large systems the workload has to 
be distributed and a natural approach for distribution can be the hierarchical structure of 
namespaces within the given strings. This means that at a top level a service only needs 
to know which services are responsible for the resolution in the subordinated namespaces, 
which naturally defines a hierarchical structure of distributed services. Scalability can be 
reached by adapting the levels of distinguished namespaces. 

Therefore, the organisation of well-defined namespaces in a PID architecture is not only a 
precondition of global uniqueness for the registration of PIDs but also a precondition for a 
high-performance resolution of these PIDs, at least on a large scale. 

12 

 
 
 
 
PID Architecture for the EOSC 

The global PID Architecture in general therefore consists of PID services, able to register 
and  resolve  PIDs,  often  implemented  as  database  instances  driven  by  a  Local  PID 
provider, and a component that guarantees global uniqueness of the PIDs for registration 
by assigning name spaces for prefixes and a global entry point for resolution of PIDs. 

2.2.3  Global PID Registration and Resolution Activities 

The PID consumer is related to these components by the following activities. With respect 
to the activities described in the section before from a PID consumers view the Local PID 
Provider is an internal and hidden component with hidden activities. 

Figure 5. Here the different roles and their relation to each other for local and global resolution are described with respect 
Here the distinction between user and repository is neglected again and with the new nodes 
to the PID consumer. 
described above labelled edges are added here with the following meaning: 

implements and runs PID service: The actual PID service is run by an organisation that 
is able to have contractual relations to stakeholders in the global PID architecture, the PID 
provider.  The  authorisation  is  credential  based,  and  if  it  is  an  in-house  dependency,  no 
contract is needed. 

resolves Prefix namespace: the first step of a PID resolution in a global environment is 
to  find  out,  which  local  instance  is  responsible.  This  is  the  resolution  of  the  prefix 
namespace, which also implies the delegation of the resolution of the PID given with this 
prefix. 

provides  PID  service  info:  The  global  PID  registration  and  resolution  infrastructure 
needs  status  information  in  order  to  control  the  overall  reliability  of  the  global 
infrastructure. The authorisation is contract based. 

retrieves allocated Prefix: This is the answer to a consumer request for a prefix to the 
global PID architecture. Since the prefix is in general not maintained at the consumer side, 
this is delegated to a local PID provider. The authorisation is contract based. 

2.2.4 

Internals of the Global PID Registration and Resolution 

An additional unfolding of the internals of the global PID registration and resolution and a 
description  of  the  interdependencies  of  the  internal  components  is  shown  below.  Here 
essentially a Global PID Registry is the technical component that is able to automatically 
resolve the prefix namespaces and to  delegate the PID resolution request to a local PID 
13 

 
 
 
 
 
 
PID Architecture for the EOSC 

service.  This  registry  needs  to  be  maintained  by  those  stakeholders  that  allocate  prefix 
namespaces and the maintainers are called registrars. 

2.2.5  Namespaces, Governance, Policies and Interoperability 

As described in the subsection about PID Strings, PID Records and Resolution above, it is 
helpful to use the same resolver address as a global resolver for all namespaces inside a 
specific framework.  

But, additionally to the technical delegation, there is a need for a namespace assignment 
to  local  organizations.  This  responsibility  for  the  namespace  assignment,  called 
registration authority, can be a simple table maintained by a system administrator, but 
also can be a complicated high level and international agreement with responsibilities of 
different stakeholders.  

Figure 6. shows the internals of the global PID registration and resolution and a description of the interdependencies of 
the internal components. 

In  this  picture  we  describe  an  example  of  a  registration  authority  that  distinguishes 
between  top  level  and  second  level  registration.  On  the  second  level  namespaces  for 
prefixes  are  registered  and  also  an  additional  registrar  is  implemented  to  register  the 
prefixes in the global PID registry. This model is a possible scenario for prefix registration, 
where the namespaces of one delimiter prefixes from different top-level namespaces could 
be administered by one registration authority, but registered by different registrars. Such 
a scenario as it is described in Figure 6 is for instance possible in the Handle world, whereas 
in the URN framework each namespace is managed differently.  

 With these new nodes also labelled edges are added here with the following meaning: 

assigns  Prefix  namespace:  the  top-level  registration  authority  assigns  the  top-level 
prefix namespaces  

implements and runs Global PID Registry service: the top-level registration authority, 
responsible for the top-level prefix namespace runs in this case also the global PID Registry 
by itself. This could be also delegated to a top-level registrar. 

registers  Prefix  namespace:  the  responsibility  for  the  second  level  namespaces  is 
handed  over  to  second  level  registration  authorities,  which  register  namespaces  for 
prefixes. 

14 

 
 
 
 
 
 
 
 
PID Architecture for the EOSC 

issues Prefix credential: To fulfil their task the registrars need credentials to be able to 
make changes in the global PID registry. 

registers Prefix: given these credentials the registrars can register prefixes. 

Namespaces  and  its  governance  also  give  the  opportunity  to  introduce  policies  in  a 
hierarchical manner in the sense that policies described for a certain namespace can be 
inherited by all sub-namespaces. This is a powerful concept to provide transparency in the 
PID  usage  and  the  promises  bound  to  PIDs.  The  maximal  common  namespace  and  the 
policies  defined  at  that  namespace  level  can  give  a  clear  understanding  about  possible 
commonalities for PIDs from different namespaces.  If the policies are directly related to 
information or interfaces, for instance by describing the metadata or access rules provided 
within  a  namespace,  this  immediately  provides  the  level  of  interoperability  that  can  be 
expected for different PIDs. 

It is therefore important inside such a namespace induced policy framework to ensure that 
policies  on  a  certain  level  fulfil  exactly  the  required  need  for  commonalities  without 
hampering possible additional freedom or requirements on lower levels. It is a matter of 
governance  to  arbitrate  these  possible  benefits  and  conflicts  of  interest  to  ensure  an 
optimal policy framework. Such a policy governance should be implemented therefore at 
the level, where different sub-namespaces are controlled by different stakeholders and the 
general rules should be defined at the top level of the namespaces. 

A typical policy in namespace based PID systems is to bind namespaces to organisational 
granularity. As described in the Glossary a prefix is a PID syntax component denoting an 
authority or division of a namespace. A prefix needs to be globally unique associated with 
particular local authorities which are free in how they generate locally unique IDs. Binding 
namespaces to organisational boundaries has the advantage of one-to-one communication 
between authorities during administration inside namespaces and to impose organisation 
wide policies. 

2.2.6 

A Generic Global PID Resolution Architecture 

Whereas  the  Global  PID  Resolution  Framework  described  above  provides  a  generic 
resolution entry point within a certain PID platform, a generic global resolution for all PIDs, 
as described in the subsection about PID Strings, PID Records and Resolution above, is still 
not  available.  This  has  several  reasons,  some  of  them  are  intrinsic,  because  some  PID 
systems do not even provide resolution in the sense described above. But others are more 
organisational and depend on a lack of an agreement between the different PID platforms.  

The resolver approach above, as it is used inside a distinguished PID platform, can be used 
again  at  that  level  by  setting  up  a  resolver  that  delegates  to  the  resolver  of  a  certain 
namespace. A precondition is that the PID strings of different PID platforms can be mapped 
to  different  namespaces,  which  will  be  often,  but  probably  not  always  the  case.  Such  a 
generic global PID resolution architecture would even work, if the PID platform does not 
provide its own global resolver, if it only has resolvers for all its internal namespaces and 
these resolvers would be made known to the global PID meta resolver. 

2.3 

Types and Profiles in a Global PID Registration and Resolution Framework 

As described above FAIR Digital Objects (FDOs) bind persistent references with metadata. 
In  order  to  ensure  machine  actionability  it  is  not  sufficient  to  describe  the  metadata  in 
human readable documents. The schema definition of this metadata has to be registered 
as types in so-called Data Type Registries. These DTRs were explicitly described in the 
RDA  working  group  on  data  type  registries,  noted  as  ICT  Technical  Specifications  for 

15 

 
 
 
 
PID Architecture for the EOSC 

referencing  in  public  procurement  of  the  EU4,    and  are  standardized  in  ITU-T  X.12555. 
There exist mature implementations for DTRs with TRL 8-9. Additionally, for PIDs used in 
a certain context it can be required that a certain set of types is available with mandatory 
and  optional  types.  Such  requirements  are  called  profiles  and  can  be  maintained  in  so-
called Profile Registries. Profile registries are still under discussion, but can rely on the 
same underlying technology as DTRs. 

These  data  type  and  profile  registries  are  currently  emerging.  It  is  necessary  that 
interoperability between these registries is ensured. Therefore, a governance structure and 
federation  of  these  registries  has  to  be  implemented  on  the  level  of  type  registrars  and 
profile  registrars,  where  the  latter  will  be  in  general  organisations  or  communities.  The 
relations of types and profiles together with their registries to the local PID service is given 
in  the  following  diagram,  where  the  PID  consumer  and  Global  PID  Registration  and 
Resolution components are again to single nodes. 

Figure 7. The role of Data Type and Profile Registries as components of the PID architecture. 

With these registries and registrars as new nodes labelled edges are added here with the 
following meaning: 

administers  Type  (or  Profile):  Registrars  are  responsible  for  Type  (or  Profile) 
registration. 

looks up Type (or Profile): types in the Type registry are publicly readable  

refers to Type: kernel information or PID information types can be used in PID records 
referring to the type definitions in the data type registries 

complies to Profile: PIDs with kernel information or PID information types can comply to 
profiles described in the Profile registries. Policies can be made that certain PIDs have to 
comply with certain profiles. 

issues Registry credentials: the type (or Profile) administration needs credentials. 

4 Topic (13) in Decision (EU) 2017/1358 of 20 July 2017: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32017D1358 

5 http://handle.itu.int/11.1002/1000/11951 

16 

 
 
 
 
 
 
 
 
 
                                                 
PID Architecture for the EOSC 

3 

CERTIFICATION 

The PID Policy v2 document [Hellström et al. 2020] mentions certification in section 7.5.: 
For EOSC we need a set of trusted registration PID Authorities and PID Service Providers 
that  are  regularly  certified  based  on  agreed  rule  sets.  Certification  should  cover  both 
resolvability  of  PIDs  to  information  from  PID  Service  Providers  and  their  management 
processes  for  maintenance  of  PIDs.  It  should  clarify  who  is  responsible  for  keeping  the 
Kernel Information up-to-date, if necessary, by enabling third parties to modify it. 

The  EOSC  FAIR  Working  Group  (WG)  created  a  Metrics  and  Certification  Task  Force  to 
coordinate  the  certification  approach  that  will  be  applied  within  EOSC  for  repositories, 
services  and  other  elements  of  the  FAIR  ecosystem  that  enable  FAIR  research  output, 
together with the companion activities on Metrics to certify FAIR digital objects. This task 
force is aware of the process described in this chapter for PID services and refers to the 
subtopics for the certification process described in the following. 

PID services need a special level of trustworthiness and certification is a possibility to raise 
the level of trust in these services. PID registration authorities and PID service providers 
have  to  be  certified  by  independent  agencies  and  such  certification  agencies  would 
essentially  evaluate  whether  the  relations  between  the  actors  in  the  diagram  above  are 
properly  working.  This  would  be  not  only  a  control  of  technical  processes,  but  also 
operational and governance aspects are evaluated. 

Especially  the  persistence  expectation  for  PIDs  raises  a  special  requirement  that  goes 
beyond institutional borders, because an institutional failure in providing the service needs 
a fallback by other institutions, for short institutional failures as well as for a permanent 
shutdown  of  the  service  for  whatever  reason.  This  kind  of  trust  can  only  be  reached  by 
special contracts made between service providers that have themselves already a certain 
level of trustworthiness and institutional persistence promise.  

With  a  description  of  the  certification  process  certain  subtopics  have  to  be  described.  A 
first incomplete list of topics specific for persistent identification is given in the following. 
It  can  be  completed  with  topics  from  more  general  certification  models  as  described  in 
[L’Hours 2019]: 

  Quality assurance (Stability and Performance) 

●  public service level agreements, 
●  organisational measures taken to ensure the persistency of the service, 
●  PID stability and consistency checks including contractor notifications in case of 

● 

errors,  
redundancy of PIDs to guarantee services according to the EOSC PID Policy 
Document,  

●  measurements to prevent information loss in case of crashes (backup, mirroring),  
●  a guarded PID deletion strategy, with a process to create a tombstone note in 

case that a Digital Object was deleted. 

  Long term persistence 

●  With which temporal time frame (long-term funding statements business model 

and warning period for possible casement)  

●  an exit strategy in case of ceasing a service (with cross institutional contracts 

about service continuation) 

  Security 

●  ensure that no unauthorised changes are possible 

17 

 
 
 
 
PID Architecture for the EOSC 

  Support 

●  What if there are complaints against resolution or generation of PIDs? 

  Certification process 

●  What if there are complaints against the result of evaluation (like not certified)? 

Since  persistence  is  a  promise  with  PIDs  this  aspect  must  have  a  special  priority in  the 
certification  process.  Persistence  can  be  supported  by  technical  processes,  but  is  more 
dependent on social contracts that have been agreed upon which is difficult to assess.  

Certification is a possibility to gain trust, but not only trust but also clarity is needed. This 
document tries to lay out a general PID architecture in order to support clarity in the PID 
landscape and a compliance to this described PID architecture can therefore also be a topic 
in a certification process. 

18 

 
 
 
 
PID Architecture for the EOSC 

4 

IMPLEMENTATIONS 

The components and activities in a PID Architecture are given in a different expressiveness 
by the different concrete implementations of PID frameworks. From the user perspective 
these  PID  frameworks  have  different  advantages  and  disadvantages,  partly  because  of 
their architectural design, and partly because of different implicit and explicit policies. An 
overview of the different kinds of questions in this context and also a recommendation of 
the most suitable system, although from a limited number of possible choices, can be found 
at the PIDwijzer online tool [PIDwijzser 2017]. 

4.1 

The Handle based Systems 

4.1.1  Namespace Governance 

The Handle technology provides most of the components described in the PID Architecture 
above. Prefix and suffix of the PID string are distinguished by the first slash (“/”) from the 
left. The namespace governance for the Handle system is organized on several levels with 
DONA, the Digital Object Numbering Authority, responsible as registration authority and 
also registrar for the top-level namespaces that are determined by the leftmost digits to 
the first dot (“.”) from the left as a so-called delimiter6. These top-level namespaces are 
delegated to the so-called Multi Primary Administrators (MPAs), which are responsible for 
the whole prefix namespace starting with their digits of the top-level namespace. The MPAs 
can delegate their namespace again in two ways. First there is the delegation of the whole 
prefixes they mint, such that the organizations responsible for these prefixes can generate 
arbitrary  suffixes.  But  secondly  there  is  the  option  to  also  delegate  whole  prefix 
namespaces with so-called two or more delimiter prefixes. 

4.1.2 

Resolution 

The  Handle  system  provides  a  global  resolution  system  that  is  hierarchically  organized 
along  the  namespaces.  The  Global  Handle  Registry  (GHR)  is  the  top-level  resolver  for 
Handles and is maintained by the MPAs as a distributed system. 

6  There still exist so-called legacy prefixes without any delimiter, coming from former pre-DONA times, that are owned by some of the 
Handle MPAs and maintained for persistence under special contracts with DONA. 

19 

 
 
 
 
                                                 
PID Architecture for the EOSC 

Figure 8. The Handle resolution framework 

For  each  prefix  in  the  Handle  frame  work  is  a  so-called  Handle  service  or  Local  Handle 
Service (LHS)  responsible for PID generation  (or minting) and resolution. Depending on 
the prefix of the PID a resolution request is delegated from the GHR to the respective LHS. 
Each LHS can consist of several service implementations: authoritative, if they can be used 
for  minting,  or  mirrors,  if  they  are  only  used  for  resolution.  For  performance  reasons 
caching and an algorithm that prefers the service with fastest response is implemented on 
each level of the resolution infrastructure. The GHR supports geographical load balancing.  

4.1.3 

Templates and Fragment Support 

Fragments  are  supported  in  the  Handle  resolution  system  by  the  so-called  Template 
Handles  as  described  in  the  Handle  Technical  Manual7  by  a  generic  pattern  matching 
mechanism that uses the defined delimiting character to split the reference string into PID 
and fragment, resolves the PID to the location path and appends the fragment part after 
a new delimiting character (usually “#”) to construct the full fragment path. This pattern 
matching rule can be implemented at every level of the handle namespace hierarchy from 
the prefix to the Handle, where lower entries overwrite the higher entries in the hierarchy. 

These template rules are defined by some pseudo code in an HS_NAMESPACE attribute in 
the prefix or PID records and are much more flexible than just describing fragment rules. 

7 See: http://handle.net/hnr_documentation.html 

20 

 
 
 
 
 
 
 
 
                                                 
PID Architecture for the EOSC 

For instance, the resolution of PIDs of other PID frameworks can be based on the Handle 
system  via  this  pattern  matching  mechanism.  This  way  a  global  resolution  framework 
based  on  the  Handle  system  can  be  realized.  The  special  policy  and  concrete  usage  of 
templates  within  the  DOI  system  is  described  in  chapter  2  in  a  document  about  the 
Conceptual Model of Resolution8.  

4.1.4 

Types 

Together  with  the  reference  to  the  location  of  the  digital  object  a  Handle  PID  can  also 
contain  metadata,  called  PID  information  types  or  kernel  information  in  the  PID  record 
inside the Handle service database. For machine actionable definition and disambiguation 
of such types the Handle system provides additional software (called CORDRA) to register 
such types with PIDs. Furthermore, this software is able to register arbitrary Digital Objects 
in  the  so-called  Digital  Object  Interface  Protocol  (DOIP),  a  general  framework  that 
describes protocols for Digital Objects as well as for digital services. 

4.1.5  Generic Global Resolution 

Inside the RPID project9 the possibility to set up a resolution system for URNs using the 
Handle  Resolvers  was  investigated.  The  finding  was  that  with  the  very  powerful  pattern 
matching engine inside every Handle resolver it is possible to map given URN PID strings 
to specialized Local Handle Servers that are able to resolve the URN PID to their location. 
This way the URN PID service that does not have a global resolution on its own can easily 
be integrated into the global resolution system of the Handle system. Similar approaches 
are possible in principle for all namespace based PID systems, where the pattern match 
engine  of  the  resolvers  can  be  used  and  a  generic  global  resolution  system  could  be 
implemented via this technology. Nevertheless, it always requires the cooperation of the 
PID system providers. 

4.1.6 

Examples 

4.1.6.1  ePIC 

The ePIC Persistent Identifier Consortium for eResearch10 is an international consortium of 
currently  nine  members  that  signed  a  contract  to  provide  a  reliable  Handle-based  PID 
infrastructure for research data. Part of the contract are for instance the mutual guarantee 
of service continuation, if a member fails for whatever reason, and a Quality of Service and 
Policy document11, in which all regulations for the reliability of the provided PID services 
and the policies under which PIDs are maintained are described. ePIC also certifies other 
PID  service  providers  to  comply  with  these  regulations  and  policies.  The  ePIC  member 
GWDG12  is  MPA  of  DONA  on  behalf  of  ePIC  and  owns  the  namespace  21  in  the  Handle 
system and delegates prefixes to its members.  

4.1.6.2  B2Handle (from the EUDAT Service catalogue) 

EUDAT’s B2HANDLE is a distributed service for minting, storing, managing and accessing 
persistent identifiers (PIDs) and essential metadata (PID records) as well as managing PID 
namespaces.  The  implementation  of  the  service  relies  on  the  DONA/Handle  persistent 
identifier solution and complies to the quality-of-service regulations and policies of ePIC.  

8 See: https://doi.org/10.5281/zenodo.890910 

9 https://rpidproject.github.io/rpid/  

10 https://www.pidconsortium.net/ 

11 http://www.pidconsortium.net/?page_id=904  

12 Gesellschaft für wissenschaftliche Datenverarbeitung Göttingen mbH (https://www.gwdg.de) 

21 

 
 
 
 
                                                 
PID Architecture for the EOSC 

B2HANDLE can be used by middleware applications, end-user tools and other services to 
reliably identify data objects over longer time spans and through changes in object location 
or ownership. The B2HANDLE service encompasses management of identifier namespaces 
(Handle prefixes), establishment of policies and business workflows, operation of Handle 
servers and technical services, and a user-friendly Python library for  general interaction 
with Handle servers and EUDAT-specific extensions. B2HANDLE is mostly transparent to 
end-users, shielding them from the complexity of infrastructure details. In the background, 
B2HANDLE  operates  as  a  federation  and  is  based  on  policies  that  aim  to  ensure  high 
availability of Handle resolution by cross-site mirroring of Handles. B2HANDLE supports a 
dedicated Handle record structure (a PID profile) for the safe data management within an 
infrastructure with a given topology. By relying on features of the PID profile, end-users 
can,  for  instance,  ensure  authenticity  of  objects  with  checksums  and  timestamps  and 
account for replicated objects across multiple locations13. 

4.1.6.3  DataCite 

DataCite14 is a leading global non-profit organisation that provides persistent identifiers for 
research data and other research outputs. Organisations within the research community 
join DataCite as members to be able to assign DOIs to all their research outputs. DataCite 
has more than 200 member organisations as of October 2020.  

DataCite is a member of the DOI Foundation15 and uses DOIs as persistent identifiers. The 
DOI Foundation is a non-profit membership organisation with currently 10 DOI registration 
agencies. DOIs use the handle system for PID resolution, and this service is provided for 
all DOIs by CNRI16, which provides a globally distributed network of about 50 proxy servers. 
The DOI Foundation is an MPA and member of DONA. 

4.2 

The URN PID Framework 

In the URN framework prefixes and namespaces are used to ensure the uniqueness of the 
PIDs and local PID services are provided to register/modify PIDs and resolve PIDs based 
on  these  prefixes.  IANA  is  the  central  namespace  authority  for  URN  framework.  It 
maintains the registry of URN namespaces at IANA17. Each namespace has to be registered 
according  to  the  procedure  specified  in  RFC  8141.  As  of  this  writing  there  are  about  50 
namespaces.  As  an  aside,  DOI  and  Handle  do  not  have  formal  URN  namespaces 
(registration of URN:DOI namespace is under preparation), but Handle resolver has already 
been  modified  so  that  it  can  resolve  DOIs  and  Handles  expressed  as  URNs  (e.g. 
https://doi.org/urn:doi:<doi>). 

Within each namespace, namespace specific strings must be unique and persistent. Each 
namespace has a namespace identifier (such as nbn or isbn) which guarantees uniqueness 
of URNs even if a namespace specific string is used in another namespace as well. 

URN syntax (RFC 8141) does not specify a prefix or suffix. Most URN namespaces do not 
have namespace sub-divisions, but one of the few that does is URN:NBN (RFC 8458) which 
specifies a country code–based prefix to the namespace specific string. The definition of 
prefix in the draft report is generic enough to be applicable to URN:NBNs as well. 

Each  URN  namespace  can  have  different  rules,  as  long  as  these  rules  comply  with  the 
requirements  set  in  RFC  8141  and  the  namespace  registration.  So  in  the  urn:doi 

13 Source: https://sp.eudat.eu/api/v1/portfolio/services/B2HANDLE?view=complete 

14 https://datacite.org/  

15 https://www.doi.org/  

16 https://www.cnri.reston.va.us/  

17 See: https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml 

22 

 
 
 
 
                                                 
PID Architecture for the EOSC 

namespace  DOI  rules  apply,  in  urn:handle  Handle  rules,  and  in  urn:nbn  each  national 
library  and  their  partners  can  impose  their  own  rules  in  their  own  sub-namespaces, 
indicated  by  country  code  prefixes.  A  inheritance  of  rules,  based  on  the  namespace 
hierarchy, is not applied here. 

URN resolvers for non-semantic identifiers such as ISSN are global18. Semantic identifiers 
such as ISBN allow sub-division to national level. Namespaces which are administered in 
a decentralized way such as urn:nbn may have a large number of interlinked resolvers.  

Functionality  supported  by  URN  resolvers  is  modest  compared  with  the  Handle  system, 
and there is no open source URN resolver available. The National Library of Finland is as 
of this writing taking into production a revised URN resolver, which supports linking of URN 
to multiple URLs and provision of resolution services as specified in the URN syntax (RFC 
8141). The library will make the software available in GitHub.   

Therefore, the relations in this framework between PID consumers and local PID providers 
depends on the URN namespace.  In URN:NBN  the PID provider is probably local, but in 
URN:ISSN  it  is  global.  In  URN:DOI  it  could  be  either.  The  possible  relations  are 
"registers/modifies  PID",  "resolves  PID",  "queries  PID",  "accesses  Prefix",  and  "issues 
Prefix Credential", which is similar to figure 1 or figure 2 with the URN framework in the 
role of the PID architecture. Note that applying this terminology to URN context could be 
not meaningful. 

4.2.1 

Examples 

4.2.1.1  URN:NBN 

National  Bibliography  Number  (NBN)  is  a  generic  term  referring  to  a  group  of  identifier 
systems  administered  by  national  libraries  and  institutions  authorized  by  them.  The 
identifier is described in RFC 845819 

One of the roles of the NBN is to fill in the gaps left by the standard identifiers, such as 
ISBN and ISSN, that are applicable only to certain kinds of resources. Collectively, these 
identifiers and NBNs cover all resources that national libraries and their partners need to 
include in their collections. 

4.2.1.2  URN:ISSN 

ISSN  is  an  authoritative  standard  identifier  system  for  continuing  resources  and  in 
particular serial publications20.  

URN:ISSNs  resolve  to  a  metadata  record  describing  the  identified  resource  in  the  ISSN 
Portal. 

4.2.1.3  URN:ISBN 

The ISBN (International Standard Book Number) is a unique machine-readable identifier, 
which identifies unambiguously any edition of a text-based monographic publication that 
is available to the public21. 

18 e.g. http://urn.issn.org 

19 See: https://tools.ietf.org/html/rfc8458 

20 See: https://www.iana.org/assignments/urn-formal/issn and http://urn.issn.org/urn:issn:1560-1560 

21 See: https://www.iana.org/assignments/urn-formal/isbn and http://urn.fi/URN:ISBN:978-951-51-6551-0 

23 

 
 
 
 
                                                 
PID Architecture for the EOSC 

URN:ISBNs  resolve  to  a  metadata  record  describing  the  identified  resource  in  a 
bibliographic database (e.g., a national bibliography) or institutional repository. 

4.3 

The ARK PID Framework 

In  the  ARK  framework22  prefixes,  here  used  for  a  so-called  Name  Assigning  Authority 
Number (NAAN), and namespaces in the name part are used to ensure the uniqueness of 
the  PIDs  and  local  PID  services  are  provided  to  register/modify  PIDs  and  resolve  PIDs 
based on these prefixes.  

No global resolution is provided for ARKs by the ARK framework itself. For a PID consumer 
that  wants  to  resolve  a  given  PID  it  is  necessary  to  know  a  priori,  which  server  is 
responsible to resolve the PID, and to address a respective query to that very server. 

Therefore, the  relations in this framework are  always between PID  consumers and local 
PID providers. The possible relations are "registers/modifies PID", "resolves PID", "queries 
PID", "accesses Prefix", "issues Prefix Credential" and "requests Prefix", which is similar to 
figure 1 or figure 2 with the ARK framework in the role of the PID architecture. 

4.4 

HTTP identifiers 

4.4.1 

Cool URIs 

To publish information and relationships between them for the so-called Semantic Web the 
Resource  Description  Framework  (RDF)  is  implemented  where  Web  documents  and 
concepts from the real world—people, organisations, topics, things— are represented in a 
machine-actionable way. To identify these things URIs (Uniform Resource Identifiers) are 
very important, providing both the core of the framework itself and the link between RDF 
and the Web. There are various proposals collected in the W3C Cool URIs for the Semantic 
Web23 to make these URIs persistent. 

4.4.2 

PURLs 

One method to have a level of indirection for URIs is to register a URI through the PURL 
service24. A PURL is a persistent URL, it provides a permanent address to access a resource 
on the web. When a user retrieves a PURL they will be redirected to the current location of 
the resource. When an author needs to move a page, they can update the PURL to point 
to the new location. In principle this level of redirection allows a persistent reference by 
the same technical and organisational processes as for other PIDs.  

Cool URIs and PURLs also fit into the PID architecture described above, since the former 
uses the namespace conventions and governance structure of the DNS system, whereas 
the  latter  uses  intrinsic  identifiers  for  a  mapping  from  URLs  to  PURLs.  Both  approaches 
however are based on the HTTP protocol and therefore not platform independent. 

4.5 

Intrinsic Identifiers 

Intrinsic  identifiers  are  described  in  the  section  1.4  PIDs  versus  Intrinsic  Identifiers  and 
have concrete implementations in many local services and also for instance in the following 
global service. 

22 See also: https://tools.ietf.org/html/draft-kunze-ark-14 

23 See: https://www.w3.org/TR/cooluris/ 

24 See: http://purl.org 

24 

 
 
 
 
                                                 
PID Architecture for the EOSC 

4.5.1  ORCiDs 

An  ORCiD  is  a  special  case  in  the  PID  architecture,  because  it  is  logically  a  monolithic 
system that does not need different namespaces, the identifiers are local and internal of 
this  monolithic  system  and  are  therefore  intrinsic  identifiers.  Resolution  in  the  sense  of 
virtualisation and redirection to the data is not necessary, since the data is maintained in 
the same monolithic system. Resolution in this case is simply providing the content behind 
the  identifier  in  the  ORCiD  database.  As  a  consequence,  no  global  resolution  and 
namespace administration is necessary and the processes are completely described by the 
relations “queries PID”, “registers/modifies PID” and “resolves PID” between the user and 
the ORCiD system, which is similar to figure 1 with the ORCiD system in the role of the PID 
architecture, but with only a part of its relations. 

25 

 
 
 
 
PID Architecture for the EOSC 

5 

COMPARISON WITH THE DNS SYSTEM 

Another well known, highly scalable and performant resolution system is the DNS System. 
A comparison of the actors, activities and relation of the PID architecture with those of the 
DNS system shows the similarities and differences. For a comparison of the PID and DNS 
resolution systems one can refer back to the introductory picture comparing the importance 
of PIDs for data sources with that of IP for network technology. 

While on the internet hostnames are used to identify a logical device independent of its 
physical  location,  IP  addresses  are  used  to  identify  the  physical  device.  DNS  is  used  to 
translate logical hostnames into physical IP addresses. In a logical sense, it is possible to 
assign  multiple  hostnames  to  a  single  IP  address  and  vice  versa  it  is  possible  to  relate 
multiple IP addresses to a single hostname via different DNS load balancing techniques. 
Within  the  TCP/IP  model,  TCP  or  UDP  is  used  as  the  transport  protocol  to  exchange 
information  between  source  and  destination  devices.  Therefore,  the  role  of  DNS  in  this 
diagram would probably be better depicted on the same level as TCP and UDP (see table 
below). 

When the TCP/IP model is used as an analogy for the PID system, the PID is similar to the 
hostname to logically identify a bitstream independent from the physical location on the 
internet.  The  URL  kernel  information  points  to  the  hostname  and  logical  location  of  the 
physical device and bitstream on the device connected to the internet. The PID model is 
based on the same concept to translate logical PIDs to physical addresses as URLs. While 
within the TCP/IP model this is done via the standardised DNS system, within the PID world 
this is not standardised. Each PID framework has its own mechanism, to resolve the PID 
to  the  physical  bitstream.  In  general,  within  the  PID  world,  HTTP  is  currently  used  as  a 
transport  protocol,  but  often  the  PID  frameworks  are  defined  in  a  way  that  enables 
independence of this specific technology to ensure a long-term persistence. Depending on 
the PID framework it is possible to assign multiple PIDs to a single bitstream of information 
or to have a single PIDs pointing to multiple locations where the bitstream can be retrieved.  

TCP/IP Model   

PID model 

Logical and human readable 
name of a service and/or 
server 

HOSTNAME 

  PID 

Logical persistent reference 
representing a digital object 

Translates logical hostname 
physical IP address  

DNS 

  PID 

RESOLVER 

Translates  logical  reference 
to  physical  location  where 
object is being stored 

Transport protocol 

TCP/UDP 

  TCP/UDP  or 

HTTP 

Transport protocol to access 
digital object 

Address to identify physical 
device 

IP ADDRESS 

  URL DO 

URL 
the 
location  where 
Digital  Object  is  physically 
stored and made accessible  

26 

 
 
 
 
 
 
PID Architecture for the EOSC 

Next to this high-level comparison between the TCP/IP layer model with the PID layered 
model,  the  comparison  can  be  extended  to  other  architectural  aspects,  as  for  example 
namespace governance and technical architecture.  

5.1 

DNS versus PID Namespace and Governance 

In this section a comparison is made between the DNS and PID namespace organisation 
and the organisational structure which governs the namespaces. 

Because the PID landscape is still very much fragmented, the comparison will not provide 
a complete overview of all PID frameworks but will focus on common used PID 
frameworks within the Research domain. 

  Handle - Handle System for registering and resolving persistent identifiers, or handles, 
to  information  resources,  and  for  resolving  "those  handles  into  the  information 
necessary to locate, access, and otherwise make use of the resources" 

  DOI  -  Digital  Object  Identifiers  (DOI)  are  Handles,  standardized  by  the  International 

Organization for Standardization 

  URN:NBN - National Bibliography Numbers is a group of publication identifier systems 

used by national libraries 

  Identifiers.org - Project providing stable and perennial identifiers for data records used 

in the Life Sciences 

  ORCID - Open Researcher and Contributor ID is a non-proprietary alphanumeric code 

to uniquely identify scientific and other academic authors and contributors 

27 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
PID Architecture for the EOSC 

Table 1, below, provides a comparison of the governance of the namespace of DNS and 5 
frequently used PID frameworks. 

Table 1: Comparison between the namespace governance structures of DNS and 5 PID frameworks 

Governance  DNS 

Handle 

DOI 

URN:NBN 

Namespace 
Organisation 

Hierarchical 

Hierarchical 

Hierarchical 

Hierarchi
cal, the 
DOI  
(10.#) 
namespa
ce is a 
sub 
namespa
ce of the 
Handle 
namespa
ce 

Identifie
rs.org 
1 Level 

ORCID 

1 Level, 2 
types of 
ORCIDs: 
for 
Researcher
s and for 
Organisatio
ns 

Top Level 
Namespace 
Governance 

Top Level 
Namespace 
Registries 

Top Level 
Namespace 
Registrars 

Number of 
Registrars 

Identifiers.
org 

ORCID 

URN is 
governed by 
IANA, NBN is 
governed by 
CDNL and 
CENL 

National 
Libraries 

Identifiers.
org 

ORCID 

ICANN 

DONA 

DOI 

Top Level 
Domains are 
maintained 
by 
administrativ
e 
organisation
s (SIDN, 
DENIC, 
EURid, ...) 

Multi Primary 
Administrators 
(CNRI, DOI, ePIC-
GWDG, …) 

DOI 
Registrati
on 
Agencies 
(DataCite
, 
CrossRef, 
...) 

distributed 

Distributed 

Distribut
ed 

Distributed 

Identifiers.
org 

ORCID 

1 

1 

Many, a 
registrar can 
offer domain 
registration 
in multiple 
TLD 

in its level Many, a 
registrar assigns 
prefixes in the MPA 
Prefix Domain to 
which the registrar 
is affiliated with, for 
example, SURFsara 
is member of the 
ePIC organisation, 
GWDG is the MPA 
representative of 
ePIC in the DONA 
Foundation, 
responsible for 
21.##### domain. 

10 
organisat
ions, 
registrars 
assign 
prefixes 
in the 
10.###
## 
domain 

Many, at least 
1 per country, 
in large 
countries with 
multiple 
National 
Libraries, the 
namespace is 
divided in 
sublevels, 1 
per National 
Library 

Namespace 
Domain 
Owners/ 
Managers 

Domain 
name owner 

Prefix owner 

DOI 
Prefix 
owner 

URN:NBN 
prefix owner 

Prefix 
owner 

ORCID ID 
owner: 
either 
Individual 
Researcher 
or 
Organisatio
n 

28 

 
 
 
 
 
PID Architecture for the EOSC 

The comparison in Table 1 is not providing a quality value of the governance structures of 
the  different  PID  frameworks.  From  the  comparison  in  the  namespace  governance 
structures, we can only conclude that the governance structure of the Handle system via 
DONA Foundation shows most similarities with the DNS governance structure via ICANN.  

To make the similarities of the governance structures between the DNS and Handle system 
more visible the two systems are compared in the following diagrams. 

Figure 9: Architectural diagram of the DNS governance structure 

29 

 
 
 
 
 
 
 
 
PID Architecture for the EOSC 

Figure 10: Architectural diagram of the Handle governance structure 

5.2 

DNS versus PID technical architecture 

Next to a comparison of the namespace governance structures, also a comparison can be 
made on the technical architecture. In table 2 a comparison is made in: 

  Namespaces minting architecture, 

  Resolving architecture and  

  Software 

30 

 
 
 
 
 
 
 
 
 
 
 
 
 
PID Architecture for the EOSC 

Table 2: Comparison of the technical architecture between DNS and 5 PID frameworks 

Technical 
Architecture 

DNS 

Handle 

DOI 

URN:NBN 

Identifiers. 
org 

ORCID 

Namespace minting 

Prefix 
namespace 

Decentralised 
at DNS 
Registrar 

Decentralised 
at DONA MPA 

Centralised 
via DOI 
Foundation 

Decentralised 
at National 
Registration 
Agencies 

Centralised 
registered at 
Identifiers.or
g 

Centralised 
registered at 
ORCID.org 

Domain 
namespace 

Decentralised 
at local DNS 
servers, or 
externally via 
DNS hosting 
providers 

Decentralised 
via Local 
Handle 
Service, or 
externally via 
PID hosting 
providers 

Decentralised 
via DOI 
foundation 
members 

Centralised 
registered at 
Identifiers.or
g 

Centralised 
registered at 
ORCID.org 

Decentralised
, URN:NBN 
must be 
registered at 
National 
Resolver and 
are assigned 
by 
repositories 
for Long 
Term 
Preservation 

Resolving 

Capabilities 

forward and 
reverse 

forward 

forward 

forward 

forward 

forward and 
reverse 

Structure 

Hierarchical, 
decentralised 

Hierarchical, 
decentralised 

Hierarchical, 
decentralised 

Decentralised  Central 

Central 

Root server 
organisatio
ns 

Root 
servers 

Namespace 
servers 

Namespace 
resolver 
entry point 

12 

9 

1086 servers 

9 

1 

1 

0 

0 

Many 

Many 

Many 

Many 

1 

1 

1 

1 

1 

1 

https://identi
fiers.org/ 

https://orcid.
org/search/n
ode 

1 
(http://hdl.ha
ndle.net/) 

1 
(https://dx.d
oi.org/) 

Many, 
hierarchical 
via local 
and/or 
organisationa
l 
nameservers 
via root 
name servers 

Many, 
National, 
regional 
and/or local 
resolvers, for 
example, 
https://nbn-
resolving.org
/ for 
Germany and 
Switzerland, 
and 
http://www.p
ersistent-
identifier.nl/ 
for the 
Netherlands 

31 

 
 
 
 
 
 
PID Architecture for the EOSC 

Prefix 
minting 

Proprietary 

Domain 
minting 

User/Client 
interface 

Multiple 
implementati
ons, see 
https://en.wi
kipedia.org/w
iki/Compariso
n_of_DNS_se
rver_software 

Integrated 
within the 
network layer 
of the 
Operating 
System, 
different 
client 
libraries 
implemented 
in different 
programming 
languages 

Software 

Proprietary - 
based Global 
Handle 
Resolver 
(GHR) 

Proprietary - 
integrated 
with 
Handle.net 
LHS software 

Proprietary - 
Global Handle 
Resolver 
(GHR) 

Handle.net, 
see 
https://www.
handle.net/d
ownload_hnr.
html 

Website 
http://hdl.ha
ndle.net/, 
REST API, 
Client 
libraries 
(https://www
.handle.net/cl
ient_downloa
d.html) and 
Community 
support tools 
(https://www
.handle.net/c
ommunity_so
ftware.html) 

Website 
https://dx.do
i.org/, API, 
Python tool 
(https://pypi.
org/project/d
atacite/), 
integrated in 
repository 
packages 
(https://supp
ort.datacite.o
rg/docs/repos
itory-
software-
integrations) 

Proprietary 

Proprietary 

Proprietary 

Proprietary 

Proprietary 

Proprietary 

No central 
website 
and/or 
generic client 
tools or API 
available, 
some 
repository 
packages 
support the 
registration 
of URN:NBN. 

Website 
https://identi
fiers.org/, 
client library 
available, see 
https://githu
b.com/identifi
ers-
org/cloud-
libapi 

Website 
https://orcid.
org/, APIs for 
members and 
non-
members are 
provided, see 
http://memb
ers.orcid.org/
api/about-
orcid-apis. 
ORCID has 
been 
integrated 
with different 
systems to 
support 
automatic 
imports, see 
https://suppo
rt.orcid.org/h
c/en-
us/articles/36
0006973653-
Add-works-
by-direct-
import-from-
other-
systems 

From this comparison we can make the following remarks: 

  The DNS namespace is consolidated into a single namespace governed by a single non-
profit  organisation  (i.e.,  ICANN)  while  within  the  PID  namespace  is  fragmented  into 
different  PID  frameworks  which  are  separately  governed.  At  this  moment  the  PID 
domain  is  lacking  an  overarching  organisation  in  which  the  different  PID  frameworks 
come together. 

  The DNS system has a highly distributed, highly scalable, highly performing resolution 
system which is natively embedded within the network infrastructures of organisations 
and within the operating systems of computers. Within the PID domain there is no de-
facto overarching resolution system but is specifically to a PID framework. The Handle 
and DOI frameworks come from an architectural point of view most close to the DNS 
system, because both frameworks make use of the Handle global resolving network. 

32 

 
 
 
 
 
 
PID Architecture for the EOSC 

  The DNS system supports forward and reverse resolving, while most PID frameworks 
only  support  forward  resolving,  with  the  exception  of  the  ORCID  system  which  also 
supports reverse lookups. 

  Many DNS client tools (e.g., system and command-line utilities, programmable libraries) 
are  available  which  work  generically  with  the  DNS  system  in  a  transparent  way.  The 
client tools to register, mint and to resolve a PID are very specific to the type of PID or 
even specific to one or more service providers within a PID framework. This limits the 
adoption  of  PIDs  because  service  developers  must  learn  and  get  acquainted  with 
different PID frameworks to make use of them.  

33 

 
 
 
 
PID Architecture for the EOSC 

6 

PERFORMANCE AND SCALABILITY 

All ubiquitous basic technologies need to be scalable and performant on their components 
and workflows with high throughput. In order to fulfil the general idea behind Fair Digital 
Objects to provide a common transparent interface to all digital objects all these  Digital 
Objects need to be  referenced by a  PID  and resolved by a global resolution mechanism 
that also comprises the PID Kernel Information.  

The number of expected PID for the objects requires high scalability in the namespace and 
how  this  namespace  is  being  maintained.  Compared  to  the  DNS  system  according  to  a 
website25 in 2018 there were 22 Billion devices connected to the internet, and this should 
grow to 50 Billion in 2030. This number feels huge but is small compared to the number 
of expected DOs. 

In  big  data  centres  the  number  of  objects  often  is  already  now  in  the  magnitude  of 
hundreds of millions of objects. Even if only ten percent are registered as FDOs this means 
that behind one hostname  you can have  Millions, in the future up to  Billions, of  objects 
stored. 

If all objects are addressed via PIDs, then the current methods via resolving PIDS via APIs 
going  to  external  services  is  not  sufficient.  Even  the  highly  distributed  and  efficiency 
optimized Handle resolution system still resolves a PID in the order of milliseconds, which 
is still not sufficient at the scale required. 

Scalability  and  performance  of  PID  systems  therefore  is  an  issue  and  there  is  already 
theoretical work done to make improvements here. In [Golodoniuc e.a.  2017] for instance 
a decentralization by distributed hash tables is proposed. Another approach could achieve 
this  by  clever  caching  mechanisms  at  all  levels.  The  question  is  whether  the  current 
infrastructure  is  capable  of  handling  this.  For  instance,  the  Handle  resolution  system 
provides  such caching internally, but especially at the level of operating systems and of 
the end user and automated services currently such mechanisms are still missing. 

25https://www.statista.com/statistics/802690/worldwide-connected-devices-by-access-technology/  

34 

 
 
 
 
 
 
 
 
                                                 
PID Architecture for the EOSC 

7 

SECURITY, RELIABILITY AND RESILIENCE 

PID service providers, but also the whole namespace administration behind PID services 
need to ensure that no one unauthorised can change the content of the PID database. It 
needs a highly secure IT infrastructure in operation and sufficient measures, for instance 
a  PKI  system,  to  ensure  that  only  authorized  modifications  are  allowed.  Whether  also 
blockchain technologies, mainly used in the context of internal identifiers, may also play a 
significant role here, especially in the context of scalability and performance of the section 
before, has to be explored in the future. 

Which operations inside the PID architecture need which level of authorization is described 
in detail in the diagrams in chapter 2 Components and Activities in a PID Architecture by 
the use of different edge styles according to the description in chapter 10 Symbology of 
Architecture Diagrams.  

On the level of created PIDs linked with kernel attribute records that are stored in the PID 
database and will be returned at PID resolution time, it is possible that users do not want 
a lookup into the records of their PIDs. Therefore, it must be possible to set access rights 
also on the attributes and/or to implement encryption possibilities.  

For the persistence of identifiers reliability, but also resilience are necessary pre-conditions. 
Reliability here needs next to a sufficient maintenance strategy for the services additionally 
a mirroring concept that allows a completely transparent permanent service provisioning. 
Resilience additionally needs a backup strategy in cases of disasters like complete or partial 
loss of PID database contents, but also robust cross organizational contracts in cases of 
institutional failures. 

A special case of endangered reliability is given whenever an object or its representation 
are no longer available, where for instance FAIR Data Maturity Model of RDA [RDA FAIR 
2020] states “Metadata is guaranteed to remain available after data is no longer available” 
as an essential principle. In this case the PID Policy Document ([EOSC PID Policy TF 2020]) 
suggests  in  3.4.1.3  and  5.6  that  the  PID  should  remain  and  its  resolution  to  Kernel 
Information must still be possible. In such cases, it should point to so-called tombstone 
information,  including  basic  metadata  about  the  (now  defunct)  object  properties,  the 
reasons  for  its  deletion  and,  if  available,  pointers  to  any  succeeding  versions.  This 
information must be reliable and sufficiently complete to be useful. This information can 
be provided by a valid landing page generated at the repository side or described in the 
PID database as kernel information, or as a combination of both.  

35 

 
 
 
 
PID Architecture for the EOSC 

8 

GAPS  IN  THE  EXISTING  PID  LANDSCAPE  AND  CHALLENGES  FOR  INVESTIGATION  AND 
DEVELOPMENT 

The  following  gaps in  the  existing  PID  landscape  and  challenges  for  future  investigation 
and development have been identified. 

8.1 

Interoperability between PID systems 

But  the  interoperability  between  existing  PID  frameworks  certainly  is  part  of  the  PID 
architecture  and  can  become  rather  complex.  Even  simple  queries  are  in  general  not 
interoperable and no generic interface is provided for them. A PID architecture also has to 
explain what is needed to provide interoperability between different PID frameworks. 

8.1.1  Generic Global Resolution 

A first step would be to provide a global service that enables the resolution of any kind of 
PID. As already described in the section about the Handle System this system provides a 
distributed global resolution and has shown in a case study to be able to also resolve URNs. 
This  could  be  a  starting  point  for  a  generic  global  resolution  service  within  an  overall 
cooperation between the existing PID systems. 

8.1.2 

Reverse Lookup 

The so-called reverse lookup, the possibility to get a single PID or a set of them for a given 
query string is not existing currently for many PID systems. New approaches and querying 
technologies  like  graph  queries  are  emerging.  But  a  reverse  lookup  may  not  even  be 
wanted by many service providers, because it can cause heavy load on the servers, but 
also  because  of  privacy  issues  concerning  metadata  in  kernel  information  that  should 
remain  undisclosed  as  long  as  the  reference  is  unknown.  Here  a  general  approach  that 
covers all these aspects but also would work for all PID systems could be a useful additional 
service. 

8.1.3  Generic PID Minting 

Also, the minting of PIDs is currently only possible with specialized APIs for the different 
PID systems. Even inside the Handle world the different groups of service providers use 
different  APIs  to  ensure  the  compliance  to  their  different  policies.  A  harmonization  is 
certainly  difficult  because  of  this  combination  of  technical  and  social  aspects  but  for 
usability of the PID systems it would be helpful. 

8.1.4 

Scaling up 

It is expected that the majority of the Digital Objects are addressed via PIDs, while in the 
current time it is the other way around. In the current time of exponential data growth, 
the  PID  infrastructure  must  scale  up  in  minting  and  resolution  capabilities  and 
performance. Collection of metadata associated with a PID needs to be automated close to 
where the data is generated and integrated into data collection and processing workflows 
to ensure FAIR data management. PIDs need to be assigned early and potentially at scale 
(depending on the application). 

To be able to cope with the future required capabilities and performance a highly distributed 
infrastructure is required with new clever approaches on caching at local level to support 
efficient  resolving  of  PID  references.  Also,  if  in  the  future  billions  of  PIDs  should  be 
generated and minted, different approaches are needed on how these PIDs are generated 
and maintained in a highly automated way. With the current number of PIDs this can be 
considered  maybe  not  as  an  immediate  gap,  but  to  be  able  to  support  the  scientific 

36 

 
 
 
 
PID Architecture for the EOSC 

challenges of the future and the exponential data growth the development of these new 
approaches should be start-up. 

8.2 

Hidden Complexity of Metadata 

In the description of the components and activities in a PID Architecture there is still a lot 
of hidden complexity. Several related activities, like for instance schema, vocabulary and 
ontology development, are not described in the diagrams, because they are not considered 
as part  of the PID architecture,  or in case of types and type definitions, as described in 
section 2.3 Types and Profiles in a Global PID Registration and Resolution Framework they 
cover only a small part of it. But metadata belongs to FAIR digital objects and is therefore 
closely related to the PID architecture, especially if the metadata becomes part of the PID 
record. 

8.2.1 

Federation and Governance of Data Type Registries 

A better standardisation in exactly these areas could lead to much more interoperability in 
data  management.  The  type  concept  and  the  data  type  registries  are  a  first  lightweight 
step in this direction, but here still a sufficient governance structure and a federation of 
DTRs is needed. 

8.2.2 

Kernel Information Types and Profiles 

To  extend the use  of PIDs beyond the  current  main use cases of  PIDs, publications and 
data,  into  the  realm  of  new  and  emerging  resource  types  PIDs  often  need  a  different 
metadata model. This is already done in several cases like the metadata set for PIDs for 
instruments  by  an  RDA  working  group,  for  organisations  by  the  “Research  Organization 
Registry (ROR)”-approach or in many metadata models for specimens or probes. In these 
and  similar  cases  the  major  challenge  is  to  keep  the  metadata  model  simple  to  enable 
simple  faceted  search  of  different  attributes  and  fast  discrimination  of  masses  of  digital 
objects in the context of big data. The description of kernel information types by an RDA 
working  group  is  an  approach  to  decide,  how  metadata  should  be  structured  to  fulfil  a 
sufficient  simplicity.  Extensions  and  variations  of  the  RDA  strawman  to  other  use  cases 
need to be defined as types in a data type registry to enable automated services to work 
on top of such digital objects. Also, the set of eligible kernel information types for a specific 
kind of digital objects should be defined in so-called kernel information profiles. 

8.2.3 

PIDs for Services 

With the approach above the metadata for a digital representation of a service would lead 
to services that work on top of that digital representation, but they will not be sufficient to 
invoke the service itself automatically. To enable the use of the service in an automated 
context  the  situation  is  fundamentally  different,  because  additionally  this  needs  basic 
agreements on the serialization of the service. First steps into this direction were made for 
instance in the context of the Digital Objects interface Protocol (DOIP) ([Kahn e.a. 2018]) 
for the Handle system. 

8.2.4 

PIDs and Sensitive data 

The FAIR principles would require PIDs to be used with sensitive data and this would reflect 
onto  the  PIDs  themselves.  This  may  lead  to  situations  where  access  to  parts  of  the 
metadata is restricted.  We would apply the principle of as open as possible and as closed 
as  necessary,  and  fine-grained  access  control  for  creating,  updating  and  accessing  PID 
records (Kernel information) may be needed. 

37 

 
 
 
 
PID Architecture for the EOSC 

8.3 

Priorities between these Challenges 

It  can  be  noticed  that  between  these  challenges  there  are  interdependencies,  there  are 
different  efforts  and  timeframes  needed  to  achieve  them  and  a  different  importance  of 
those  challenges  might  be  seen.  We  therefore  decided  to  set  up  a  query  inside  the  PID 
Architecture Taskforce, later extended to the whole Architecture Working Group of EOSC, 
about an opinion on a prioritization, especially emphasizing the timeline respecting possible 
dependencies to other topics, in order to suggest an agenda for the future work to be done 
with respect to an improvement of the current PID landscape.  

The outcome of this poll showed the highest priority for “Federation and Governance of 
Data  Type  Registries”,  followed  by  “Kernel  Information  Types  and  Profiles”, 
“Generic  Global  Resolution”  and  “Scaling  up”  with  a  similarly  ranked  priority.  Lower 
priorities were given to “PIDs for Services”, “Reverse Lookup”, “PIDs and Sensitive 
data” and finally “Generic PID Minting” with the lowest priority in this order. 

38 

 
 
 
 
PID Architecture for the EOSC 

9 

THE USERS/COMMUNITIES’ PERSPECTIVE 

The users and communities’ perspectives will be better visible after the open consultation 
phase  of  this  document.  We  collect  users  and  communities’  perspectives  on  the  here 
described PID architecture in a separate folder26, where users or communities can share 
what  demands  they  have  with  respect  to  a  PID  architecture.  These  perspectives  will  be 
included here in a later version of the document. 

26 https://drive.google.com/drive/folders/1W5oxqh0Y6poTzizT2ldBW7HEhfqjsL74  

39 

 
 
 
 
                                                 
PID Architecture for the EOSC 

10  SYMBOLOGY OF ARCHITECTURE DIAGRAMS 

The UML style diagrams that describe the PID architecture from different perspectives and 
with different levels of abstraction have different codings for the nodes and edges used. 
The coding of the edge style distinguishes between the kind of access control needed for 
the  respective  relations  in  the  diagram,  whereas  the  coding  of  the  nodes  distinguishes 
between  organisational  and  technical  components  and  between  atomic  and  complex 
components. 

10.1  Edges 

  solid lines: activities that are executed by the PID consumer, either the User, or the 

Repository or both. 

  dashed  lines:  activities  that  are  executed  by  components  of  the  PID  architecture, 

targeting the PID consumer or completely internal. 

  edges with plain arrows: no access control (open access) 

  edges starting with filled diamonds: contract-based access control. 

  edges with arrows starting with open diamonds: credential-based access control. 

In general credential-based authorization is based on a contract. 

10.2  Nodes 

  Boxes with red edges: Components of the PID architecture that consist of different 
other  components  that  are  relevant  for  the  architecture.  In  most  cases  these 
components are decomposed in other diagrams.  

  Boxes with black edges: Components that are atomic organisational units in the view 
of this document, but which on the other hand can occur many times, like for instance 
local PID providers. 

  Pie diagrams: components that are technical implementations. 

40 

 
 
 
 
 
PID Architecture for the EOSC 

11  DEFINITIONS, GLOSSARY 

The following terms related to the PID Architecture are an extension of the terms provided 
by the PID Policy Document v2 [EOSC PID Policy TF 2020]. 

Attribute 

A value that describes a feature of an object or its representation, as part of PID 
Kernel Information or other metadata. 

Digital Object 

A Digital Object has a bit sequence that can be stored in multiple repositories and is 
associated with a Persistent Identifier (PID) and metadata. 

Digital Object 
Identifier (DOI) 

A digital object identifier (DOI) is a persistent identifier based on Handle used to 
identify objects uniquely, standardized by the International Organization for 
Standardization (ISO). 

Digital Entity 

A digital Entity denotes any sort of bit sequence that is being stored or transmitted 
without being registered to enable sharing. 

European Open 
Science Cloud 
(EOSC) 

An integrated infrastructure to create a web of FAIR data. The development of EOSC 
is a large and ongoing multi-stakeholder initiative. 

FAIR Digital 
Object 

A model proposed by the Turning FAIR into Reality report, denoting what elements are 
needed for a Digital Object to be FAIR and thus machine actionable. For more details 
see section 1.6 PIDs, Digital Objects and FAIR Digital Objects. 

FAIR Principles 

FAIR stands for Findable, Accessible, Interoperable and Reusable. It refers to the FAIR 
Data Principles developed by the FORCE 11 community, that recommend data should 
be shared according to these four concepts. 

Granularity 

Handle 

The varying levels of hierarchy or constituent parts that may form data or other 
research outputs. For example, the differing levels of granularity of a research 
publication, going from a whole Journal issue, to its constituent articles, to the 
article’s constituent sections or figures, the levels in a complex scientific collection or 
the level of detail in a large scientific database. 

A Handle is a globally resolvable, unique and persistent PID which is defined by RFCs 
3650, 3651 and 3652 of the Internet Engineering Task Force (IETF). They are used by 
DOI, ePIC and many other service providers. The Handle System is governed by the 
independent Swiss DONA Foundation. 

Kernel 
Information 

A PID needs to be resolved to a structured record consisting of well-defined attributes 
to allow machine actions. This is the concept of PID Kernel Information as described in 
the matching RDA Recommendation [Weigel e.a. 2018]. 

Landing Page 

A human-readable page, displayed in a browser, that provides human users with 
information on how to access and/or interpret the digital object or its representation 
that is identified by a PID. 

Machine 
Actionable 

Machine Actionable means that a formal statement is syntactically and semantically 
specified enabling computing systems to carry out automatic processing. 

Metadata 

With metadata we mean all kinds of assertions about properties of the bit sequence of 
a digital object such as descriptive, deep scientific, contextual, provenance, access 
permissions, transactions etc. This kind of metadata is not stored in the PID record as 
kernel attributes, however the PID record in general should point to the metadata. 

41 

 
 
 
 
PID Architecture for the EOSC 

Namespace 

A namespace ensures that all the identifiers within a given level have unique names 
so that they can be easily identified. 

Persistent Identifier 
- PID 

A PID consists of a PID string and a PID resolution system that has to persist on a 
technical and organisational level and that resolves the PID string to a structured 
record consisting of a reference and of well-defined other attributes, called Kernel 
information types, to allow machine actions. More details on the nature of PIDs can be 
found in the introductory chapter of this document and in the EOSC PID Policy 
document ([EOSC PID Policy TF 2020]). 

PID Ecosystem 

The set of PID Components and Services that may be federated or interoperable to 
support EOSC and research that is FAIR in an effective and a sustainable way. 

PID Framework 

Describes here a governance structure and technical infrastructure that allows 
organizations to implement PID Services for their needs within agreed policies. 

PID Profile 

The PID profile describes the set of kernel attributes that are being selected by a 
repository to describe the DO. The profile is dependent on the type of object and the 
needs of the community. Only openly declared attributes with widely agreed semantic 
types will provide machine actionability. 

PID Service 

The technically implemented service to mint and resolve PIDs 

Prefix 

Semantics 

Suffix 

Types 

A PID syntax component denoting an authority or division of a namespace. A prefix 
needs to be globally unique associated with particular local authorities which are free 
in how they generate locally unique IDs. 

The meaning or interpretation of meaning attached to a given text string. It is 
recommended to not include semantics in an identifier string where meaning may 
change over time or may not be understood across linguistic and cultural divides. 

A “suffix” is the part of a unique and persistent identifier that is created by a local 
authority which also specifies the syntax rules for the suffix. 

Attributes of Kernel Information as parts of the structured record given by PID 
resolution. 

In [Hellström e.a. 2018] for instance one can find additionally a comprehensive glossary 
of acronyms used in the context of PID systems.  

42 

 
 
 
 
 
 
 
 
 
 
 
 
 
PID Architecture for the EOSC 

11.1  Categories and Criteria of PID systems 

In the publications mentioned in the introduction section 1.2 Overview and Previous work 
the different aspects of a PID architecture are given with a short description that is listed 
in the following and can be seen as an extension of the glossary above for the terminology 
used in this document. As it is based on criteria to distinguish the properties of different 
PID systems it has a focus on the expectations of users on PID systems and the activities 
how they interact with them.  

Category and Criteria 

Description 

Infrastructure and Security 

resolution 

the necessary redirection needs to be resolved by the PID system 

global resolution 

resolvability in a global context 

location independence of 
resolution 

the resolution must not be dependent on the location of the query 

secure permissions for write 
access 

the PID system only permits authorised data sources to register and 
update PIDs 

reliability of resolution 

a failsafe solution for his resolving service 

scalability of the resolution 
service 

the resolver service can be expanded as required. 

scalability of the PID service 

creation and modification of PIDs can be expanded as required 

independence of third-party 
technology 

no dependency upon specific third parties for the use and replacement of 
system parts 

export of PID records into open 
standards 

data necessary for the core PID services can be exported at any time in 
openly documented and standardised formats from the system 

performance 

high-performance behavior must be ensured primarily by a scalable 
architecture, a fast network connection and sufficient hardware 

metadata support 

additional metadata associated directly with the PID 

fragment support 

to hand over fragments or part identifier strings to target service 

collection support 

PIDs as references to collections of data sets (collections, digital objects, 
…) 

dynamic data support 

PIDs as references to dynamic data (time series, database queries, …) 

flexibility on services 

new functionalities can be added without jeopardizing the conformity to 
the standard infrastructure 

support of several target copies 

it can be transferred from a PID to several copies of the target 
simultaneously (1:n relationship) 

secure permissions for write 
access for parts 

the PID system only permits authorised data sources to modify parts of 
PIDs (necessary for multiple copies) 

43 

 
 
 
 
PID Architecture for the EOSC 

scalability of the namespace 

the encoding scheme of the namespace permits any number of name 
variants. 

Object management 

uniqueness of PID domain 
(prefix) 

unique indication of the PID system / institution 

uniqueness of PID 

no multiple issuing of a PID to non-identical objects 

flexibility in metadata support 

flexibility in schema definition for metadata associated directly with the 
PID 

validity of the associated 
information 

periodical checks of the validity of the associated information (types) 

neutrality against resolution 
targets 

on no level does the PID system favour linking to objects from certain 
data sources 

conformity to standards 

the PID system and infrastructure is based on international standards 

statistics 

relevant statistics about the use of my Persistent Identifiers are 
available, e.g., how often they are resolved 

Organisational Framework 

trustworthiness of stakeholders 

stakeholders are key players in the field of application 

long term commitment of 
stakeholders 

to maintaining the PID system including resolution for a long time period 

exit strategy for stakeholders 

a strategy exists to ensure ongoing resolution once resolver operation 
has been discontinued. 

QoS and SLAs 

the stakeholders commit to SLAs and QoS 

transparency about rules for 
issuing and managing PIDs 

requirements and the core elements of the obligations entered into are 
publicly known. 

domain specific policies 

policies for PID deletion, for metadata associated to the PID or others 
can be made domain and/or community specific 

sustainable business model 

financing of the PID service operation is secured on a long term basis 

independent, affordable, 
transparent and stable prices 

the PID service operation does not depend on an unaffordable business 
model of a company and has to be transparent and stable 

openness of software and 
technology 

independence is only given when using software that is open and when 
all contracts that might be concluded contain appropriate clauses 

user support 

support when working with PIDs or implementation of PID service 

44 

 
 
 
 
 
PID Architecture for the EOSC 

12  REFERENCES 

[Almas  e.a.  2015]  Almas,  Bridget,  Bicarregui,  Juan,  Blatecky,  Alan,  Hill,  Sean,  Lannom, 
Larry,  Pennington,  Rob,  Stotzka,  Rainer,  Treloar,  Andrew,  Wilkinson,  Ross,  Wittenburg, 
Peter, Yunqiang, Zhu, 2015, Data Management Trends, Principles and Components – What 
Needs to be Done Next? HDL: 11304/77656f7c-79bb-4e91-a163-29661738680d 

[Berg-Cross e.a. 2015] Berg-Cross, G, Ritz, R, Wittenburg, P 2015 Core Term Definitions, 
in  Data  Foundation  and  Terminology  Work  Group  Products.  DOI:  10.15497/06825049-
8CA4-40BD-BCAFDE9F0EA2FADF 

[Bulatovic e.a. 2008] Bulatovic, N., Dreyer, M., Romary, L., Broeder, D., Kemps-Snijders, 
M.,  Wittenburg,  P.,  Lautenschlager,  M.,  Schwardmann,  U.,  BAR  Antrag  zur  Einführung 
Persistenter und Eindeutiger Identifikatoren in der MPG, 2008 

[Bütikofer 2009] Bütikofer, N., 2009. Catalogue of criteria for assessing the trustworthiness 
of PI systems, nestor-studies 13, urn:nbn:de:0008-20080710227 

[Duerr  e.a.  2011]  Duerr,  R.E.,  Downs,  R.R.,  Tilmes,  C.  et  al.,  2011.  On  the  utility  of 
identification schemes for digital earth science data: an assessment and recommendations. 
Earth Sci Inform 4, 139 DOI: 10.1007/s12145-011-0083-6 

[DiCosmo e.a. 2019] Di Cosmo, R., Gruenpeter, M., & Zacchiroli, S. (2020).  Referencing 
Source Code Artifacts : A Separate Concern in Software Citation. Computing in Science & 
Engineering, DOI: 10.1109/MCSE.2019.2963148  

[DiCosmo e.a. 2020] Di Cosmo, R., 2020, Scholarly Infrastructures for Research Software 
for the European Open Science Cloud (EOSC), https://op.europa.eu/en/publication-detail/-
/publication/145fd0f3-3907-11eb-b27b-01aa75ed71a1 

[RDA FAIR 2020] RDA, 2020, FAIR Data Maturity Model, DOI: 10.15497/rda00050 

[Golodoniuc  e.a.    2017]  Golodoniuc,  P.,  Car,  N.J.  and  Klump,  J.,  2017.  Distributed 
Persistent Identifiers System Design. Data Science Journal, 16, p.34. DOI: 10.5334/dsj-
2017-034 

[Hellström  e.a.  2018]  Hellström,  M.,  Johnsson,  M.,  Toussaint,  F.,  Kindermann,  S.,  Lear, 
D., Huber, R., Stocker, M., Häggström, I., Enell, C.-F. 2018, D6.2: A report on negotiations 
with  publishers,  providers  of  existing  data  citation  systems  and  other  scientific 
organisations on implementing a global data citation system, ENVRIplus WP6 deliverable 
report,  especially  chapter  4.4.2  Questionnaire/survey,  http://www.envriplus.eu/wp-
content/uploads/2015/08/D6.2-A-report-on-negotiations-with-publishers-providers-of-
existing-data-citation-systems-and-other-scientific-organisations-on-implementing-a-
global-data-citation-system.pdf  

[EOSC  PID  Policy  TF  2020]  Hellström,  Maggie,  Heughebaert,  André,  Kotarski,  Rachael, 
Manghi, Paolo, Matthews, Brian, Ritz, Raphael, … Wittenburg, Peter. (2020, May 1). Second 
draft  on  Persistent  Identifier  (PID)  policy  for  the  European  Open  Science  Cloud  (EOSC) 
(Version 2.0). Zenodo, DOI: 10.2777/926037 

[L'Hours  2019]  Hervé  L'Hours;  Ilona  von  Stein;  Frans  Huigen;  Anusuriya  Devaraju; 
Mustapha  Mokrane;  Joy  Davidson;  Jerry  de  Vries;  Patricia  Herterich;  Linas  Cepinskas; 
Robert Huber, 2019, M4.2 Draft Maturity Model Based on Extensions and-or Additions to 
CoreTrustSeal Requirements, Zenodo, DOI: 10.5281/zenodo.4003598  

45 

 
 
 
 
PID Architecture for the EOSC 

[Kahn,  Wilensky  2006]  Kahn,  R,  Wilensky,  R  2006.  A  framework  for  distributed  digital 
object services. Int. J. on Digital Libraries. 6. 115-123. DOI: 10.1007/s00799-005-0128-
x. 

[Kahn e.a. 2018] Kahn, R, Blanchi, C, Lannom, L, Lyons, P, Manepalli, G, Tupelo-Schneck, 
R,  Sun,  S  2018,  Digital  Objects 
interface  Protocol  Specification  Version  2,  
https://www.dona.net/sites/default/files/2018-11/DOIPv2Spec_1.pdf  

[Klump, Huber 2017] Klump, J. and Huber, R., 2017. 20 Years of Persistent Identifiers  – 
Which Systems are Here to Stay?. Data Science Journal, 16, p.9. DOI: 10.5334/dsj-2017-
009 

[Merkle 2000] Merkle, R.C., 2000, A Digital Signature Based on a Conventional Encryption 
Function, in LNCS, volume 293, DOI: 10.1007/3-540-48184-2_32 

[Philipsson  2019]  Philipsson,  J.,  "Identifying  PIDs  playing  FAIR",  Data  Science  2  (2019) 
229-244; DOI: 10.3233/DS-190024 

[PIDwijzer 
https://www.pidwijzer.nl/en/pid_results/new 

PIDwijzer 

2017] 

2017, 

Persistent 

Identifier 

Guide 

[Schroeder 2009] Schroeder, K., 2009. Persistent Identifier (PI) - ein Überblick“ (Version 
2.0), urn:nbn:de:0008-200908114898 

[Schwardmann  2020]  Schwardmann,  Digital  Objects  –  FAIR  Digital  Objects:  Which 
Services Are Required? Data Science Journal, DOI: 10.5334/dsj-2020-015 

[Weigel e.a. 2018] Weigel T, Plale B, Parsons M et al (2018). RDA Recommendation on PID 
Kernel Information (Version 1). Research Data Alliance. DOI: 10.15497/RDA00031 

[Wittenburg e.a. 2014] Wittenburg, P., Berg-Cross, G. Eds., 2014, RDA Data Foundation 
and Terminology DFT1: Overview  

46 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Getting in touch with the EU 

IN PERSON 
All over the European Union there are hundreds of Europe Direct information centres. 
You can find the address of the centre nearest you at: https://europa.eu/european-union/contact_en 

ON THE PHONE OR BY EMAIL 
Europe Direct is a service that answers your questions about the European Union. 
You can contact this service: 
– by freephone: 00 800 6 7 8 9 10 11 (certain operators may charge for these calls), 
– at the following standard number: +32 22999696, or 
– by email via: https://europa.eu/european-union/contact_en 

Finding information about the EU 

ONLINE 
Information about the European Union in all the official languages of the EU is available on the Europa 
website at: https://europa.eu/european-union/index_en 

EU PUBLICATIONS 
You can download or order free and priced EU publications from:  
https://op.europa.eu/en/publications. Multiple copies of free publications may be obtained by 
contacting Europe Direct or your local information centre (see https://europa.eu/european-
union/contact_en) 

EU LAW AND RELATED DOCUMENTS 
For access to legal information from the EU, including all EU law since 1952 in all the official language 
versions, go to EUR-Lex at: http://eur-lex.europa.eu 

OPEN DATA FROM THE EU 
The EU Open Data Portal (http://data.europa.eu/euodp/en) provides access to datasets from the EU. 
Data can be downloaded and reused for free, for both commercial and non-commercial purposes. 

 
 
 
 
 
 
 
 
 
The Technical Architecture document on Persistent Identifiers 
(PIDs) describes a high-level view on components and 
stakeholders relevant inside an architecture for persistent 
identification based on namespaces. It is generic in the sense that 
the components are described independently of a concrete 
technical implementation. 

The PID Technical Architecture document will additionally identify 
opportunities for how interoperability between PID services can be 
achieved within the framework of the European Open Science 
Cloud (EOSC). Drawing from the EOSC guidelines, it identifies 
stakeholders at different levels of PID namespaces, their roles and 
their ability to enforce policies.  

The PID Technical Architecture document is mainly targeted at PID 
and generic service providers and practitioners as guidelines on 
implementation of PIDs and related services compliant with PID 
Policy within the EOSC. But it may also be of interest for 
technically interested PID practitioners and for policy makers 
acting on an organisational level. 

Research and Innovation policy