Difference between revisions of "Talk:ESciDoc Services DataAcquisitionHandler"

From MPDLMediaWiki
Jump to navigation Jump to search
(→‎Approaches: added pros and cons)
 
(5 intermediate revisions by one other user not shown)
Line 5: Line 5:
** sounds like a good reason, not to have it in the public API :)
** sounds like a good reason, not to have it in the public API :)
** Perhaps its a comfort feature for others as well ;)
** 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?--[[User:Robert|Robert]] 16:04, 2 March 2009 (UTC)


==SWORD==
==SWORD==
([[SWORD | SWORD discussion moved]])
[[SWORD | SWORD discussion moved]]


==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)
-- Not feasible due to ICE requirement
# 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)
# Create additional metadata field where this info is stored
-- Not feasible due to ICE requirement
# Create additional metadata record where this info is stored
--Bad: increasing FOXML size due to versioning
# Event log
--Bad: architectural changes needed
: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)
 
===Why we want to store origin information===
* 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
** other?
 
===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"