[Tobias Weigel]

Kernel Information VC Nov 20 – minutes

 

Next call:

Dec 18, 14:00 UTC.

Current status:

• Assembled new working document on guiding principles for Kernel Information. Currently, this contains an introduction stating the main intentions of KI, particularly that it is designed to be consumed and used by machines, and that KI is an essential ingredient to establishing a middleware infrastructure, followed by 6 principles that frame the design and possible content of Kernel Information such that applications relying on said middleware can work efficiently and no scalability issues arise.

• The original strawman profile from earlier this year still contains a lot of unaddressed comments. Its two parts, the properties table and the architecture deliberations, could now become separated. Parts of the architecture are covered by the new guiding principles doc.

 

Discussion notes:

• We need some description (framework?) of object states / object life cycle (also see Tobias’ mail from Oct 25). This could be based on previous work on trust (concrete project name?). This should cover the following points:

  • Object states should include preservation stage (no changes allowed) and ‘tombstone stage’. Also, notion of a ‘control zone’ somewhere in the middle, where changes to an object become restricted to a smaller user group

  • Mutability flag. It may be sufficient for this to be a boolean.

  • Some other flags/KI entries may be mandatory or have mandatory/disallowed values in some stages. For example, a deletionDate should be mandatory for a tombstone stage. There may be other examples.

  • This could be fully described in a state machine.

  • There is also a relation of FAIR to this, as FAIR implies some progress from finding to re-use.

• What actors/stakeholders do we want to describe? Principles mention owner and delegate owner. Are there more? E.g., ‘publisher’ is a typical role from use cases, and we should define it more precisely related to our principles/framework.

• Impact/Meaning of FAIR principles when looking at the guiding principles? Does FAIR require or imply additional principles? Is everything covered by our guiding principles FAIR?

• Collection representation: This is not sufficiently clear from strawman. ‘hadMember’ seems not the best idea, but what else can we recommend? Collection API (or: services implementing it) should have a role, but possibly not become mandatory for everyone dealing with KI?

• Possible recommendation on KI (supposed to delivered around P11!) could now take shape, with 4+x parts, which we are currently assembling:

  • Guiding principles

  • Architecture and other implementation concerns

  • Strawman

  • Community examples, further profiles

Discussion