PID Kernel Information WG: P10 Montréal session

The PID Kernel Information WG held a session at the RDA Plenary 10 in Montréal. The session agenda included the following presentations, which are attached for further reference to this page:

  1. Introduction (Tobias Weigel, DKRZ)
  2. RPID project: Towards FAIR Open Science with PID Kernel Information (Yu Luo, IU)
  3. Perseids PID Kernel (Bridget Almas, Perseids/Tufts)
  4. PITSS: PID Kernel Information and the Social Sciences (René van Horik / Vyacheslav Tykhonov, DANS)
  5. A Generic Approach for PID Kernel Information Profiles (Ulrich Schwardmann, GWDG)

The presentations were followed by a discussion. The following are the raw notes from all the presentations and discussions:

Yu's presentation:

  • Guideline for what to include in kernel: how far can KI aid in implementing FAIR?
  • Local Handle System cannot be the authoritative source of metadata - should just be a cache of information stored elsewhere

René's presentation:

  • Terminology issues: what do we call the elements of a Kernel? Property identifiers, or call it something else?
    • Better definitions would be good! Could be an outcome of the KI WG.
  • LicenceFlag: has been suggested in the past as well, but shouldn't this rather be an authorization question? Or an accessibility question?
  • Mark: Question whether it is relevant in social sciences is misleading. Because if we think at the Internet scale, the a priori unforeseen usage is not restricted to the social sciences - other domains will make use of the data no matter where it comes from.
    • This also means that the use cases we will be looking at will not be just domain use cases doing something at domain level, but they should be driven by these ‘management at Internet speed’ questions. This is different from generic RDA use case collection, so we have to focus on specific KI use cases.
  • Suggestion: We should come up with a list of the questions that we actually want to answer with KI to better structure the discussion. This is more than filtering, and even filtering can mean many things, so we have to become more concrete.

Ulrich's presentation:

  • Larry: We want the information to be stable (Ulrich’s point (B)), but we also see the KI as not the authoritative source - just a reflection of information stored elsewhere (also see Yu’s presentation)
    • This is a contradiction and a conflict in understanding. Both views are valid on their own, but how can we satisfy both? This remains an unresolved conflict.
    • So: (B) could be reformulated so that it is clear you do either caching or use Handle record as stable, authoritative source. Then it becomes an explicit choice/decision.
  • Ulrich’s suggested approach leads us to avoid semantics at the first stage in the sifting/filtering/decision-making workflow - clients then deal with it at a later stage.
  • Can we do this syntactic framing but also put a semantic framing around it?
  • Instead of ‘optional entries’, let’s phrase this as ‘mandatory if applicable’. Optional entries in a KI profile seem beside the point, mandatory if applicable is more precise.
  • Mark: Syntax focus is good, but it still does not help us with deciding which is in a profile and which is not.

General discussion:

  • There seem to be more implicit assumptions that we have come up through the various discussions in the telecons and at the Plenaries, where we have gained some shared understanding. But this is implicit - we should make it explicit for P11, phrase it out.
    • Part of that are the questions we actually want to answer with KI. This is part of the use cases discussions.
  • We also need a better description of the high-level use cases.
    • Bridget: This can also enable improved internal management of our data (within your own project/domain) - so it is not just for the re-use beyond domain boundaries.
    • The driving element is the Internet-speed decision making. So this is not just some generic ‘RDA use case collection’.
  • Using Ulrich’s principles, what could we do with regards to FAIR principles?
    • E.g., we could do a certain level of findable, …
  • High level use cases: around first level of FAIR, relationships, workflows….
    • Mark will take a first crack for the next telecon.