Difference between revisions of "Talk:ESciDoc Services DataAcquisitionHandler"

From MPDLMediaWiki
Jump to navigation Jump to search
(SWORD discussion moved)
Line 1: Line 1:
==Integrate SWORD?==
([[SWORD | SWORD discussion moved]])
[http://www.ukoln.ac.uk/repositories/digirep/index/SWORD SWORD] is a profile of the [http://wwmm.ch.cam.ac.uk/~ojd20/sword-profile-1.3-20081007.html Atom Publishing Protocol] and a lightweight protocol for deposit.
*Exposing and importing data
*Depositing supported by [http://arxiv.org/help/submit_sword arxiv]. (Probably nice feature to enable export to arxiv when creating an item in pubman)
experiences in using SWORD for Facebook=> repository (ePrints) can be found [http://learninglab.lincoln.ac.uk/blogs/joss/2008/12/17/facebook-to-the-repository-via-sword/ | here]. In any case, if scenarios for automatic submission to discipline-specific repositories could be supported, of great value within MPG...but still have not understood how different privileges and workflows are solved. --[[User:Uat|Ulla]] 12:52, 26 February 2009 (UTC)
*How is this topic related to the syndication manager?
*After some reading on SWORD
**first stage we could integrate it to actually support our import metadata formats
**second stage we could integrate it to support SWAP (Scholarly Works Application Profile)
**use-case to check for arXiv
*two-folded implementation of SWORD
**for deposits to PubMan
**for deposits from PubMan to Target repositories e.g. arXiv


==How to Store the Origin Information of an Item==
==How to Store the Origin Information of an Item==

Revision as of 09:07, 27 February 2009

( SWORD discussion moved)

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]

  1. Create additional attribute for an Identifier (this one could even be invisible for the user)
  2. Store the fetched data as own item and somehow relate the corresponding(transformed) escidoc item
  3. Store the fetched data as component of the created escidoc item
  4. Create additional metadata field where this info is stored
  5. Create additional metadata record where this info is stored
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)

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.
  • 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)