Difference between revisions of "EsciDoc Item Origin"

From MPDLMediaWiki
Jump to navigation Jump to search
m (typo)
 
(2 intermediate revisions by 2 users not shown)
Line 5: Line 5:


* Store the fetched data as '''own item''' and relate the corresponding escidoc item.
* Store the fetched data as '''own item''' and relate the corresponding escidoc item.
** Pro:  Versioning, retrieval (only needed data is retrieved), source indicated in relation  
** Pro:  Version, retrieval (only needed data is retrieved), source indicated in relation  
** Con:  More complex, LTA Interface: Perhaps problems, more complex when exporting our data
** Con:  More complex, LTA Interface: Perhaps problems, more complex when exporting our data
** Open: Where to store origin MD (PREMIS?) in origin or escidoc item. How to handle the relation when an item is updated?
** Open: Where to store origin MD (PREMIS?) in origin or escidoc item. How to handle the relation when an item is updated?
:<font color="green">'''accepted''' </font>


* Store the fetched data '''as component''' of the created escidoc item
* Store the fetched data '''as component''' of the created escidoc item
Line 14: Line 15:
** Open:
** Open:


:mostly acceptable
:<font color="red">'''rejected'''</font> due to item overload


* Create '''additional metadata record''' where this info is stored
* Create '''additional metadata record''' where this info is stored
Line 20: Line 21:
** Con:  Increasing FoXML size due to versioning
** Con:  Increasing FoXML size due to versioning
** Open: How can we handle fetched components (full texts)?
** Open: How can we handle fetched components (full texts)?
:rejected
:<font color="red">'''rejected'''</font>


* Store all data in '''one item''' (fetched data is first version, escidoc data second etc.)
* Store all data in '''one item''' (fetched data is first version, escidoc data second etc.)
Line 26: Line 27:
** Con:
** Con:
** Open:
** Open:
:rejected, as there is no clear way how to match always to version 1
:<font color="red">'''rejected'''</font>, as there is no clear way how to match always to version 1


I would actually mostly vote for one of two alternatives: additional metadata record or additional component; where additional metadata record is logically better approach; However, here we have technical issues with large FoXMLs and versioning. Therefore, probably more pragmatical approach would be to stor it as a component with special content category. The content of this component should be XML i.e. a Premis metadata record that provides information on the original identifier, original repository, time of creation etc this could be more detailed inlcuding the metadata on rights, etc. see Ulla's remark below. --[[User:Natasab|Natasa]] 15:08, 26 February 2009 (UTC)
I would actually mostly vote for one of two alternatives: additional metadata record or additional component; where additional metadata record is logically better approach; However, here we have technical issues with large FoXMLs and visioning. Therefore, probably more pragmatical approach would be to store it as a component with special content category. The content of this component should be XML i.e. a Premis metadata record that provides information on the original identifier, original repository, time of creation etc. this could be more detailed including the metadata on rights, etc. see Ulla's remark below. --[[User:Natasab|Natasa]] 15:08, 26 February 2009 (UTC)


==Why we want to store origin information==
==Why we want to store origin information==
* Storing of origin information as legal issue
* Storing of origin information as legal issue
* Source dependend BibTex export
* Source depended BibTex export
* Different visualization on GUI for imported items?
* Different visualization on GUI for imported items?
* Source dependend rights handling
* Source depended rights handling
* Maintainance issues (richer transformation after mapping rework)
* Maintenance issues (richer transformation after mapping rework)


==Misc==
==Misc==

Latest revision as of 10:13, 3 July 2009

When fetching data from an external service it is desirable to store the information where and when this data was fetched. For long term archiving aspects it is desirable to store the original fetched metadata record, as well.

Approaches[edit]

Four approaches are still under discussion:

  • Store the fetched data as own item and relate the corresponding escidoc item.
    • Pro: Version, retrieval (only needed data is retrieved), source indicated in relation
    • Con: More complex, LTA Interface: Perhaps problems, more complex when exporting our data
    • Open: Where to store origin MD (PREMIS?) in origin or escidoc item. How to handle the relation when an item is updated?
accepted
  • Store the fetched data as component of the created escidoc item
    • Pro: Metadata can be stored in different formats, not only xml
    • Con: Logic changes needed (invisible component)
    • Open:
rejected due to item overload
  • Create additional metadata record where this info is stored
    • Pro: MD is stored directly in item
    • Con: Increasing FoXML size due to versioning
    • Open: How can we handle fetched components (full texts)?
rejected
  • Store all data in one item (fetched data is first version, escidoc data second etc.)
    • Pro: No overhead, Easy retrieval of data.
    • Con:
    • Open:
rejected, as there is no clear way how to match always to version 1

I would actually mostly vote for one of two alternatives: additional metadata record or additional component; where additional metadata record is logically better approach; However, here we have technical issues with large FoXMLs and visioning. Therefore, probably more pragmatical approach would be to store it as a component with special content category. The content of this component should be XML i.e. a Premis metadata record that provides information on the original identifier, original repository, time of creation etc. this could be more detailed including the metadata on rights, etc. see Ulla's remark below. --Natasa 15:08, 26 February 2009 (UTC)

Why we want to store origin information[edit]

  • Storing of origin information as legal issue
  • Source depended BibTex export
  • Different visualization on GUI for imported items?
  • Source depended rights handling
  • Maintenance issues (richer transformation after mapping rework)

Misc[edit]

  • Do we handle Metadata and full texts differently?
  • In case fetched data are transformed a) into escidoc items and/or b) into other format (e.g. part of authoring tools), the idea of storing original data related to escidoc data sounds good to me. In any case, information on date and source should be kept, just in case we have to legitimate the quality of fetched data. In addition, we might get confronted with rights information related to the source, which has to be stored as well (e.g. constraints for re-use by source, or indication of ownership)--Ulla 13:37, 26 February 2009 (UTC)

Possible workflows[edit]

MPI ICE Workflow[edit]

  • All data are stored in a big EndNote file
  • The original data (endnote) has to be stored
  • Duplicate check necessary (on endnote or item level?)