New version of the specification

Thomas et all,
Thank you for including the A&A section. I am working on a use case
within a data regulated environment (eg HIPPA). Ideas for names to the
"special users" might include:
Owner (keep as is)
Authenticated (in place of public)
Everyone (in place of anonymous)
Static data only?
I personally envision a future need for collections which are dynamic
(eg not all the data on a specific topic is known).
With this in mind I would like to suggest a flag or trait defining
static/dynamic collection data.
Additionally, to keep consistency at a given point in time, a collection
might have a "snapshot" collection(s) over various points in time. The
snapshot(s) would refer to static collection at the given point in time.
Thank you,
-C

Dear C,
Thanks for your suggestions regarding the "special users", if nobody
complain I will change the document.
Static data: maybe we have to make a differentiation here between a) the
data which is part of a collection and b) the collection itself:
a)
From the point of view of the collections API, it is difficult to say
anything about the "staticness" of individual items. If an item is
represented by a PID, then it least we can say we have persistence in
the meaning that the PID will stay (forever), even if the data is
already gone.
b)
A collection itself was never meant to be static in general. In the
document, Tobias has defined the property "read only (boolean)". In that
sense, a collection *can* be static if read only is set to true, but it
doesn't have to.
Best,
Tom

Hi,
thank you, Tom, for bringing up the authentication topic. I agree that
the authentication mechanics should stay simple given our current scope.
I've made some additions, see attached. I also prefer to have the
document somewhere in a cloud working area, so if you can provide one
that would be good.
Regarding the topic of static and dynamic collections: This concerns one
of the most recurring use cases for collections we have seen so far, so
we try to model it in detail. As Tom explained, these distinctions are
already visible through the various traits. In the past, I have made the
experience that this is not an easy topic, deciding for either one or
the other, but there are some variations in the middle as well, which
are reflected in the traits. I also see the need for "snapshot
collections", which can also be modelled through the traits by calling a
cloning operation and then removing those traits that would result in
modifications.
This also sounds to me as if the API must provide methods to manage
(add, remove) traits. Not entirely sure whether there is a better way.
Best, Tobias
-------- Original Message --------
*Subject: *Re: [rda-collection-wg] New version of the specification
*From: *ThomasZastrow
<***@***.***>
*To: *harrison <***@***.***>, ***@***.***-groups.org

Dear all,
Tobias, thanks for the additions. I put the document into our DataShare
cloud:
https://datashare.rzg.mpg.de/index.php/s/YWUxkSd7zqplCDM
The link is read-only and public available. If you want to have write
access to the folder, please let me know and give me an email adress or
- if you have one, your MPCDF user account name.
Best,
Tom

... btw. I'm on a workshop today and can't join the videomeeting in the
afternoon.

Hi Tom,
thank you for uploading the document. I think we can use the folder to
add more drafts in the future. I am also currently going through oru
public RDA pages - is it ok to put the link on our front page?
Best, Tobias
-------- Original Message --------
*Subject: *Re: [rda-collection-wg] New version of the specification
*From: *Thomas Zastrow
<***@***.***>
*To: *TobiasWeigel <***@***.***>, harrison <***@***.***>,
***@***.***-groups.org

Yes of course. The link is readonly, if someone needs write access, just
let me know.