[Tobias Weigel]

Hi Frederik,
I’ve looked at your diagrams [1]; yes, these go in the direction of the
two models I described earlier. I’m missing the “parent item” (the
actual collection) in A. This could be your “Stream n+1” object; there
may be a point about thinking whether that collection is conceptually
defined as the aggregation of all parent relations or as the aggregation
of all object. Also, should one of the objects in A be “stream n”?
Can you also upload the sources you used to create the bitmaps (what did
you use?)? We can make more diagrams for other cases.
B looks right to me. I’m musing about what the arrow might indicate
other than “n+1 follows n” – perhaps there is an interpretation with
inheritance.
Your point about PIDs indicating the referenced entity is immutable is a
possible major concern: As soon as we start about modifying collections,
we have objects whose structure changes (though semantics may stay –
referring back to your earlier point). I think we cannot avoid talking
about mutable PID’ed objects when thinking in terms of CRUD. So, in
general, these discussions are within scope, at least to the extent
where they concern collection membership.
Meanwhile, while continuing this via email, I think we should also use
the upcoming video call to discuss more details or work on diagrams.
Does Tuesday, March 29 15:00 CEST / 09:00 EDT still work for everyone?
Best, Tobias
[1]
https://rd-alliance.org/group/research-data-collections-wg/wiki/collecti…
——– Original Message ——–
*Subject: *Re: [rda-collection-wg] Collection requirements, streaming
*From: *fbaumgardt
*To: ****@***.***-groups.org

Discussion

[Bridget Almas]

March 29 works for me.

[Thomas Zastrow]

Dear all,
I had this discussion – about immutable/mutable objects a PID is
pointing to – already a few times in the past … and depending who is
attending the discussion and which current use cases are in
consideration the answers (*if* there are answers) are subject of change.
We are talking about research data *collections*. We should not talk
about versioning at all. If the content of a collection is static –
fine. If it is not static – also fine. We don’t know and we don’t care.
The concept of a collection and its PID can only guarantee the
persistence of the collection itself – but it doesn’t says anything
about the individual components. This is along the concept of PIDs in
general: the PID is persistent, but maybe it is pointing to something
which no longer exists. Same goes for the collection and its PID: the
collection is persistently there, but who knows what has happened to its
content …? Also, if the collection is not able to determine changes
done to its individual items, versioning etc. on the collection level is
not possible.
Some use cases:
– You mentioned already the ORCID use case. If my postal adress changes,
my ORCID ID stays the same. Lets say someone creates a collection of
ORCID IDs – if some of them are subject of change, the collection itself
has even no chance to find out and should also not reflect these changes
– A collection of sensor data – “Collecting started at 1.1.1990 and is
still going on”. Maybe the sensor data of one day is an immutable thing,
but not the collection itself. Creating every day a new collection is
not always an option.
My personal opinion: Per definition, PIDs are not able to deal with
versioning at all. They also can’t reflect changes in the data they are
pointing to. So it makes no sense to implement versioning etc. on a
logical level of data management which is defined by PIDs.
Before you kill me – one thing I would provide in this sense is a flag
“static” or “non static” which is assigned to the collection as a whole.
Best,
Tom

[Author]

Replies