This page is a subpage of CMDI 1.2

Specification of resource relations

The issue

CMDI 1.1 has an optional element /CMD/Resources/ResourceRelationsList that can look something like the following:

<ResourceRelationList>
 <ResourceRelation>
  <RelationType>describes</RelationType>
   <Res1 ref="a_text"/>
   <Res2 ref="a_photo"/>
  </ResourceRelation>
 </ResourceRelationList>
</Resources>

This is a relatively little used feature and it has even been argued that it can be removed. However it is being used in practice and has sensible use cases (at least theoretically). The problems with this implementation are the lack of clear semantics, a forced but implicit relational direction (e.g. Res1 describes Res2) and inelegant naming (Res1, Res2).

Proposed solutions

First solution

In an e-mail discussion (17 January 2012), Dieter? proposed the following:

- about the <ResourceRelationList>, with the input from Torsten and
Menzo I would like to propose a structure like:

<ResourceRelationList>
  <ResourceRelation>
    <RelationType dcr:datcat="http://www.isocat.org/datcat/DC-4009">
     annotates
    </RelationType>
    <Source ref="rp1"/>
    <Target ref="rp2"/>
  </ResourceRelation>
</ResourceRelationList>

This has:

-- a machine-readable relationtype (a datcat) while maintaining a prose
text description possibility

-- a clearly directed graph nature for the relation (source/target)

For symmetric relations that means that if there is a bidirectional
relation 2 ResourceRelations need to be specified (A -> B and B -> A)

We could make this change as no one is currently using ResourceRelationList.

Pros

• It adds semantic grounding of the relation

Cons

• Forces direction on the relation
• Limits the number of resources taking part in the relation to two.

Centre impact

Tools that generate/process resource relation lists will need to be adapted

Discussion

Discuss this solution proposal in this section

Second solution

A more flexible solution was discussed recently. It would have for example:

<ResourceRelationList>
  <ResourceRelation>
    <RelationType dcr:datcat="http://www.isocat.org/datcat/DC-2318">annotates</RelationType>
    <Resource ref="rp1">
      <Role dcr:datcat="http://www.isocat.org/datcat/DC-4009">annotation</Role> 
    </Resource>
    <Resource ref="rp2"/>
      <Role dcr:datcat="http://www.isocat.org/datcat/DC-2656">annotated</Role> 
    </Resource>
  </ResourceRelation>
</ResourceRelationList>

The dcr:datcat attributes should probably be optional.

The maximal number of <Resource> elements should be unbounded, allowing for relations between any number of resources. (EXAMPLE? USE CASE?)

Pros

• Semantic marking of both relation type and roles of resources
• Option to have more than two resources involved in a relation
• No forced relational direction

Cons

• More verbose
• More processing of datacategories
• No default direction (while most cases will be covered by subject-object in that order)

Centre impact

Tools that generate/process resource relation lists will need to be adapted

Discussion

Discuss this solution proposal in this section

Tickets

Tickets in the CMDI 1.2 milestone with the keyword resourcerelationlist:

Ticket	Summary	Owner	Component	Priority	Status
No tickets found

Discussion

Discuss the topic in general below this point

Florian (BAS): The first proposal makes a lot of sense. But if such a general relation mechanism is implemented, we should also consider to remove the special relation 'isPartOf' (see seperate issue) and deal this as any other relation. The second proposal is not very lucid to me. Can anybody add a practical use case where this is necessary?