SWORD2 kick-off notes
From DigiRepWiki
Rough notes from SWORD kick-off meeting, 1st July 2008
Updates to the SWORD Profile
- sword level - remove; only one level
- add <sword:version> to replace <sword:level>
- add <sword:maxuploadsize>
- consider <sword:errorcode> as outlined by Simeon in his case study, i.e. passing an ATOM document as an error message.
- re-align with APP wherever possible
- basic over HTTP – check that this isn't mandatory in SWORD (it shouldn't be)
- make a clear recommendations about use of URIs for deposit; possibly recommending that the atom document is kept as part of the created object; consider removing use of slug-header; consider use of a new HTTP header for passing the deposit id (Jim's idea)
- format namespace – extend or refine?
- review current ATOMPUB and extend SWORD profile to support additional bits of ATOMPUB, e.g.
- support for depositing ATOM docs only for passing references to resources
- supporting the multipart draft (http://www.ietf.org/internet-drafts/draft-gregorio-atompub-multipart-01.txt) to enable deposit of an ATOM document along with multiple files without use of a package or zip
- This goes beyond what Jim calls 'ATOMPUB FOR PACKAGES' and begs the question - is SWORD still useful, do we still need the extensions?
- rather than creating a separate review of ATOMPUB, it might be better to add a section to the existing profile about 'the rest of ATOMPUB', not recommending support, but encouraging implementations to support local needs. The main unsupported aspects are update/delete, categories, list collections - are there any any obvious benefits to implementing these?
Also: auto-discovery of deposit target URI supporting nested collections with service documents; having some mechanism for chunking up large service documents append
Implementation
- Update SWORD code libraries and implement
- Improve SWORD code libraries and implement
- Finish PHP library (integration into Facebook)
- Develop validator
- Implement changes to profile
- MS Word .Net implementation (scope work for JISC consideration? contact Lee Dirks and others at microsoft to find out how far they have got)
- test accepting deposits from arXiv
Other work:
- Create package registry (this could only be a very lightweight piece of work)
- Uptake/Advocacy VERY IMPORTANT!
- OAuth and FAM project – make contact, probably isn't time to implement OAuth, but worth considering
- Contact other integration targets – ESRC, UKPMC, arXiv, Microsoft, Nature … more?
Idea from Jim of turning this into an IETF standard.
