Difference between revisions of "Talk:ViRR Metadata"

From MPDLMediaWiki
Jump to navigation Jump to search
(New page: = Discussion on data formats for Metadata = === Possible formats === ==== 1. eBind ==== [http://sunsite.berkeley.edu/Ebind/ eBind] was developed in (1996) but has never been finished as ...)
 
Line 1: Line 1:
= Discussion on data formats for Metadata =
= Discussion on data formats for Metadata =


=== Possible formats ===
== METS ==
 
==== 1. eBind ====
[http://sunsite.berkeley.edu/Ebind/ eBind] was developed in (1996) but has never been finished as a international standard. But because a small tool for converting eBind files into HTML pages was available ([http://sunsite.berkeley.edu/cgi-bin/ebind2html/2/breen?cap eBind2HTML]), eBind was used very often. In 1998 "MOA2" ([http://sunsite3.berkeley.edu/MOA2/ Making of America]) was developed out of eBind. MOA2 then become [http://www.loc.gov/standards/mets/ METS] as part of the standardization process.
 
'''Pro:'''
*eBind enables to structure the texts in paragraphs.
 
'''Contra:'''
*eBind does not enable to mark up journals, because its not possible to define one author per article, only per book.
 
==== 2. METS ====
'''Pro:'''
* METS enables the mark up of front, cover, etc.
* 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.
* 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


'''Contra:'''
'''--> An METS import and export is needed.'''
no direct translation into eSciDoc internal format (basic services)
 
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
 
==== 3. eSciDoc native format ====
will be checked together with FIZ
 
 
=== Discussion ===


Results form the internal meeting on 12th of October
== eSciDoc native format ==
* It will be checked together with FIZ, if the METS data will be stored in METS or transfered and stored in eSciDoc native format.


== Discussion ==
In general, an external format (like METS/eBinds/eSciDoc) can be used in three different ways:
In general, an external format (like METS/eBinds/eSciDoc) can be used in three different ways:
# importing digital objects in eSciDoc's native format  
# importing digital objects in eSciDoc's native format  
Line 36: Line 18:
# exporting to METS -> export is probably not very problematic
# exporting to METS -> export is probably not very problematic


Questions:
'''Questions:'''
# from where does the concrete METS requirement come from? Does the MPIeR have concrete needs or is it more a "best practice" & assumption?
# is the eSciDoc native format rich/flexible enough to represent the [structure of the] digital objects as required by MPIeR?
# is the eSciDoc native format rich/flexible enough to represent the [structure of the] digital objects as required by MPIeR?
# If yes, does this mean we need to provide an offline editor for the eSciDoc native format ourselves?
# 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
'''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.

Revision as of 12:19, 31 January 2008

Discussion on data formats for 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

--> An METS import and export is needed.

eSciDoc native format[edit]

  • It will be checked together with FIZ, if the METS data will be stored in METS or transfered and stored in eSciDoc native format.

Discussion[edit]

In general, an external format (like METS/eBinds/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.