Minutes From Call 2016-06-28 - Next Meeting on July 26

28 Jun 2016

Action Items and notice for next meeting:

  • All members of the group: please advise if you are wanting to join the meetings but find the current time of 13:00 GMT untenable
  • Thomas Z.: will add latest model diagrams and definitions into the growing summary document
  • Next Meeting: We will skip our next mid-month meeting and meet next on July 26 when Dimitris Koureas and colleagues will present details of their use case.  We will extend this meeting to 90 minutes long.

Discussion points/decisions from today's :

  • Reviewed the 3 proposed collection models (see working drafts folder: https://datashare.rzg.mpg.de/index.php/s/YWUxkSd7zqplCDM)
  • Seem to be moving towards convergence on the definitions as Ulrich as most recently stated them (https://rd-alliance.org/group/research-data-collections-wg/post/further-...) . More discussion needed on mapping piece.
  • Frederik would like feedback on whether his diagram accurately depicts the RDA PID Types PID Record.  We think generally yes, but that the object itself is not part of the record, rather a locator or path to it.  Welcome further feedback on this.
  • Need to be sure we have an API implementation which works for the bare bones use case and without dependencies on PID Types and DTR, but which can scale up to fuller functionality which can be delivered by these components
    • e.g. we should consider use of PID Types API and DTR as providing the means for us to support collection models which allow for assertion by the creator of a "profile" for member records at creation time - e.g. this collection can only contain items which are of datatype xyz, as expressed by a Datatype URI
    • this is generally the point of the "capabilities" metadata -- to describe what actions are and aren't for a collection
  • We will need to define best practices for use of the collections API to guide implementation
  • We need to answer the implementation question of where the collection-level metadata should/will live.  Is this a cached copy of bits of metadata which might live elsewhere (such as with the PID provider for the collection PID record)?
    • the metadata that describes what the collection is capable of and its model must be easily accessible by the implementation.
  • Should consider that the API should enable advanced functionality, such as search, to be built by consumers of it, but that all functionality is not in scope for the API itself.

Please add anything I've missed!