| | 130 | [[oschonef|Oliver (IDS)]]: The second version is a generalization of the first one. For some relations, |
| | 131 | it might lead to a more compact representation of the 1:N relations, e.g. you have 5 different annotations of a |
| | 132 | text file (e.g. different tools create POS annotations). With the first version, you'll need 5 !ResourceRelation |
| | 133 | elements, in the latter case only one. However, I don't think proposed XML serialization for solution 2 could me |
| | 134 | made better, e.g: |
| | 135 | {{{#!xml |
| | 136 | <ResourceRelationList> |
| | 137 | <ResourceRelation> |
| | 138 | <RelationType dcr:datcat="http://www.isocat.org/datcat/DC-2318">annotates</RelationType> |
| | 139 | <Resource role="source" dcr:datcat="http://www.isocat.org/datcat/DC-4009" ref="rp1"/> |
| | 140 | <Resource role="target" dcr:datcat="http://www.isocat.org/datcat/DC-2656" ref="rp2"/> |
| | 141 | </Resource> |
| | 142 | </ResourceRelation> |
| | 143 | </ResourceRelationList> |
| | 144 | }}} |
| | 145 | 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 |
| | 146 | 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 |
| | 147 | to discuss, if we want to allow this. |
| | 148 | If we decide for this general relation mechanism, I agree with Florian to get rid of the [[CMDI 1.2/Resource proxies/IsPartOf|IsPartOfList]]. |
