+1 for option b, However I suggest a url more link the following
http://www.dspace.org/ns/sword/1.0/ Scott-- On Feb 14, 2009, at 7:11 AM, Richard Jones wrote: > 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 ------------------------------------------------------------------------------ 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
