ESciDoc Metadata Records Manipulation

Introduction[edit]

This discussion refers to problem of delivery of all metadata records of the resource by retrieval methods

For example:

Item resource has several metadata records (one of them marked as a default i.e. labeled as "ESciDoc")
- retrieveItem method delivers within the Item.xml all metadata records of this item

Item resource has one or more metadata records (one of them marked as a default i.e. labeled as "ESciDoc") and several components associated. Each component has at least one descriptive metadata record and one technical metadata record (generated by JHove service)
- retrieve Item method delivers within the Item.xml all metadata records of this item, information on all components of this item and all metadata records of all components

Item.xml (Container.xml) should embed only completely the default metadata records for item (and evtl. components) or container
Item.xml should provide the information i.e. IDs/Links to other metadata records (format to be defined)
Resource handlers should provide a method with which a particular metadata record should be retrieved i.e. retrieveMetadataRecord(MdRecordID) or retrieveMetadataRecords(ResourceID) -> that provides a list of metadata records (in same manner as in Item.xml - not full metadata records)

when users define default metadata records that is a conscious decision (in most of the time they would not need other metadata records, except on special ocasions)
in most use-cases other metadata records are originally taken metadata records during e.g. ingestion of external objects into the system
especially delivery of technical metadata records for the component is not needed by default
less network traffic (especially in item lists)
faster (smaller) cache (only default metadata records are cached)
only properties/default metadata records are filterable
users/clients are not annoyed with a need to additionally process the xml in situations such as e.g. export
client code and interfaces can be more stable, as addition of new metadata records would not affect the client code
retrieve<Resource>Complete - separate method can actually deliver complete metadata records (if users would need to have them in case of i.e. posting data to an LTA interface)

not seen to much, except if users would like to filter by non-default metadata records (but I would assume this as not primary use-case) (but even this is not a blocking factor - as in future this can be enabled - by request also for non-default metadata records)
extra request to the core services needs to be issued in order to retrieve a non-default metadata records
see above proposal for retrieve<Resource>Complete method

Searching can be made configurable
- by default: only default metadata records are indexed for searching
- if user explicitly asks: other metadata records can be indexed for searching, but that should be separate index database