[Tobias Weigel]

Hello Ulrich,
I have gone through your revised definitions and I think they are an
improvement over what I originally wrote. I agree that your point about
the rather indirect recursion is right; to build collections of
collections is a core feature and should not be obfuscated in the
definitions.
I’ve made some small changes to the document (uploaded to the shared
folder and attached). I got a bit confused around the collection
metadata and membership metadata. I’ve now further clarified that the
latter is part of the former.
As already mentioned in last meeting’s minutes, the other main point to
continue discussion on now is the open issue you raised about the
purpose of the mapping function. So let me explain a bit more the use
case (one, not the only one) that I had in mind when I introduced it:
The mapping function allows us to state properties for a specific member
of the collection within its role or context as a member of this
collection. That means that those properties are only interpretable
within this role, but not necessarily valid properties of the object
once taken out of this context. For example, a collection may be created
within a particular system to contain several data objects and one
metadata object that collectively describes these data objects. The same
objects may, however, be considered simply data objects within the scope
of another system or use case. Therefore, within the scope of the
primary system, they will bear the “data”/”metadata” markers, but these
should be considered only valid when approaching this constellation of
objects via the particular collection.
Your suggestion was: “The Mapping Function is a function F mapping from
the collection membership to the union of item metadata elements and
collection membership metadata.”
First of all, I like talking about a union; this may be useful perhaps
as well at other places within these or future definitions. Mathematics
has these structures and using them may be an elegant trick.
However, I do not fully understand what the “item metadata elements”
will be. I don’t see a match for this in the current definitions, but
perhaps I’m looking wrong. Did you mean by this maybe those “metadata
objects” I mentioned above? Or what did you have in mind – perhaps you
can explain the use case. If there is a usage we do not cover yet and it
has to do with such a construct, we have to think a bit more in that
direction. As I said, my own original use case may be just one, so if
there is one that is not covered we have to further refine the mapping
function definition until it covers all of them.
Best, Tobias
—
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

Discussion

[Ulrich Schwardmann]

Hi Tobias,
thanks for clarifying the collection and membership metadata relation
and explaining the use case for the mapping function further. This is
very helpful.
Let me come to your question directly. The term item metadata elements
is not explaind indeed and should probably be added. I used this here to
refer to the metadata of the members or items in the collection, in
other words of the metadata you find in the next level of recursion in
the collection. I think this would cover your use case, but I’m not
really sure.

[Author]

Replies