Minutes from call 2016-08-09 - next meeting Aug 23

*Attending:* Bridget, Frederik, Maggie, Tobias, Tom, Ulrich
*Next call:* Aug 23., usual time (09:00 Eastern, 13:00 GMT, 15:00
Central European)
*Actions:*
* Tom: Prepare sth. on the one-pager
* Bridget: Continue on API
* Tobias: Continue on def document - particularly mapping function
examples, item metadata
* Bridget+Tobias: Contact use case providers - before next call
* Frederik, Ulrich: Work on examples, provide input on the mapping
function
We had a deep look at the current definitions and API impact from many
viewpoints, raising many questions in the process. The questions should
inform the next steps on deepening the definitions, API functionality
and any kind of binding elements inbetween and around.
*Notes on the definitions:*
* Need better examples for item metadata - current ones still conflict
with definition of mapping function.
o Example: order of the item within an ordered collection
o Function in the API: give me for a given collection and a given
member of the API, return the item metadata record
o "annotations" vs. "item metadata"
+ The annotations only make sense within the context of the
collection. Item metadata (core md) is independent from
collection.
* There is still a problem with distinguishing between the conceptual
definitions (which includes "functions") and the actual
API/implementation
o Capabilities: are about both - what you can do with the
collection and with the items
+ Does the mapping function belong in capabilties?
+ Is metadata created by applying capabilities?
* Capabilities: Are these explicitly offered as possible actions?
o Is there a distinction between "all capabilities theoretically
possible" vs. "capabilities as allowed on this specific
collection in its current state"?
+ Inheritance on capabilities?
+ Do we want to define a core set of capabilities that should
always be there? (What does always mean here - always
allowed or always defined for each collection, but possibly
disabled due to collection state?)
o Need to flesh out capabilities definition to understand this.
* We want to distinguish the mapping function from metadata and
capabilities. It seems odd to have the mapping function as part of
metadata.
o Bridget - example for an interesting capabilities method: A
collection can have a default member; return this.
+ Explanation: Think of a collection with like items, e.g.
expressions of a work, on sort of same level. But there is
one preferred option given back to a requestor if nothing
more specific is asked.
# Does this bring us to "roles" of items within a collection?
* Might a good example for the annotations within the
mapping function. Perfect example for a relation
between an item and its collection.
# API functions: return dictionary of items + roles; and
also: function to give back all items for a given role
(or many?)
o Need examples for mapping function - how does this look in
practice!
+ Better examples than what is currently in the doc.
* PID records: Let's not be talking too much about those; i.e., where
to store the annotations or item metadata. Folks have legacy systems
and there is conceptual baggage coming with PID records; PID records
do not scale well; also a red herring - we want to talk about
collections, not PID systems/implementations, Handles vs. DOIs etc.
o Frederik: It is becoming increasingly difficult to implement
what we have in mind within the narrow box of PID records. Free
ourselves from this to get to a coherent concept and API.
* Frederik is working on a collection sandbox in Scala:
o https://github.com/fbaumgardt/manifold_/tree/master/app/models
o Particular focus on mutability/immutability - sort of WIP and
might be hard to understand in this early form, but comments
already appreciated
o Could become a demo for Denver, depending on how far this
develops over the next weeks.
*On the API:*
* Do we want to offer the ability to expand level of depth when
querying collections of collections of ...?
o Have to be mindful of different operational architectures. Might
be too much for some.
o Stateful vs. stateless implementations - refer back to past
query and expand on it vs. fully stateless, which might not work
as soon as one leaves the tree model behind.
+ We might prefer stateless solution (REST), but that's not a
dogma.
+ Frederik: Filtering client-side may be an option, but this
may cause more scalability issues. Highly depends on
particular infrastructure on which server-side functionality
is implemented.
* Related: Ability to collapse repeated levels of collections. Filter
out certain metadata items.
o Flattening?
o Would you e.g. be able to exclude specific parts, like the
metadata description? (only give back e.g. annotations from the
mapping function?
* Need to be a bit mindful of breadth and scope of API. Not every
implementation to support all our ideas.
o Gather ideas and then boil down to a core set? Maybe still
describe advanced methods, but not make them mandatory.
*For our session at P8:*
* More discussion, less presentation!
* Have a 20-30 min. introductory presentation, giving current status,
questions clarified, ...
o Then: Continue our usual WG discussions, like what we are doing
during the calls
o Try to minimize RDA phenomenon of newcomers asking questions
already answered. Or opening up topics we already found to be
out of scope.
o But also need to draw in use case providers. What can we expect
from them?
+ Only to be there. Invite them, but not to present.
+ Circulate document draft prior to P8 (before our next call)
and gather comments via e-mail. We'll just see what they say.
* Distribute current doc draft prior to P8. Also include a FAQ with
the typical questions that we already covered throughout the last
months.
* Prepare a one-pager flyer with current status etc. to distribute at
the session, particularly to newcomers.
--
Dr. Tobias Weigel
Abteilung Datenmanagement
Deutsches Klimarechenzentrum GmbH (DKRZ)
Bundesstraße 45 a • 20146 Hamburg • Germany
Phone: +49 40 460094-104
Email: ***@***.***
URL: http://www.dkrz.de
ORCID: orcid.org/0000-0002-4040-0215
Geschäftsführer: Prof. Dr. Thomas Ludwig
Sitz der Gesellschaft: Hamburg
Amtsgericht Hamburg HRB 39784