On 14/02/2009 17:57, Diggory Mark wrote: >> 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: > > -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)
I tend to agree with Mark and Sands - I presume that this is going to be easily configurable, and that you are just looking for the default behaviour. If we are designating a general URL, then we should liaise with the foundation to ensure that it is reserved and can be (made) resolvable in an appropriate way. On a related note, did you see my message relating to sword on the -tech list? We may want to have a similarly reserved URL for the purposes of passing an extended set of metadata. >> 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. +1 - to address Sands point, there isn't anything to stop ingest when the format isn't identified anyway, so it's a bit pointless not recognising the format as far as preservation is concerned. In fact, it would be better to recognise the format, and to then be able to explicitly state why that particular format has preservation challenges. G ------------------------------------------------------------------------------ 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 Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
