PID Information Types (PIT) WG Recommendations

19
Jan
2015

PID Information Types (PIT) WG Recommendations

By Tobias Weigel


PID Information Types WG
Group co-chair: Timothy DiLauro, Tobias Weigel

Authors: Tobias Weigel, Timothy DiLauro, Thomas Zastrow

Contributors: The PID Information Types WG members

Recommendation Title: Persistent Identifier Type Registry

Impact: Defines standard core PID information types to enable simplified verification of data identity and integrity

Recommendation package DOI: doi.org/10.15497/FDAA09D5-5ED0-403D-B97A-2675E1EBE786

Citation: Tobias Weigel; Timothy DiLauro; Thomas Zastrow (2015): PID Information Types WG final deliverable. DOI:10.15497/FDAA09D5-5ED0-403D-B97A-2675E1EBE786

 

The working group on Persistent Identifier Information Types of the Research Data Alliance concerned itself with the essential types of information associated with persistent identifiers. The working group developed a conceptual model for structuring typed information, an application programming interface for access to typed information and a demonstrator implementing the interface. The final deliverable consists of a summarizing report, the interface specification and a set of exemplary types.

 

Reference: https://rd-alliance.org/groups/pid-information-types-wg.html

 

Rights: Creative Commons CC0 1.0 Public Domain Waiver (CC0)


Please download the full PID Information Types (PIT) WG Recommendations package below, either as a complete zip file PIT Outcomes or as individual sections. 

RDA is running a community review on the recommendations and highly values your input on this first set of recommendations. 

Please use the comment function below for questions and suggestions. Please note that you need to login in order to comment. 

Output Status: 
RDA Endorsed Recommendations
Group content visibility: 
Use group defaults
Primary WG Focus / Output focus: 
Domain Agnostic: 
Domain Agnostic
  • Keith Jeffery's picture

    Author: Keith Jeffery

    Date: 29 Jan, 2015

    I appreciate how much work has gone into this and the effort to produce an implementation.  However I do have some comments:

    Comment1

    This proposal for a recommendation mixes completely the concepts of PID types (i.e. different kinds of persistent identifiers) and attribute type values which may (or may not) be associated with a PID.  In the RDA community at large it is my belief that people equate PID with some kind of DO ID (e.g. DOI, URI, UUID). 

    Comment2

    The proposal discusses a PID Record.  Surely many records can contain a PID attribute either as unique ID (primary key) or reference to one or more other object(s) (foreign key(s)).  The text indicates there is confusion with metadata and admits there are many existing metadata catalogs and that PID records are not capable of replacing them.  In my experience most scientific metadata schemes include the information that might be found in the proposed PID record idea.

    Comment3

    Section 5.  The table is confusing.  The column heading ‘range’ describes what are usually considered types (or representations / encodings).  Range usually means the set of possible values ( maybe between lower and higher limits).  The use of the value ‘identifier’ is presumably shorthand for a representation (undeclared so non-validated) of a value of this attribute which is mandatory and unique.   The column headed ‘Name’ describes what are usually called attributes or properties.  Although the text states they are non-normative the concept of ‘parent’, ‘child’, ‘predecessor’ and ‘successor’ limit greatly the conceptual data model being represented (basically precluding a fully connected graph especially with cyclic properties).

    Comment 4

    Section 6.1  This describes the well-known referential integrity and functional integrity problem and the current proposal does not handle this difficulty.  This is handled appropriately by some metadata systems (but not by implementations of DC, DCAT, CKAN, eGMS and many more although RDF variants may be able to cope with it give a multitude of RDF statements). However, referential and functional integrity should be guaranteed since it is important in the community of researchers that RDA aims to support.

     

  • Bridget Almas's picture

    Author: Bridget Almas

    Date: 06 Mar, 2015

    While I agree that one view of a PID is simply as an opaque identifier, I think this concept of PID "types" is immensely practical and useful, and can correspond to the way some PID systems are being used in the real world.  For example, at the Perseus Digital Library we have been using a proposed standard coming out of the field of Digital Classics,  for identifying data objects by CITE URN, associating these URNs with a standard set of properties, and accessing these properties by their URNs via a predefined API protocol.  The way we are using this standard seems in many ways analgous to the functionality described by the combination of the PID Types recommendation and the Data Types Registry. The key needs that I see possibly being met by the combination of these two RDA deliverables are:

    1) a standard for associating a persistent identifier with a set of pre-defined properties

    2) the ability to template and name these sets of different pre-defined properties

    3) the ability to check the properties for a specific PID assignment for conformance with such a template

    4) the ability to explicitly aggregate sets of objects with like properties *[but see question below about profiles]

    5) A standard API for CRUD, list and search operations on the representations of the above

    6) the ability to avoid naming collisions (across institutions, domains, etc) on all of the above

    But I have some questions specifically around the concept of "profiles":

    1) The explanation of profiles in the recommendation is not very comprehensive and would really benefit from some concrete examples of how they would be applied.

    2) Is my assumption in #4 above that these could be used to explicitly aggregate (and name) sets of objects associated with a type and conformance rules for that type?

    3) Assuming that the the answer to the previous question is yes, would there be a way to explicitly identify a specific ordering of PID types in a profile?

     

     

  • Sara john's picture

    Author: Sara john

    Date: 28 Feb, 2017

    I'll download some of them but do you think that they meet the required purpose
    I always find those who talk about such things, and nothing but mere promotions fake
    I'll try .. thank you

    برنامج حسابات | برنامج حسابات ومخازن

submit a comment