Difference between revisions of "Talk:ESciDoc Services DataAcquisitionHandler"

From MPDLMediaWiki
Jump to navigation Jump to search
 
(17 intermediate revisions by 2 users not shown)
Line 1: Line 1:
==Integrate SWORD?==
==DataAcquistion Service==
[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.
[http://invenio.cern.ch CERN Document Server] (http://cdsweb.cern.ch/oai2d?verb=Identify)<br/>
*Exposing and importing data
* i don't really understand the difference between "view" and "download". isn't it a problem of the API client, what to do with the response? i.e. if the client is a browser and the response happens to be HTML, it may as well display it, whereas if it is a zip file, it may open the download dialog.--[[User:Robert|Robert]] 08:39, 2 March 2009 (UTC)
*Depositing supported by [http://arxiv.org/help/submit_sword arxiv]. (Probably nice feature to enable export to arxiv when creating an item in pubman)
** Sure, you are right, the client can ignore this option and handle the response like he wants. I implemented this as a comfort feature for our communication with pubman.--[[User:Kleinfercher|Friederike]] 08:48, 2 March 2009 (UTC)
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)
** sounds like a good reason, not to have it in the public API :)
*How is this topic related to the syndication manager?
** Perhaps its a comfort feature for others as well ;)
*After some reading on SWORD
*** ok. but what exactly is the difference between the responses for "view" and "download"? just a "content-disposition" header?--[[User:Robert|Robert]] 16:04, 2 March 2009 (UTC)
**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)
==SWORD==
**use-case to check for arXiv
[[SWORD | SWORD discussion moved]]
*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==
When fetching data from an external service it is desirable to store the information where this data was fetched.
[[EsciDoc_Item_Origin | Origin discussion moved]]
===Approaches===
# Create additional attribute for an Identifier (this one could even be invisible for the user)
# Store the fetched data as own item and somehow relate the corresponding(transformed) escidoc item
# Store the fetched data as component of the created escidoc item
# Create additional metadata field where this info is stored
# 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. --[[User:Natasab|Natasa]] 15:08, 26 February 2009 (UTC)
 
===Misc===
* 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)--[[User:Uat|Ulla]] 13:37, 26 February 2009 (UTC)

Latest revision as of 16:04, 2 March 2009

DataAcquistion Service[edit]

CERN Document Server (http://cdsweb.cern.ch/oai2d?verb=Identify)

  • i don't really understand the difference between "view" and "download". isn't it a problem of the API client, what to do with the response? i.e. if the client is a browser and the response happens to be HTML, it may as well display it, whereas if it is a zip file, it may open the download dialog.--Robert 08:39, 2 March 2009 (UTC)
    • Sure, you are right, the client can ignore this option and handle the response like he wants. I implemented this as a comfort feature for our communication with pubman.--Friederike 08:48, 2 March 2009 (UTC)
    • sounds like a good reason, not to have it in the public API :)
    • Perhaps its a comfort feature for others as well ;)
      • ok. but what exactly is the difference between the responses for "view" and "download"? just a "content-disposition" header?--Robert 16:04, 2 March 2009 (UTC)

SWORD[edit]

SWORD discussion moved

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

Origin discussion moved

Application Programming Interface

Hypertext Markup Language

Coordinated Universal Time

Simple Web-service Offering Repository Deposit

Retrieved from "https://colab.mpdl.mpg.de/mw010/index.php?title=Talk:ESciDoc_Services_DataAcquisitionHandler&oldid=29208"