Currently the index processor populates the 'resourceMap' field for each aggregated object in a resource map based on the cito:documents relationship, putting the resource map id in that field.
This approach doesn't work for metadata only packages, where there are no objects that have the 'cito:documents' field.
Client software such as the dataone R package add a self-refering 'cito:documents' relationship for the metadata object, so that the link from the Solr doc for the metadata object back to the resource map is made.
An approach that we should consider is to use the 'ore:isAggregatedBy' relationship to identify all the package members that should have the resourceMap field populated, because for metadata-only packages, this relationship is present, as the ORE spec requires.
Things to consider with this change:
will a re-indexing of the entire DataONE corpus be required?
will additional items be 'linked' for some packages, as there may be more 'isAggregated' relationships that 'documents'
Currently the index processor populates the 'resourceMap' field for each aggregated object in a resource map based on the
cito:documentsrelationship, putting the resource map id in that field.This approach doesn't work for metadata only packages, where there are no objects that have the 'cito:documents' field. Client software such as the
dataoneR package add a self-refering 'cito:documents' relationship for the metadata object, so that the link from the Solr doc for the metadata object back to the resource map is made.An approach that we should consider is to use the 'ore:isAggregatedBy' relationship to identify all the package members that should have the
resourceMapfield populated, because for metadata-only packages, this relationship is present, as the ORE spec requires.Things to consider with this change: