Difference between revisions of "Talk:ViRR Specification"
Jump to navigation
Jump to search
(New page: == Discussion on data formats == meeting on 12th of October In general, an external format (like METS/eBinds) can be used in three different ways: # for importing digital objects to eSciD...) |
|||
| Line 2: | Line 2: | ||
meeting on 12th of October | meeting on 12th of October | ||
In general, an external format (like METS/eBinds) can be used in three different ways: | In general, an external format (like METS/eBinds/eSciDoc) can be used in three different ways: | ||
# | # import digital objects in eSciDoc's native format | ||
# 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 | # import 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 | ||
# | # support 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 | ||
# exporting -> export to METS is probably not very problematic | |||
Questions: | Questions: | ||
Revision as of 08:03, 15 October 2007
Discussion on data formats[edit]
meeting on 12th of October
In general, an external format (like METS/eBinds/eSciDoc) can be used in three different ways:
- import digital objects in eSciDoc's native format
- import 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
- support 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
- exporting -> export to METS is probably not very problematic
Questions:
- from where does the concrete METS requirement come from? Does the MPIeR has 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?
- 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