On Feb 14, 2009, at 2:11 PM, 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
-1 (a) Unless that generator was somehow modified from the original source +1 (b) generator refers to the software +1 (c) The source is the best representation of the version of that generator I'd rather see something that did not change across versions. (b) > > > 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? I think it should have been added, its a bit silly to not being able to recognize zip packages as a bitstream format. Just set it as unsupported for those "preservation purists" who argue that we shouldn't be storing such "things" in DSpace Bitstreams. > > 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 Nice > - 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. Very good and important for other work soon to come. Big +1 on this. > - 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 Likewise, there was a great meeting last week with Microsoft Research, EPrints, DSpace, Fedora about providing ingest of office docs from within MS Office, and the target of that conversation was getting SWORD 1.3 properly implemented and supporting single file ingest. So I think you should get more involved with that discussion group. I'll forward the email summary to you. Cheers, Mark ~~~~~~~~~~~~~ Mark R. Diggory http://purl.org/net/mdiggory/homepage ------------------------------------------------------------------------------ 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
