Difference between revisions of "Talk:ViRR Metadata"

From MPDLMediaWiki
Jump to navigation Jump to search
Line 1: Line 1:
== MAB to MODS Mapping ==
= Display of the structural metadata =
Below are listed the requirements from the institute which still have to be discussed in our team.
 
'''Legend:''' # = Leerzeichen (Blank), & = Zeilenumbruch
 
== In the browsing tree ==
 
For details, please see [https://zim01.gwdg.de/repos/smc/trunk/03_Functional_Description/02_Scenarios_Concepts/Concepts/Virtueller_Raum_Reichsrecht/01_Documentation/Deskriptive_Metadaten_Anzeige_im_Browse_Tree.doc Deskriptive Metadaten Anzeige im Browse Tree]
 
{| border="1"
|width="150pt"|'''Spalte 1'''
|width="800pt"|'''Spalte 2 mit Einrückungen (je nach Hierarchie-Ebene)'''
|-
| Genre
|
Numeration # Creator # [CreatorRole]: # Title # : # Subtitle # / # DisplayForm. # - # StartPage # - # EndPage. &  <br/>
&  <br/>
'''LawType:''' # Legislature, # Place, # DateIssued &  <br/>
'''Schlagwort:''' # Keyword &  <br/>
'''Anmerkung:''' # Comment&  <br/>
'''Fortsetzung:''' # Continuation  <br/>
|}
 
'''COMMENTS:''' <br/>
We would like to use the same tree for browsing as for editing. Therfore, it makes sens to display the metadata seperate from the tree.
 
== In the editing tree ==
 
For details, please see [https://zim01.gwdg.de/repos/smc/trunk/03_Functional_Description/02_Scenarios_Concepts/Concepts/Virtueller_Raum_Reichsrecht/01_Documentation/Deskriptive_Metadaten_Anzeige_im_Editor_Tree.doc Deskriptive Metadaten Anzeige im Editor Tree]
 
=== SHORT FORM ===
 
GENRE # Numeration # Creator # [CreatorRole]: # Title &
 
=== DETAILED FORM ===
 
{| style="border:1px solid #1b90b5; "
|width="160pt"|'''<Genre>'''
|width="200pt"|
|width="500pt"|
|-
| bgcolor=#fedcba| '''Zählung'''
| Numeration
|
|-
| bgcolor=#fedcba| '''1. Person'''
| Creator # [Role]
| entspricht  "(2) Verfasser invertiert" oder "(3) normierte Form", falls existent
|-
| bgcolor=#fedcba| '''1. Pers. Vorlage'''
|
|
|-
| bgcolor=#fedcba| '''1. Pers. normiert'''
|
|
|-
| bgcolor=#fedcba| '''x. Person'''
| Creator # [Role]
|
|-
| bgcolor=#fedcba| '''x. Pers. Vorlage'''
|
|
|-
| bgcolor=#fedcba| '''x. Pers. normiert'''
|
|
|-
| bgcolor=#fedcba| '''Titel'''
| Title
|
|-
| bgcolor=#fedcba| '''Untertitel'''
| Subtitle
|
|-
| bgcolor=#fedcba| '''Erstellungsort'''
| Place
|
|-
| bgcolor=#fedcba| '''Gesetzestyp'''
| Law type
|
|-
| bgcolor=#fedcba| '''Körperschaft Vorlageform'''
| Legislature
|
|-
| bgcolor=#fedcba| '''Körperschaft'''
| Legislature (normierte Form)
|
|-
| bgcolor=#fedcba| '''Erstelldatum'''
| Date issued
|
|-
| bgcolor=#fedcba| '''Keywords'''
| Schlagworte
|
|-
| bgcolor=#fedcba| '''Anmerkung'''
| Comment
|
|}
 
'''COMMENTS:''' <br/>
To offer a preview in a separate window which will look like eBinds editor based on the above mentioned requirements. When w put all this info in the editing tree, this won't be a tree anymore.
 
= MAB to MODS Mapping =


The MPIER provided us with [https://zim01.gwdg.de/repos/smc/trunk/03_Functional_Description/02_Scenarios_Concepts/Concepts/Virtueller%20Raum%20Reichsrecht/02_Exemplary_Data/ 5 MAB records] for the two books (two parent records plus three child records). These 5 records will be mapped to MODS by using the rules defined in the [http://dfg-viewer.de/fileadmin/groups/dfgviewer/MODS_Application_Profile_2008-01-09b.pdf ZVDD MODS profile]. The result ([https://zim01.gwdg.de/repos/smc/trunk/03_Functional_Description/02_Scenarios_Concepts/Concepts/Virtueller_Raum_Reichsrecht/01_Documentation/MAB_MODS_v32_mapping.xml MAB_MODS_v32_mapping]) is available in the repository.
The MPIER provided us with [https://zim01.gwdg.de/repos/smc/trunk/03_Functional_Description/02_Scenarios_Concepts/Concepts/Virtueller%20Raum%20Reichsrecht/02_Exemplary_Data/ 5 MAB records] for the two books (two parent records plus three child records). These 5 records will be mapped to MODS by using the rules defined in the [http://dfg-viewer.de/fileadmin/groups/dfgviewer/MODS_Application_Profile_2008-01-09b.pdf ZVDD MODS profile]. The result ([https://zim01.gwdg.de/repos/smc/trunk/03_Functional_Description/02_Scenarios_Concepts/Concepts/Virtueller_Raum_Reichsrecht/01_Documentation/MAB_MODS_v32_mapping.xml MAB_MODS_v32_mapping]) is available in the repository.

Revision as of 11:12, 29 January 2009

Display of the structural metadata[edit]

Below are listed the requirements from the institute which still have to be discussed in our team.

Legend: # = Leerzeichen (Blank), & = Zeilenumbruch

In the browsing tree[edit]

For details, please see Deskriptive Metadaten Anzeige im Browse Tree

Spalte 1 Spalte 2 mit Einrückungen (je nach Hierarchie-Ebene)
Genre

Numeration # Creator # [CreatorRole]: # Title # : # Subtitle # / # DisplayForm. # - # StartPage # - # EndPage. &
&
LawType: # Legislature, # Place, # DateIssued &
Schlagwort: # Keyword &
Anmerkung: # Comment&
Fortsetzung: # Continuation

COMMENTS:
We would like to use the same tree for browsing as for editing. Therfore, it makes sens to display the metadata seperate from the tree.

In the editing tree[edit]

For details, please see Deskriptive Metadaten Anzeige im Editor Tree

SHORT FORM[edit]

GENRE # Numeration # Creator # [CreatorRole]: # Title &

DETAILED FORM[edit]

<Genre>
Zählung Numeration
1. Person Creator # [Role] entspricht "(2) Verfasser invertiert" oder "(3) normierte Form", falls existent
1. Pers. Vorlage
1. Pers. normiert
x. Person Creator # [Role]
x. Pers. Vorlage
x. Pers. normiert
Titel Title
Untertitel Subtitle
Erstellungsort Place
Gesetzestyp Law type
Körperschaft Vorlageform Legislature
Körperschaft Legislature (normierte Form)
Erstelldatum Date issued
Keywords Schlagworte
Anmerkung Comment

COMMENTS:
To offer a preview in a separate window which will look like eBinds editor based on the above mentioned requirements. When w put all this info in the editing tree, this won't be a tree anymore.

MAB to MODS Mapping[edit]

The MPIER provided us with 5 MAB records for the two books (two parent records plus three child records). These 5 records will be mapped to MODS by using the rules defined in the ZVDD MODS profile. The result (MAB_MODS_v32_mapping) is available in the repository.

Results & Discussion:

  1. Hierarchical record structure
    • One record for each parent and each child record exists. The child record has an element <relatedItem type="host"> pointing to the parent record by using an identifier (URL/URN)
      The current MODS file only includes identifiers of type string (e.g. <identifier type="local">66237</identifier>). These identifiers should be replaced by the appropriate uri, after the digital objects have been ingested
    • Alternative implementation (not recommended by zvdd) I: create only one object for the work and all its parts (element <part type="constituent">)
    • Alternative implementation (not recommended by zvdd) II: provide information for parent in child record without creating an individual record for the parent (element <relatedItem type="host">).
    • Please Note: It is not necessary that the parent record points to its child records, because this information will already be stored in the eSciDoc container.
  2. Handling of subject strings ("Schlagwortketten")
    • In MAB subject strings are represented in the element 710 as strings. Further on, each subject is saved in one separate element 902.
    • In MODS we transfered each subject string in one element, several "Schlagwortketten" would be transferred to separate elements. But it would be also possible to put the subjects in separate elements.
  3. The "MODS application profile" used by the DFG viewer demands identifiers in form of URNs. The Deutsche Nationalbibliothek provides a service to assign URN (NBN).
  4. Missing Metadata in the MAB file
    • The "Bandtitel" from the Sisis file was not exported to MAB and can therefore not part of an automatic mapping to MODS. The MAB files have to be created properly so that no data will get lost.
  5. MODS offers no property for the local signature of the book (MAB element 544). Can we loose this information or is there another possibility to represent this? --Kristina 16:52, 14 February 2008 (CET)
I would suggest to map this information to <location><physicallocation>, see example in MAB_MODS_v32_mapping --Inga 11:36, 18 February 2008 (CET)

Metadata Formats[edit]

Format for Structural Metadata[edit]

METS[edit]

  • METS enables the mark up of front, cover, etc.
  • METS is an international standard. It displays the hierarchical structure, the name and the location of the data storage and the metadata of objects. --> METS can be used for descriptive metadata as well as container format.
  • Im Interesse weiterer Projekte (fuer die ggf. eine Foerderung der DFG beantragt werden koennte) ist METS nahezu zwingend. Alternativ zu diesem seitenorientierten Format kaeme TEI als dokumentorientiertes Format in Frage. Das MPI praeferiert eindeutig METS, da es den gegenwaertigen Anforderungen genuegt und einen geringeren Aufwand nach sich zieht. s. auch DFG-Praxisregeln, S. 17. 18.10.2007, S. Amedick

--> A METS import and export is needed. Therefore, an Mapping from the eSciDoc Container Format to METS is needed. This has to be written in XSLT (for exemple see the Mapping eSciDoc to DC.

Discussion[edit]

In general, an external format (like METS/eSciDoc) can be used in three different ways:

  1. importing digital objects in eSciDoc's native format
  2. importing from METS format - might be very problematic from Natasa's point of view, e.g. because METS is very broad and only a specific import for ViRR METS can be done
  3. supporting METS as native format in eSciDoc -> this would require a lot of redesign in the basic services. According to Malte there are related requirements coming from the GBV
  4. exporting to METS -> export is probably not very problematic

Questions:

  1. is the eSciDoc native format rich/flexible enough to represent the [structure of the] digital objects as required by MPIeR?
  2. If yes, does this mean we need to provide an offline editor for the eSciDoc native format ourselves?

Result:
This question is the mayor decision in the project and will influence the required/chosen implementation essentially. The decision needs to be taken until January 2008! We decided to prepare an detailed evaluation together with FIZ.