Changes between Version 2 and Version 3 of CMDI 1.2/Header/MdType

Timestamp:

12/13/13 06:56:24 (10 years ago)

Author:

herold

Comment:

--

CMDI 1.2/Header/MdType

@@ -37 +37 @@
 ==== Discussion ====
 
-Discuss this solution proposal in this section
+[[herold|Axel]]: This would work if we agreed on a fixed set of types, ideally with just two elements (collection, part_of_some_bigger_collection). But as always there is no sharp line to be draw between even those two values. E.g. for the Deutsches Textarchiv (a collection of digitalized complete printed book) one could argue that each part is also a complete and self-contained resource in its own right -- it just happens to have been arbitrarily chosen for inclusion in the Deutsches Textarchiv. Maybe we would need to introduce a third type 'archive' for cases like those?
 
 === Second solution: the one and only collection profile ===
@@ -63 +63 @@
 ==== Discussion ====
 
-Discuss this solution proposal in this section
+[[herold|Axel]]: We shouldn't go this route. It's so inflexible that it is hard to imagine such a catch-all profile will ever stabilize. We would end up with a whole family of profiles anyway once profile versioning is in place.
 
 === Third solution: a mandatory collection component for collection profiles ===
@@ -141 +141 @@
 ==== Discussion ====
 
-Discuss this solution proposal in this section
+[[herold|Axel]]: No, this is a dirty hack, i.e. a tailor made solution for VLO harvesting outside of the CMDI framework proper. Collection information must be expressed within the CMDI framework so that it is available not only at harvest time but also within MD instances.
 
 == Tickets ==