[Thomas Zastrow]

Dear all,
Another point: which metadata we want to add to a collection? Some
possibilities:
a)
The easiest case: a collection has only its own identifier, no more
other metadata. Disadvantages would be that a potential user needs
already to know about the collection. Displaying / exploring through a
bunch of collections would be difficult.
b)
We leave that topic to other APIs like the PIT API or DTR.
c)
The collection API itself is able to store / handle metadata about the
collection(s).
If we are going with b) or c), a set of metadata needs to be defined,
independently where the (meta)data is stored / handled later on. A
possible solution would be to have just a Dublin Core record: it is well
known and the 15 core fields would all make sense in the scope of a
collection.
Best,
Tom
—
Dr. Thomas Zastrow
Max Planck Computing and Data Facility (MPCDF)
Gießenbachstr. 2, D-85748 Garching bei München, Germany
Tel +49-89-3299-1457
http://www.mpcdf.de

Discussion

[Tobias Weigel]

Hello Tom,
so far, I understood things as that the Collection API would surely
provide metadata in the widest sense as far as it concerns the life
cycle of the collection and questions about item membership. An
extension could be to include things such as versioning and provenance
as these are points that automated object management may require.
Another extension would be the most basic information about the
“contents”, and this is where I can well see that we wanto to rely on
Dublin Core. On the other hand, we should be as parsimonious as we can
be when it comes to such additional metadata because not every use case
will be able to provide such while still wishing to make a significant
part of the metadata elements mandatory.
A possible metaphor describing the boundaries is that of talking about
objects managed through collections, where the objects are located in a
distributed manner somewhere (in the cloud), as an abstraction layer
going beyond the traditional view where we have files managed through
filesystems and their directory structure. But clearly, the boundaries
are not defined yet, and I am not sure whether there is consensus also
among the use cases for this.
Best, Tobias
——– Original Message ——–
Subject: [rda-collection-wg] Metadata for collections
From: ThomasZastrow

To: RDA Collections WG
Date: 06 Jun 2016, 10:35
—
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

[Bridget Almas]

Hi all,
I agree with Tobias’ comments here.
I think the first point, “metadata in the widest sense as far as it
concerns the life cycle of the collection and questions about item
membership” is what we previously had been discussing as the
“capabilities” of the collection, and that general descriptive metadata,
such as could be expressed in Dublin Core, would be distinct from that.
I do think the API might need a general ability to get/set metadata on a
collection but I don’t think we should care too much about what it is.
Maybe we could recommend for general descriptive metadata that it use a
controlled vocabulary, and a capability of the collection then might be
to declare which?
Bridget

[Tobias Weigel]

I think this sounds like a good compromise to get the descriptive
metadata covered without diluting the core capabilities of the API too
much. I will include a note in the document – still more to define, but
this seems like a good principle to me.
Best, Tobias
——– Original Message ——–
Subject: Re: [rda-collection-wg] Metadata for collections
From: balmas
To: ***@***.***-groups.org
Date: 06 Jun 2016, 16:18

[Author]

Replies