WG PID Kernel Information RDA P11 Berlin – March 2018 Co-chairs: Beth Plale, Tobias Weigel www.rd-alliance.org - @resdatall CC BY-SA 4.0

https://rd-alliance.org/ - https://twitter.com/resdatall Meeting agenda Introduction, agenda bashing Use cases and adoption perspectives RPID project ENES adoption DOI perspective ... Q&A on all draft recommendation contents Discussion and decision on next steps https://rd-alliance.org/ - https://twitter.com/resdatall

https://rd-alliance.org/ - https://twitter.com/resdatall Current status Draft RDA Recommendation including PID Kernel Information guiding principles Explanatory examples Core Kernel Information profile Exemplary high-level architecture Use cases and adoption (tbd) Working Group running officially from P9-P11. What do we do next? https://rd-alliance.org/ - https://twitter.com/resdatall

https://rd-alliance.org/ - https://twitter.com/resdatall Motivation The current global middleware infrastructure exposes shortcomings for data identification, discovery and use No good approach for automated services dealing with millions of objects in short timeframes Needed: A tiny amount of metadata injected into PID records This is what the PID Kernel Information group is pursuing. https://rd-alliance.org/ - https://twitter.com/resdatall

What is PID Kernel Information? Lots of information can be put in a PID record – but what is a wise choice? This group looks for the most essential information – the kernel information Kernel information is organized through profiles We identified core guiding principles which are valid independent from a particular technology https://rd-alliance.org/ - https://twitter.com/resdatall

PID Kernel Information Guiding Principles PID Kernel Information is a non-authoritative source for arbitrary metadata.  That is, if PID Kernel Information contains attributes that are a duplicate of metadata maintained elsewhere, the authoritative source for the attribute is outside the PID Kernel Information. PID Kernel Information is stored directly at the local resolving service and not referenced. Primary purpose of a PID KI record is to serve machine actionable services. A PID KI record can be changed only by the data object owner or owner delegate (e.g., PID record manager). https://rd-alliance.org/ - https://twitter.com/resdatall

PID Kernel Information Guiding Principles PID Kernel Information record values should change infrequently and only by an appropriate authority, avoiding human interaction on updates where possible.      Attributes (items) in the profile are expressed as key-value pairs where the values are simple (indivisible) (first normal form).   A profile definer should strive to follow the second and third normal form when defining a profile. Doing so may reduce migration issues if records need to be migrated to a revised profile in the future. Every attribute in a profile depends only on the identified object and nothing else. Every attribute also depends on the object directly and not through another attribute. To resolve possible violations, attributes may be moved to separate records or DTR entries. https://rd-alliance.org/ - https://twitter.com/resdatall

PID KI Guiding Principles PID Kernel Information is a non-authoritative source for arbitrary metadata.  That is, if PID Kernel Information contains attributes that are a duplicate of metadata maintained elsewhere, the authoritative source for the attribute is outside the PID Kernel Information. PID Kernel Information is stored directly at the local resolving service and not referenced. Primary purpose of a PID KI record is to serve machine actionable services. A PID KI record can be changed only by the data object owner or owner delegate (e.g., PID record manager). PID Kernel Information record values should change infrequently and only by an appropriate authority, avoiding human interaction on updates where possible.      Attributes (items) in the profile are expressed as key-value pairs where the values are simple (indivisible) (first normal form).   A profile definer should strive to follow the second and third normal form when defining a profile. Doing so may reduce migration issues if records need to be migrated to a revised profile in the future. Every attribute in a profile depends only on the identified object and nothing else. Every attribute also depends on the object directly and not through another attribute. To resolve possible violations, attributes may be moved to separate records or DTR entries. https://rd-alliance.org/ - https://twitter.com/resdatall

Core Kernel Information profile see table in Google doc? https://rd-alliance.org/ - https://twitter.com/resdatall

Exemplary high-level architecture (Handle-based) https://rd-alliance.org/ - https://twitter.com/resdatall