Skip to main content


The new RDA web platform is still being rolled out. Existing RDA members PLEASE REACTIVATE YOUR ACCOUNT using this link: Please report bugs, broken links and provide your feedback using the UserSnap tool on the bottom right corner of each page. Stay updated about the web site milestones at

Reminder: Web Conference Tomorrow 25 October 13:00 GMT

  • Author
  • #132346

    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

  • #132339


    I attached a current list of proprty fields. I started out with Bridgets Swagger definitions, the fields in italic are additions from my side.


  • #132338

    A markdown version of the above list is posted here for collaborative editing:

  • #132337

    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

  • #132335

    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?)
    – Alex

  • #132334

    I should probably have mentioned that my username is godfoder …
    – Alex

  • #132333

    Invitation sent!

  • #132332

    I have created a basic mock-up using Connexion here:
    It currently does nothing, but I’m working on adding redis as a minimal
    – Alex

  • #132331

    Fantastic! Thank you!

  • #132330

    Gee, awesome! Just checking out your repo. Using redis sounds good,
    Best, Tobias

Log in to reply.