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

Timestamp:

12/05/13 16:32:27 (10 years ago)

Author:

mwindhouwer

Comment:

--

CMDI 1.2/Header/MdType

@@ -9 +9 @@
 Originally described in [[CmdiCollectionsIdentification]]
 
-(TO BE EXTENDED)
+Due to the difference in granularity it might be good to be able to select CMD records of a specific granularity, e.g., collection or item level.
 
 == Proposed solutions ==
 
-=== First solution ===
+=== First solution: MdType header element ===
 
-Description
+A new header element that indicates the type.
 
 ==== Pros ====
 
-Pros of this solution
+Easy
 
 ==== Cons ====
 
-Cons of this solution
+There can be a tendency to keep on extending the header instead of using CMDI's flexibility.
 
 ==== Centre impact ====
@@ -35 +35 @@
 * Implementation on instance level
 
-{{{#!comment
-(Include this section if there are multiple proposals)
 ==== Discussion ====
 
 Discuss this solution proposal in this section
 
-}}}
+=== Second solution: the one and only collection profile ===
 
-{{{#!comment
+One collection profile to be used by all.
 
-=== Second solution ===
+==== Pros ====
 
-=== Third solution ===
-}}}
+Easy
+
+==== Cons ====
+
+Inflexible
+
+==== Centre impact ====
+
+* Affected tools
+* Impact on instances
+
+==== Implementation examples ====
+
+* Implementation on model level
+* Implementation on instance level
+
+==== Discussion ====
+
+Discuss this solution proposal in this section
+
+=== Third solution: a mandatory collection component for collection profiles ===
+
+Any collection level profile should contain a specific CLARIN collection component.
+
+==== Pros ====
+
+Easy, may have low impact if the component is optional (but can be detected in the schema)
+
+==== Cons ====
+
+What should be in the component?
+
+==== Centre impact ====
+
+* Affected tools
+* Impact on instances
+
+==== Implementation examples ====
+
+* Implementation on model level
+* Implementation on instance level
+
+==== Discussion ====
+
+Discuss this solution proposal in this section
+
+=== Fourth solution: the profile root uses a data category from a collection relation set ===
+
+The profile root should use one of the data categories from a specific collection relation set in RELcat.
+
+==== Pros ====
+
+Easy, low impact
+
+==== Cons ====
+
+Data category might be unintentionally used 
+
+==== Centre impact ====
+
+* Affected tools
+* Impact on instances
+
+==== Implementation examples ====
+
+* Implementation on model level
+* Implementation on instance level
+
+==== Discussion ====
+
+Discuss this solution proposal in this section
+
+=== Fifth solution: collection level instances are harvested from a specific OAI-PMH set ===
+
+Like done for web services collection CMD records can be explicitly requested by harvesting a center specific OAI-PMH set.
+
+==== Pros ====
+
+No need to touch CMD profiles or instances
+
+==== Cons ====
+
+VLO currently doesn't use endpoint information, i.e., the facet mapping can't select based on the OAI-PMH endpoint or set.
+
+==== Centre impact ====
+
+* Affected tools
+* Impact on instances
+
+==== Implementation examples ====
+
+* Implementation on model level
+* Implementation on instance level
+
+==== Discussion ====
+
+Discuss this solution proposal in this section
 
 == Tickets ==