ESciDoc Item List
This page is the result of the eSciDoc workshop held in September 2007. It should serve for collecting ideas, questions and constraints, discovered while evaluating the filtering of items according to a "mini item" information object. Please feel free to use the page
Basic Idea[edit]
Base filter methods on a "mini item" = a specific data stream with minimal metadata. The metadata would be created "content model" specific with creation/update of an item.
The idea of "list metadata" is derived from the necessity to generate Dublic Core Metadata for each Fedora object (and therefore for each eSciDoc object). This generated subset of the solution specific metadata may be used for filtering/searching eSciDoc objects. The entries in the Dublic Core Metadata datastream named "DC" of a Fedora object are automatically written to the resource index. The assumption is that the core metadata entries for one object - that are written to the DC datastream of the object - are sufficient for searching/filtering.
If this leads to the usage of DC metadata as container for search specific properties this approach is of course failed.
Prototype[edit]
Boundaries for prototype by FIZ:
- with AA
- without paging
- list format RSS in RDF
Requirements (delivered by MPDL):
- item list should be sortable by:
- item list currently include following metadata:
- list hier
- transformation rules are available:
Questions & Discussion[edit]
- How to version the changes required if a change in the transformation requires a change of all item of a specific content type
- Proposed solution can be treated as a "temporary workaround" and a test for having all metadata further placed into proper storage. At present, the "list metadata" are part of the Fedora system datastream (DC metadata) that is "pushed" into the relational database. Note: only non-qualified DC metadata is allowed. --Natasa 12:32, 26 September 2007 (CEST)
- To Do: think of "moving" the "list metadata " (or all descriptive metadata) into a RDF storage (this will take substantial rework, but will give also substantial benefits for interoperability, discovery - and of course - performance etc.) --Natasa 12:32, 26 September 2007 (CEST)
- The idea to use the DC datastream is because of that the entries are automatically written to the triplestore, isn't it? It would be nice to write all entries from the solution specific metadata to the triplestore but then it must be transfered in a flat well-known structure. The DC-mapping is an approach to do that. -- Frank
- To check: Are standarc DC data sufficient to create the information required to display item lists, i.e. are all required data for sorting and displaying available in DC core?
- If not: To change the functional specification or to "disemploy" the standard?
- Should a change of the "mini item" data stream
- create a new logical version?
- create no new logical version?
- To consider for start: In case when metadata presented in the "list-metadata" are not sufficient and a new transformation is needed - this is not (from aspect of content versioning) changing the version of the content item - it just provides a new "enriched view" on the content item. In this case if very necessary: utility should be developed that is modifying the content items (but not creating new versions of them) as it is a redundant information derived from the actual metadata of the item. --Natasa 12:32, 26 September 2007 (CEST)