The advantages of alleviating or removing the above limitations would be huge. It would make it easier to integrate the repository into other systems, both userfacing and administrative, by providing a coherent and fully functional content storage and retrieval ser vice. It would give repositories and repository managers the opportunities to access content earlier in its lifecycle, and to engage more readily in the archiving and publishing aspects of the repositorys mission. It would also make it easier for userfacing systems to hide the details of the repositor y from endusers, by providing simple file management interfaces. In the long term it is hoped that increasing the ease by which repositories provide their services to partner systems would increase their holdings and usage and thus their value to their owners and the community at large.
It is not possible to introduce features to deal with everything we discuss above immediately. This next version of SWORD will instead constrain itself to a single critically important area which will pave the way to full deposit lifecycle support: the URIs supplied to the client in the deposit receipt, and the resources to which they resolve.
Quoting RFC4287:
The “atom:id” element conveys a permanent, universally unique identifier for an entry or feed.
In the case of SWORD this should be an entry and should be a URL style URI which can be resolved.
What it resolves too… let the client decide in the HTTP ACCEPT header?
Video of this working on EPrints: http://www.eprints.org/software/training/3.2/videos/sword_feedback_loop.swf
This paragraph doesn’t say much without the context of a use case… of which there still isn’t one. Also the last sentance worries me, allow me to flip it…
In the long term it is hoped that increasing the ease by which repositories provide their services to partner systems would help partner systems to increase their holdings thus doing away with the need for the repository.
It could have been phrased to enphasise interoperability between all systems.
The language here worries me a bit. On the one hand I really like the idea of broadening the appliability of SWORD. However, phrases such as ” It would give repositories and repository managers the opportunities to access content earlier in its lifecycle, and to engage more readily in the archiving and publishing aspects of the repository’s mission.” worry me.
For me “the opportunities to access content earlier in its lifecycle” is feature creep for repositories. Isn’t that the job of CMS systems?
Perhaps a better approach (and I confess to knowing bery little of SWORD or repositories) would be to view SWORD as the integration point between existing CMS style systems (the earlier part of the lifecycle) and the repository systems (the archiving and retrieval of “completed” works).
The goal would be to avoid re-inventing the wheel with respect to the earlier (CMS) lifecycle of content production whilst using SWORD as the common element between production and archiving.
That is, authors start out with a lightweight “deposit” in collaborative CMS systems (minimal meta-data, loose packaging requirements etc.) Upon publication the user “flicks a switch” and SWORD now assistes with detailed meta-data and packaging requirements for deposit in a repository.
Working on the assumption that the (0) next to the heading is about comments, I thought I’d comment to avoid “Impact (0)”…