wiki:CMDI 1.2/Header/MdType

Version 2 (modified by mwindhouwer, 10 years ago) (diff)

--

This page is a subpage of CMDI 1.2

MdType instance header element

  1. MdType instance header element
    1. The issue
    2. Proposed solutions
      1. First solution: MdType header element
        1. Pros
        2. Cons
        3. Centre impact
        4. Implementation examples
        5. Discussion
      2. Second solution: the one and only collection profile
        1. Pros
        2. Cons
        3. Centre impact
        4. Implementation examples
        5. Discussion
      3. Third solution: a mandatory collection component for collection profiles
        1. Pros
        2. Cons
        3. Centre impact
        4. Implementation examples
        5. Discussion
      4. Fourth solution: the profile root uses a data category from a …
        1. Pros
        2. Cons
        3. Centre impact
        4. Implementation examples
        5. Discussion
      5. Fifth solution: collection level instances are harvested from a …
        1. Pros
        2. Cons
        3. Centre impact
        4. Implementation examples
        5. Discussion
    3. Tickets
    4. Discussion

The issue

Originally described in CmdiCollectionsIdentification

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: MdType header element

A new header element that indicates the type.

Pros

Easy

Cons

There can be a tendency to keep on extending the header instead of using CMDI's flexibility.

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

Second solution: the one and only collection profile

One collection profile to be used by all.

Pros

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

Tickets in the CMDI 1.2 milestone with the keyword mdtype:

Ticket Summary Owner Component Priority Status
No tickets found

Discussion

Discuss the topic in general below this point