Notes from today's webconference. Next Call: 30 May 14:00 UTC

09 May 2017

Discussion Notes:
- For we either
need to upgrade to OpenAPI 3.0, or change schema for GET /property to
not define a return value, or leave it as is, returning the member
item. We decided moving to Open API 3.0 is out of scope for now.
Bridget will investigate whether we can leave it undefined. If not we
will leave it as is. We will open separate issues for the future for the
move to open Api 3.0 and specifying multiple values.
- discussed whether DELETE and POST commands should return the
created/deleted object. decided they should. Bridget will open issues
and make the changes. Frederik is going to review all the return
values and make suggestions for any additional changes needed.
- discussed definition of PIDs for the ontology used for the
properties in the API schema. (See and
No definite decision taken. Ulrich will take an action item to
investigate whether use of the DTR is appropriate here.
- Frederik reported on the status of the Tufts implementation. There is
now a Docker compose file which enables deployment with a Marmotta data
store. He is working on externalizing configuration. (Github repo at The Tufts
implementation will also include id minting capability for Collections
and Member items and we will likely model it as a call to a PIT API, but
may not have a real PID solution behind it initially. (Eventually would
like to be able to provide Handles as PIDs but it depends upon
infrastructure not yet in place)
- Bridget added a Ruby collections api client to the GitHub
organization. (it's at This was
auto-generated with the swagger codegen tool. She will keep it in sync
as the swagger spec is updated. It's a gem which can be used by any Ruby
code. Perseids will use it to talk to the Tufts Collections API.
- Frederik added the Perseids use case for a property which indicates
who added an item to a collection
( None other
supplied yet.
- Bridget submitted the proposal on the API work to the DH workshop on
collections. No response yet.
- For the specification document, we agreed to track requested changes
and improvements in a GitHub Issues list, and to create a new repository
for the specification, where we can also manage its content. Frederik
will convert to Markdown. The new repository is here: Requested changes,
additions, deletions from the spec should be added as issues here: Bridget
already added Javier's feedback as issues.
Action Items:
- Frederik: will conver the specification/guidelines document
to Markdown and put it in the new GitHub repository for it.
- ALL: continue to review the specification/guidelines document and
consider which section or sections you would like to volunteer to be
responsible for updating or adding to
- Bridget: issues and fixes for return values for DELETE and POST and
GET /property operations
- Ulrich: consider DTR for identifiers for schema properties
- Frederik: convert specification document to Markdown and put in the
specification repository.
- Frederik: add details of LDP mapping to the specification document