= Metadata Record Sibling Relationships =

|| '''Date''' || 2012-09-20 ||
|| '''Contact(s)''' || Simon Pigot ||
|| '''Last edited''' || 2012-09-20 ||
|| '''Status''' || Motion passed - Done ||
|| '''Assigned to release''' || 2.9.0 ||
|| '''Resources''' || Available ||
|| '''Ticket #''' || #1068 ||

== Overview ==

ISO Metadata records can be related to one another in different ways. The mechanisms for handling these relationships are most often part of the standard in the form of specific elements eg. parent-child relationships are handled through the parentIdentifier element and the datasets that a service delivers are handled through the operatesOn element. !GeoNetwork:
 * can index these relationships to support search
 * has services for retrieving a specific set of related records or the entire collection of related records
This proposal adds sibling relationships between metadata records to !GeoNetwork. The elements in the ISO standard that support sibling relationships are the aggregationInfo element. Sibling relationships types can be specified using an extendible codelist. Sibling records would be displayed under the relationship type. An example of how sibling relations are displayed in the classic interface and the new ExtJS interface are shown below.
[http://www.awanirentcar.com Sewa Mobil Jakarta], [http://www.yourbutik.com Parfum], [http://www.detikauto.com Aksesoris Mobil], [http://www.grosir-kosmetik.com/6-baby-pink-cream-pemutih-kulit Baby Pink Cream], [http://kiosauto.com Aksesoris Mobil]

=== Proposal Type ===
 * '''Type''': GUI Change, Core Change
 * '''App''': !GeoNetwork
 * '''Module''': ExtJS Experimental Interface, Classic Interface, Services for retrieving Metadata Relations

=== Links ===
 * '''Other wiki proposals''': Mentioned as a possible extension in Francois' original metadata relations proposal: http://trac.osgeo.org/geonetwork/wiki/MetadataRelation

=== Voting History ===
 * Vote to be proposed by Simon Pigot, result was +/-n (m non-voting members).

----

== Proposal == 

Aggregate Information in an ISO record that has a related sibling record uses the aggregationInfo element. This looks something like the following:

{{{
    <gmd:aggregationInfo>
        <gmd:MD_AggregateInformation>
            <gmd:aggregateDataSetIdentifier>
                <gmd:MD_Identifier>
                    <!-- optional gmd:authority here: could have details of a register describing the some details of the sibling record -->
                    <!-- code is UUID/urn of the sibling record, could be a gmx:Anchor -->
                    <gmd:code>
                        <gco:CharacterString>urn:marine.csiro.au:project:1532</gco:CharacterString>
                    </gmd:code>
                </gmd:MD_Identifier>
            </gmd:aggregateDataSetIdentifier>
            <gmd:associationType>
                <gmd:DS_AssociationTypeCode codeList="http://...#DS_AssociationTypeCode" 
                                            codeListValue="crossReference">crossReference</gmd:DS_AssociationTypeCode>
            </gmd:associationType>
            <!-- initiative type describes the type of sibling relationship - in this case the code is a project 
                 related to the record that contains this aggregateInformation -->
            <gmd:initiativeType>
                <gmd:DS_InitiativeTypeCode codeList="http://...#DS_InitiativeTypeCode" 
                                           codeListValue="project">project</gmd:DS_InitiativeTypeCode>
            </gmd:initiativeType>
        </gmd:MD_AggregateInformation>
    </gmd:aggregationInfo>
}}}

The UUID of the related record is held in an MD_Identifier element, the associationType is set to crossReference (which seems the most appropriate association type code) and the initiativeType is set to the type of sibling relationship (in this example 'project').

To retrieve and display related records from the aggregationInfo block, we extend the process that is used for parent-child and other relationships:
 * in the java code underlying the !GetRelated guiservice. A simple XPath extraction for all aggregationInfo elements that have an aggregateDataSetIdentifier with a code, an associationType with value set to crossReference and an initiativeType is used to assemble the list of codes (UUIDs/URNs). Sibling metadata records are extracted from the database and attached to the XML output of the !GetRelated guiservice.
 * add processing of the !GetRelated output in relations.xsl which is used in the xml.relation service - returns a simple/brief view of the related records.
 * add processing of related sibling records from guiservice to iso19139/present/metadata-iso19139-utils.xsl - this XSLT generates the classic presentation of related records - see below (Note that the same record is used as a parent and as a 'project' sibling).
[[Image(ClassicSiblingRelationships.png)]]
 * add processing of related sibling records from xml.relations to the ExtJS !MetadataRelationStore.js and the ExtJS user interface - see below.
[[Image(NewSiblingRelationships.png)]]  

To create aggregationInfo elements representing sibling relationships, the user would use the advanced editor to expand the aggregationInfo element manually and:
 * search for and select a sibling metadata record whose UUID will become the aggregateDataSetIdentifier (The search widget for the parentIdentifier is used for this purpose)
 * select 'crossReference' as the associationType
 * select an appropriate initiativeType to describe the sibling relationship

The editing session to create the aggregationInfo block would look something like the following:
[[Image(EditingAggregationInfo.png)]]

=== Backwards Compatibility Issues ===
None known.

=== New libraries added ===
None required.

== Risks ==
As is the case with many features of the ISO standard, best practice for the use of the aggregationInfo element is not defined. There is a risk that the way in which we are using this element will not suit all users. However one way of developing best practice is to attempt to use the element in different ways and accumulate experience which we hope will not be too bitter :-)

 
== Participants ==
 * Simon Pigot