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
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.
Deutsches Klimarechenzentrum GmbH (DKRZ)
Bundesstraße 45 a • 20146 Hamburg • Germany
Phone: +49 40 460094-104
Geschäftsführer: Prof. Dr. Thomas Ludwig
Sitz der Gesellschaft: Hamburg
Amtsgericht Hamburg HRB 39784
Definitions, mapping function discussion
You are here