Recent Activity: Research Data Collections WG

06 Mar 2017

iDigBio Use Case

I've promised a couple of different people a narrative version of
iDigBio's RDA use case. I'll probably still work on this a little more,
so please check with me before including it in any other documents. I've
also enabled comments, so feel free to let me know where you think it
could use clarification or elaboration.
https://docs.google.com/document/d/1IJB6Y6--pCZCUpNzgl9Pfmox9dO848s_Tlh7...
Thanks,
Alex

28 Feb 2017

Notes from 28-Feb-2017 Meeting; Next call 14 March 14:00 UTC

It was a small group today, just myself, Frederik and Ulrich.
We discussed Thomas' Reptor implementation. Frederik suggests that maybe
one approach to addressing the complexity issue would be to make it
required for server implementations to explicitly declare the default
values for the required elements of the schema. Since the default values
should represent the lowest common denominator behavior, it should mean
minimal burden on the server implementation and enable clients to have a

27 Feb 2017

Implementation of the API in Reptor

Dear all,
I'm working already for some time on a repository software which
implements some of the RDA recommendations (DFT, DTR etc.). So I moved
the "standalone" implementation of the API I did so far into the
"Reptor" software.
I installed an empty instance of Reptor for playing around with the
collection API. Feel free to kill it :-) :
http://reptor.thomas-zastrow.de/col-wg/index.php
-> There is an example folder "photos" which shows most of the

15 Feb 2017

Authentication problem

Dear all,
In the API, we have read and write calls to the same endpoint. For example:
/collections/{id}/members/
When sending a GET request, it means "Get the members in that
collection". If sending a POST, it means "Add a new member to this
collection".
When having only one endpoint for both kind of operations, any
differentiation between read/write calls has to be done *on the
application level*. In other words, it has to be *implemented* in the
instance of the collection API. It is no longer possible to just put

14 Feb 2017

Simple Python client

Dear all,
We talked about clients accessing the collection API - I wrote a short
Python script which uses only the two functions "Give me all
collections" and "Give me all members of a collection" to create a
(recursive) graph out of the content of a collectors API instance in Dot
language.
Visualized with GraphViz, the graph looks like this:
https://github.com/TomZastrow/collection-api/blob/master/graph.png
Here is the Python script:

14 Feb 2017

Notes from 14-Febuary Call

Next calls: Feb 28, March 14 & 18, 14:00 UTC
Action Items for the next month:
* Frederik, Alex and Thomas to continue working on implementations
o All three need to be put into the GitHub collections
organization so that we can point adopters there
(https://github.com/RDACollectionsWG/)
* Bridget, Tobias and Maggie (and anyone else who wants to) will write
up technical details of how we each intend to adopt the API for our

14 Feb 2017

Fwd: YACA - Yet another collection API

-------- Weitergeleitete Nachricht --------
Betreff: YACA - Yet another collection API
Datum: Thu, 2 Feb 2017 15:03:18 +0100
Von: Thomas Zastrow
<***@***.***>
An: Tobias Weigel <***@***.***>, Baumgardt, Frederik
<***@***.***>, Almas, Bridget M. <***@***.***>
Following the CRUD approach, this would be:
- List all existing collections
- Create a collection
- Read a collection (returning all items it contains)
- Add an item to a collection
- Delete an item from a collection

31 Jan 2017

Minutes from today meeting

- Alex made some progress on the demonstrator. Alex will get the
demonstrator nearly done in the next month
- Alternative implementation from Frederik, can share some code with
Alex implementation
- Both implementations will have different backends (Redis, Triple Store)
-
- maxDepth:
- default will be 0
- maxDepth: will be property on the service level
- appendsToEnd: is the collection a stack or a queue
- it is possible to add an element at any place in the list (adding in
the middle)

31 Jan 2017

Regular Collections WG video call today at 14:00 UTC

Dear all,
Today is the last Tuesday of the month and we will have a GoToMeeting video call at 3pm CET / 9am EST. The technical details are here: https://www.rd-alliance.org/group/research-data-collections-wg/event/res...
Today’s agenda items are:
1. Discussing plans for the demonstrator
2. Input on the maxDepth property
3. Discussing item mapping functions
Hope to see you in the call,
Frederik

11 Jan 2017

Collections call minutes from 10 January 2017. Next call: Jan 31

Dear all,
here are the minutes of yesterday's call.
Best, Tobias
*Tuesday 10 Jan 2017 - Collections VC*
Next call: Tue Jan 31, 14:00 UTC
Actions:
* Tobias: Contact Alex on the demonstrator
* Tobias: Review spec, spot missing methods, params etc.
* Bridget & Frederik: merge wiki page into spec - get one single point
of reference
* All: think about maxDepth - what do we want this to be?
* Tom: Have a go at the P9 flyer
Notes:
* Discussion on next steps up to P9

04 Jan 2017

Confirming regular collections call on January 10

Dear all,
just to confirm: We will have a regular Collections WG videocall next
week, Tuesday January 10, 14:00 UTC.
Call details as usual here:
https://www.rd-alliance.org/group/research-data-collections-wg/event/res...
Best, Tobias
--
Dr. Tobias Weigel
Abteilung Datenmanagement
Deutsches Klimarechenzentrum GmbH (DKRZ)
Bundesstraße 45 a • 20146 Hamburg • Germany

03 Jan 2017

CFP: Persistent Identifier session at EGU 2017

Dear colleagues,
the following session at the European Geosciences Union General Assembly
2017 may be of interest to those combining PID topics with geosciences
and related disciplines. Submission deadline is January 11.
Apologies for cross-postings.
http://meetingorganizer.copernicus.org/EGU2017/session/22861
ESSI 2.3 - Developing Persistent Identifiers for Future Applications and
Maintaining Integrity

28 Nov 2016

Collection WG call tomorrow, Nov 29 - cancelled

Dear all,
as none of the co-chairs will be easily available tomorrow for the
regular videocall, we will cancel the call.
According to our schedule, the next meetings would be Dec 13, which
collides with the RDA chairs meeting in Gaithersburg, and Dec 27, which
might also see quite low attendance. Unless we want to squeeze in an
irregular meeting, I suggest that our next regular call should be
January 10, 14:00 UTC.
Best, Tobias

09 Nov 2016

Minutes from call 2016-11-08 - next meeting Nov 29, 14:00 UTC

*Tuesday, 08 Nov 2016 - Collection WG call*
*Attending: *Alex, Bridget, Frederik, Maggie, Tobias, Tom
*Next call: *Nov 29, 14:00 UTC-0
The properties discussion was heavy and we decided that the many details
should be continued offline via GitHub: Do it via the Wiki, iterating on
Frederik's page, and use issues for individual property details;
alternatively, use Wiki subpages.
Nonetheless, there was also agreement that the next call should continue
with the remaining sections of the Wiki page, depending on attendance.
*Actions:

Pages