PID Information Types (PIT) WG Recommendations

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.

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?

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

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