Hi Folks, Sorry for general long-term silence at this end, I have been diverted onto other projects over the past months. But, at the moment, I'm working on the DSpace implementation for the SWORD 1.3 specification:
http://www.swordapp.org/docs/sword-profile-1.3.html I have a couple questions for us to answer before I can finish this up, which I hope to do in time for the 1.5.2 release. These are: 1 - In Sections 3.3 and 3.4 there is specified an atom:generator element for the deposit response. This entry requires a URI defining the software which generated the response, and I'm unsure as to what the best thing to put in that field is. The options are: a) The URI of the instance of DSpace which generated the response (i.e. the actual repository) b) Some generic DSpace URI such as http://www.dspace.org/sword-app c) The URI to the sourceforge svn for the code for the dspace-sword module Anyone have opinions on this? 2 - During development I've noticed that application/zip is not a default bitstream format in the bitstream format registry. Is this deliberate or an oversight? As it happens, it would make a SWORD interface behave much more sensibly if this is available in the format registry (otherwise the application has difficulty in identifying zip files when they are re-exposed via the interface). Can we add this to the default bitstream registry, or is there some subtle problem which I have not taken into account? Any thoughts on either of these questions much appreciated. A quick update on what will be happening in the next version of DSpace SWORD: - Support for nested service documents, allowing (through configuration) the Community, Collection and Item structure of the archive to be browsed via service documents, and deposit targets discovered where appropriate - Support for single file deposit onto DSpace Items. So before it was only possible to deposit a package conforming to the METSDSpaceSIP format into a Collection to obtain an Item, but now it will be possible to deposit a single PDF (for example) into an item discovered through the above nested service document retrieval. - General architectural improvements and use of the Plugin Manager to allow dynamic loading of ingesters. - Greater configurability over the behaviour of the sword service offered by a DSpace instance - obviously, compliance with the request/response protocols of the latest version of the standard Cheers Richard ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Dspace-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-devel
