Difference between revisions of "EsciDoc Item Origin"

From MPDLMediaWiki
Jump to navigation Jump to search
(new page for origin of item)
 
Line 1: Line 1:
==How to Store the Origin Information of an Item==
==How to Store the Origin Information of an Item==
When fetching data from an external service it is desirable to store the information where this data was fetched.
When fetching data from an external service it is desirable to store the information where this data was fetched.
===Approaches===
===Approaches===
# Create additional attribute for an Identifier (this one could even be invisible for the user)
Three aproaches are still under discussion:
-- Not feasible due to ICE requirement
 
# Store the fetched data as own item and somehow relate the corresponding(transformed) escidoc item
* Store the fetched data as own item and somehow relate the corresponding(transformed) escidoc item
-- Good: versoining, retrieval (only needed data is retrieved), source indicated in relation  
** Good: versoining, retrieval (only needed data is retrieved), source indicated in relation  
-- (Bad: More complex), LTA Interface: Perhaps problems, more complex when exporting our data
** Bad: More complex, LTA Interface: Perhaps problems, more complex when exporting our data
# Store the fetched data as component of the created escidoc item
* Store the fetched data as component of the created escidoc item
-- Bad: logic changes needed (invisible component)
** Bad: logic changes needed (invisible component)
# Create additional metadata field where this info is stored
** Good: Metadat can be stored in different formats, not only xml
-- Not feasible due to ICE requirement
* Create additional metadata record where this info is stored
# Create additional metadata record where this info is stored
**Bad: increasing FOXML size due to versioning
--Bad: increasing FOXML size due to versioning
*Store all data in one item (fetched data is first version, escidoc data second etc.)
# Event log
 
--Bad: architectural changes needed
# Store all data in one item (fetched data is first version, escidoc data second etc.)
: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 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)


Line 24: Line 23:
** indication on user interface that this is an imported item ?
** indication on user interface that this is an imported item ?
** Source dependend rights handling
** Source dependend rights handling
** other?
* Maintainance issues (richer transformation after mapping rework)


===Misc===
===Misc===

Revision as of 14:37, 2 March 2009

How to Store the Origin Information of an Item[edit]

When fetching data from an external service it is desirable to store the information where this data was fetched.

Approaches[edit]

Three aproaches are still under discussion:

  • Store the fetched data as own item and somehow relate the corresponding(transformed) escidoc item
    • Good: versoining, retrieval (only needed data is retrieved), source indicated in relation
    • Bad: More complex, LTA Interface: Perhaps problems, more complex when exporting our data
  • Store the fetched data as component of the created escidoc item
    • Bad: logic changes needed (invisible component)
    • Good: Metadat can be stored in different formats, not only xml
  • Create additional metadata record where this info is stored
    • Bad: increasing FOXML size due to versioning
  • Store all data in one item (fetched data is first version, escidoc data second etc.)
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. --Natasa 15:08, 26 February 2009 (UTC)

Why we want to store origin information[edit]

  • Storing of origin information as legal issue
  • Source specific handling of item
    • bibtex export
    • indication on user interface that this is an imported item ?
    • Source dependend rights handling
  • Maintainance issues (richer transformation after mapping rework)

Misc[edit]

  • Do we want to store the date of fetching as well? If yes, where?
  • Original MD record has to be stored for ICE. Duplicate check necessary
  • 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)