Changes between Version 8 and Version 9 of CMDI 1.2/Resource proxies/ResourceRelation


Ignore:
Timestamp:
01/21/14 10:38:12 (10 years ago)
Author:
oddrun.ohren@nb.no
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • CMDI 1.2/Resource proxies/ResourceRelation

    v8 v9  
    166166Oddrun:
    167167
    168 We need to be clear when we are talking about n-ary relation with n>2 as opposed to a set of several binary relations. We also need to be clear on the semantics of the ResourceRelation element: Does one ResourceRelation element express one relationship only, or may it sometimes express several relationships as suggested by Oliver?
     168Comment to Oliver and Twans suggestions: I agree with the improved generalized version of ResourceRelation. However, I tend to think that the IsPartOfList should keep a special status. After all, the ResourceProxyList is in effect a PARTS list, giving the ''downlinks'' in the hierarchy a special status.  So why not also the ''uplinks''? That way, the hierarchical (or DAG-like)  resource structure can be clearly and explicitly expressed, separately from other relationships the resource as a whole or its individual parts may engage in.
     169
     170Twan, I am not sure of the necessity of having a separate  MetadataRelations, unless you want to distinguish between
     171* relations between  ''metadata files as resources in their own right'', and
     172* relations between the ''resources represented by the metadata files''.
     173In your example, my feeling is that the relation expressed is to hold between the resources, not the metadata.
     174
     175Now the PARTS (ResourceProxyList) list, the IsPartOfList and the ResourceRelationList combined provide all the structural information about the described resource that the owner wish to express, and should perhaps be wrapped together. If Resources doesn’t suit, we might rename it to ResourceSpec, like this:
     176
     177
     178{{{
     179<ResourceSpec>
     180    <ResourceProxyList>
     181        <!-- this is in effect a PARTS list, i.e. the downlinks in the hierarchical structure -->
     182        <ResourceProxy id="rp1"/>
     183        <ResourceProxy id="rp2"/>
     184        <ResourceProxy id="rp3"/>
     185    </ResourceProxyList>
     186    <isPartOfList>
     187        <!-- the uplinks in the hierarchical structure, from THIS resource as a whole -->
     188        <IsPartOf>http://infra.clarin.eu/example/mycollection1.cmdi</IsPartOf>
     189        <IsPartOf>http://infra.clarin.eu/example/mycollection2.cmdi</IsPartOf>
     190    </isPartOfList> 
     191    <ResourceRelationList>
     192        <!-- internal relations  between resources listed in ResourceProxyList -->
     193        <!-- relations between resources listed in ResourceProxyList and other resources -->
     194        <!-- relations (excluding isPartOf as expressed by the isPartOfList) between THIS resource as a whole and other resources -->
     195        <ResourceRelation>
     196            <RelationType dcr:datcat="http://www.isocat.org/datcat/DC-2318">annotates</RelationType>
     197            <Resource role="source" dcr:datcat="http://www.isocat.org/datcat/DC-4009" ref="rp1"/>
     198            <Resource role="target" dcr:datcat="http://www.isocat.org/datcat/DC-2656" ref="rp2"/>
     199            </Resource>
     200        </ResourceRelation>
     201        <ResourceRelation>
     202            <RelationType dcr:datcat="http://www.isocat.org/datcat/DC-xxx1">partOf</RelationType>
     203            <Resource role="part" dcr:datcat="http://www.isocat.org/datcat/DC-yyy1" ref="rp3"/>
     204            <Resource role="container" dcr:datcat="http://www.isocat.org/datcat/DC-zzz1" ref="../anotherCollection.cmdi"/>
     205            </Resource>
     206        </ResourceRelation>
     207        <ResourceRelation>
     208            <RelationType dcr:datcat="http://www.isocat.org/datcat/DC-xxx2">toolsUsed</RelationType>
     209            <Resource role="part" dcr:datcat="http://www.isocat.org/datcat/DC-yyy2"/> <!-- no ref denotes the resource described by THIS document -->
     210            <Resource role="container" dcr:datcat="http://www.isocat.org/datcat/DC-zzz2" ref="../someAnnotatorTool.cmdi"/>
     211            </Resource>
     212        </ResourceRelation>
     213    </ResourceRelationList>
     214</ResourceSpec>
     215}}}
     216
     217I realise this is very much like before, but with your improved relationship version. However, with a clear semantics, I think it is a good format.
     218
     219
     220'''More comments on relationships:'''
     221We need to be clear when we are talking about ''n-ary relation with n>2'' as opposed to ''a set of several binary relations''. We also need to be clear on the semantics of the ResourceRelation element: Does one ResourceRelation element express one relationship only, or may it sometimes express several relationships as suggested by Oliver?
    169222* If we constrain ResourceRelation to represent one relationship, and go for solution 2, it is possible to express realtionships of higher dimensions than 2. That is, each resource listed in the ResourceRelation participates in the same relation,for example,  any ResouceRelation with 3 resources represents a ternary relation.
    170223* If we allow one ResourceRelation to represent more than one relationship, I think in effect we limit the expressive power to binary relations. Oliver's example with 5 annotations of the same resource expressed as one ResourceRelation would then represent 5 binary relations.
    … …  
    177230How strict should we be in applying datcats to relationships, - is it sufficient to select datcats conveying the general idea of the relation, or must the datcat be explicitly defined as a relation (as in the other example using DC-2318)
    178231
    179