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

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?

Oliver (IDS)?: The second version is a generalization of the first one. For some relations, it might lead to a more compact representation of the 1:N relations, e.g. you have 5 different annotations of a text file (e.g. different tools create POS annotations). With the first version, you'll need 5 ResourceRelation elements, in the latter case only one. However, I don't think proposed XML serialization for solution 2 could me made better, e.g:

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

where mandatory @ref references a ResourceProxy and @dcr:datcat is optional. We need to discuss, if we want to make @role mandatory or not. I don't have a strong feeling in either direction. However, porper XSD magic can be used to ensure, that only one source role and at least one target role exists (XSD 1.1 assertions). Theoretically, one could also model N:M relations with this mechanism (by providing more source roles) and we need to to discuss, if we want to allow this. If we decide for this general relation mechanism, I agree with Florian to get rid of the IsPartOfList.

Twan?: Thanks Oliver, I like your improved representation and constraint proposals. Especially if we want to broaden the use of 'resource relations', I think we must build in this kind of flexibility (including N:M relations, what would be the downside?). On that note, using this to represent IsPartOf relations we probably want to
(1) Rename ResourceRelationList to RelationList and move it out of Resources
(2) Provide ways of referring to the document itself AND other documents that are not resources in the document (i.e. a way to express "this is part of collection Y"). For example:

<RelationList>
  <ResourceRelation>
    <!-- omitted details -->
  </ResourceRelation>
  <MetadataRelation>
    <RelationType dcr:datcat="http://www.isocat.org/datcat/DC-1234">partOf</RelationType>
      <MetadataDocument role="part" dcr:datcat="http://www.isocat.org/datcat/DC-2345"/> <!-- No ref could denote 'this document' -->
      <MetadataDocument role="container" dcr:datcat="http://www.isocat.org/datcat/DC-3456" ref="../mycollection.cmdi"/>
  </MetadataRelation>
</RelationList>

which adds a lot of power to the (resource) relation list but of course also complexity and another level of indirection. Is that roughly what you had in mind, Florian and Oliver? If so, the question is: is is it worth the additional hassle or should the 'part of' realation for metadata documents keep a special status.