Month: March 2011

Categories
News SWORD v2

Next draft of the v2 specifcation

A new copy of the proposed SWORD v2 specification has been posted based on recent feedback from the Technical Advisory Panel:

The main changes that were made are as follows:

1/ Changed all relevant instances of URI to IRI.

2/ Provided a better introduction with text from the business case/technical approach document.

3/ Corrected the identifiers to which 6.6.2 and 6.6.3 referred.

4/ Added 2 new sections covering overwriting metadata or overwriting with Atom Multipart (sections 6.5.2 and 6.5.3), which were missing from the previous version.

5/ Added a new section (6.10) on the use of SWORD on arbitrary IRIs in order to clarify how it should be used alongside other standards like CMIS, GData, OData, or just plain old REST.

6/ Removed the use of 202 (Accepted) as an HTTP response code to any request.

7/ Better introduction to the Metadata Handling section.

8/ Removed usage of In-Progress header on IRIs which do not represent the container (i.e. the Atom Entry).

9/ Better introduction to the Continued Deposit section, and the addition of a section on how to complete an In-Progress deposit.

10/ Added a new IRI type which is called the SE-IRI (SWORD Edit IRI) which is identified by the @rel value “http://purl.net/org/sword/terms/add”, and is used to identify the IRI which can be used to do HTTP POST against for adding content to a container.  I updated all the references for HTTP POST operations to refer to this IRI, and added it and an explanation of its relation to Edit-IRI near the top of the document.  Note this doesn’t strictly add a new IRI to be maintained, the atom:link can still point to the Edit-IRI, but their usage is distinguished as per the previous discussions on this list.

11/ Changed the rules for default packaging so that in the event that a server does not announce any packaging, the client will assume that none is supported.  I believe this means that SWORD now fully simplifies to plain old AtomPub without confusion.

12/ Changed the old IRI which represented the zip package to be http://purl.net/org/sword/package/SimpleZip, which is more descriptive.

There are still some comments on the list which haven’t been addressed.  These will be looked at next in tandem with an effort to
start the development of the clients and servers, as we feel that there’s not a lot more we can get out without first having a go at the implementations.

There are just a couple of questions regarding the latest changes:

a/ Are there any obstacles in the spec to using another APP based protocol in parallel.  We are thinking CMIS and GData, obviously, but
also perhaps others like OData.  It’s important that SWORD not prove an obstacle to them.

b/ Are there any other @rel values that we need to create to accurately describe SWORD specific operations which aren’t purely APP operations?  Looking over the profile when writing this version of the spec, it was  only the SE-IRI that we picked up.  Have we missed anything?

Categories
News SWORD v2

Discussing the scope of SWORDv2

As part of the SWORD v2 developments, the Technical Advisory Panel have been busy discussing many aspects of the proposed new version of the standard.  This has been a lively and engaging process.  If you would like to read these discussions and contribute any feedback, you would be very welcome!

One particularly interesting thread came from the project’s technical lead.  The message concerns the scope of SWORD v2 (what areas it should contribute to, ans which it should not):

Hi Folks,

There’s been some great discussion on the list this past week or two, and I thought it might be time for a summary of what looks to me to be a key sticking point: the scope of sword.

There are two distinct sides to this argument as it’s been articulated on this list:

a) That we should adopt the approach of content management API like CMIS or more likely GData

b) That SWORD should be not say anything about what happens to the content once it is sent to the server.

In general, I am against (a) for a number of reasons.  First, I am concerned that the idioms that are associated with GData are not /necessarily/ appropriate.  The hierarchical file system is a common idiom but an idiom nonetheless, and it wouldn’t be SWORD’s place to therefore build itself over the top of it.  CMIS I have a harder time refuting or accepting, so am open to persuasion either way.  Secondly, I don’t see a reason to re-create a content management standard, since they already exist.  SWORD should, instead, provide support for the things that these standards don’t provide for our sector/use cases, while not preventing the use of them.

From a purists perspective of (b) the main thing that SWORD offers, then, is support for Packaging (with a capital P).  This is a valuable addition to the community since it is both common in our sector and expressly not covered at least by GData and I believe not by CMIS (though again, open to correction).  The support for packaging, though, needs to extend to a full CRUD implementation of AtomPub, which is a large part of what the profile attempts to do.  I think we have had some good technical discussion which which will allow the next draft of the profile to do better at that.

In the mean time, there are some grey area parts of the profile, particularly In Progress and Suppress Metadata which are more content management than they are deposit.  I, personally, think these are important; they are light touch, the profile doesn’t mandate the server to obey them, and they help fulfill known use cases.  Likewise the Statement could be viewed as more content management than not, although we have tried to pitch that as more an informational resource rather than an operational one (i.e. read but not write).

What I’m going to suggest for the next draft is as follows:  we’ll put some more time into analysing the appropriate ways of updating and overwriting deposit packages using the feedback on this list.  And we will extend the profile to cover how you would use the SWORD headers to be used in content management operations /if that’s what your implementation wants/ (e.g. how you might use Suppress Metadata or In Progress with GData).  There will, obviously, be plenty of time for comment.

In conclusion: we must constrain the scope of sword to something which doesn’t tread on anyone’s toes and is of value to the community.  Too far one way or the other and we’ll either be superseded or of no value.

Cheers,

Richard

Categories
SWORD v1

Retirement of old demonstration servers

Since the very first SWORD project, there have been two demonstration SWORD servers provided.  These were funded by the original SWORD project.  They have been in existence for a number of years, and have served as excellent demonstration servers for SWORD clients. However, they have now had to be retired.

http://dspace.swordapp.org/ used to provide a demonstration DSpace system. Instead, it is possible (thanks to Duraspace for making this available) to use the http://demo.dspace.org/ server.  http://fedora.swordapp.org/ has not been replaced, but if anyone knows of a public test instance of Fedora that could be used, we’d be happy to update this page.

Categories
SWORD v2

Video introduction to SWORD v2

The team over at CottageLabs.com have created a nice 2 1/2 minute technical introductory video to the SWORD v2 standard.  You can view it via their blog:

The narrator is Richard Jones, the Technical Lead for the SWORD v2 initiative.  The video provides a great high-level introduction to the main technical concepts of the standard, and how these fit into the deposit lifecycle.