Hi all,
Just a reminder that we have our next Webconference tomorrow at 13:00 GMT (9:00 Eastern, 15:00 Central European)
Call-in details here: https://www.rd-alliance.org/group/research-data-collections-wg/event/res...
Notes and action items from last meeting: https://www.rd-alliance.org/group/research-data-collections-wg/post/meet...
See you tomorrow!
Bridget
- Log in to post comments
- 9381 reads
Author: Tobias Weigel
Date: 24 Oct, 2016
Hi Bridget,
I'll be there; I'm currently going through your updated API spec in
detail and may have some comments we can talk about tomorrow. Nothing
big and serious, just details to clarify. The whole scope is already
very good :-)
Best, Tobias
Author: Frederik Baumgardt
Date: 25 Oct, 2016
Hi,
I attached a current list of proprty fields. I started out with Bridgets Swagger definitions, the fields in italic are additions from my side.
Frederik
Author: Frederik Baumgardt
Date: 25 Oct, 2016
A markdown version of the above list is posted here for collaborative editing: https://github.com/RDACollectionsWG/apidocs/wiki/Collections-and-Service...
Author: Tobias Weigel
Date: 25 Oct, 2016
Hello Frederik,
after today's call, I just went through your list and I have some
comments. Feel free to discuss; in general, I agree to most of what you
suggest, while the other points I find hard to decide without more
discussion. But I think your list is a step forward, in any case, we
should discuss this at our next call.
Service caps:
- supportsSetOperations flags: yes, definitely required.
- providesVersioning: not sure how this fits in; isn't this a use case
concern, to be solved at the client side?
- allowsRecursiveness: also required, but I am not sure what the
"remote" case will mean. If this means that recursion is only possible
if a client retrieves the actual collection and parses it, I think it
would be a bit too far away for the API to make a statement, as it is
outside its control.
- hasItemStore: Similar concern, is this really something we want to
provide at our API level?
Collection properties:
- memberOf: Yes, this looks like a miss, though I could also imagine
this to be done through a dedicated method as I am not sure whether all
implementations will store such info at the same place as e.g. ownership
and license. Might well be. But still I'm divided here.
Collection capabilities:
- isOrdered random vs. append: So this is the linked list vs. array
distinction. I'd also like to include that, even if it probably does not
have any influence on method behaviour (params, valid ops) other than
run time costs. But such costs may be decisive in some cases...
- maxDepth: Yes, without recursiveness, this cannot be more than 1, and
we also need a flag for infinity. I currently don't see an alternative
to introducing a dedicated "infiniteDepth" flag.
- isHomogeneous: sounds very useful to me, but optional via features.
- maxLength: yes
Item mapping functions:
- role: I am also undecided on how to manage this. If it is a CV, how is
this managed? Multiple roles per item may also be useful, but also
increases complexity. I am not sure what a good compromise is.
- dateAdded: Useful, but may also be optional, so can be marked as
disabled via service features.
Best, Tobias
Author: Alexander Thompson
Date: 25 Oct, 2016
Can you add my github username to the organization (if possible, with
the ability to create repos... if not, can you create a repo for the API
prototype to go into?)
Thanks,
- Alex
Author: Alexander Thompson
Date: 25 Oct, 2016
I should probably have mentioned that my username is godfoder ...
- Alex
Author: Bridget Almas
Date: 25 Oct, 2016
Invitation sent!
Author: Alexander Thompson
Date: 25 Oct, 2016
I have created a basic mock-up using Connexion here:
https://github.com/RDACollectionsWG/rda_collections_api
It currently does nothing, but I'm working on adding redis as a minimal
backend.
- Alex
Author: Bridget Almas
Date: 25 Oct, 2016
Fantastic! Thank you!
Bridget
Author: Tobias Weigel
Date: 26 Oct, 2016
Gee, awesome! Just checking out your repo. Using redis sounds good,
Best, Tobias