[Tobias Weigel]

Call on Nov 19, 2013, 15:00 GMT
Attendees: Tobias, Tim, Tom, Matthias, Larry, Ulrich, Maurizio, John Henry Scott

Agenda/Notes:

1) Brief RDA Plenary session review and what has happened since then

• some minor corrections and extensions from the 2nd plenary have been transferred to the use case docs on the website
• The discussion on the definition what a PID is and the role of repositories is valuable, but too much for this group right now. Also the idea of persistence of identifiers is perhaps misleading as it may seem to exclude some pathways and is in the end a question of policy. The pragmatic view here is that we are talking about identifiers that are globally resolvable, associated with information, and have actions enabled on them.

2) Conceptual architecture regarding properties, types and profiles and connection to services

• we’ve briefly reviewed this conceptual framework and agreed to follow it with view on defining our types and going on with implementations and actions to provide
• Tim presented a diagram further illustrating the layers and the role of service interactions
  • the services should not be specific to a single (local) provider but be cross-cutting

I also tried to put down examples mentioned in the conversation for possible actions/methods, but unfortunately didn’t get that far:

• show me all the actions I can do with this identifier (Matthias)
• what types do you support? (not just in your entire repository, but on THIS record in particular) – may be the same as Matthias’ one
• … surely to be extended!

Matthias: Interaction with the API and getting information about available actions for a specific PID creates a contract that an external service can then rely on. Part of the contract could be the type(s), because the service would return this.
The idea of contracts (and API in general) is working well for the scope of the WG because it provides abstraction / information hiding.

There was also a minor discussion point on what this WG will provide in terms of “recommended types” and to what extent we are capable to do so. A realistic expectation should be that it is unlikely we’ll promote a minimal set at the end that is useful for lots of communities. Rather, we may end up with exemplars and perhaps some voting mechanism or ranking or other means of recommending such examples.
This is also why the Type Registry is so important because registering types makes them discoverable and reusable and thus prevents the proliferation of lots of similar types by different communities. The Type Registry WG’s model is actually to establish more than just 1 registry.

3) Discussion on possible type examples

Important: these may be somewhat academic examples, used for getting a feeling for the properties/types/profiles distinction, and some may be too sophisticated for the scope of the WG and the idea of layering. The information provided should be quite simplistic.

This is available here as a working document: https://rd-alliance.org/groups/pid-information-types-wg/wiki/type-examples.html

4) Moving towards implementation and practicalities

Some personal resources are available, and then there are the US projects and initiatives; but to get more reliable commitment, we need more time and convince by making progress and, most importantly, promote adoption. Single repositories will be more easily motivated to contribute bits and pieces if they see others doing the same. Everyone will want to have some ROI for time (money) invested.
We can probably only convince by going forward with the type examples and services/actions in the next weeks/months.

5) Miscellaneous
(already covered in other points)

Discussion