Difference between revisions of "ESciDoc Metadata Records Manipulation"
Jump to navigation
Jump to search
m (→Disadvantages) |
m (→Advantages) |
||
| Line 24: | Line 24: | ||
*users/clients are not annoyed with a need to additionally process the xml in situations such as e.g. export | *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 | *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) | ||
===Disadvantages=== | ===Disadvantages=== | ||
Revision as of 14:15, 10 November 2008
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
Proposal[edit]
- 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)
Advantages[edit]
- 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)
Disadvantages[edit]
- 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[edit]
- 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