Hi Mark, What you are after is the Service Document. The Sword spec describes a Service Document that the server should provide when requested, to advertise amongst other things, what package formats it supports. So the typical conversation would go...
Client - "Please send me your Service Document" Server - "Here it is" Client - "Thanks. Now I know what you support I'm going to send you a package you will be happy with" Server - "Got it!" Sorry, got to rush but I'll try and find some links to examples later. Cheers, Robin. On 24/05/12 15:39, Mark Jordan wrote: > Marco, > > Thanks for the pointer to your blog, I'll take a look. I realize that SWORD > is just a transfer protocol, and that the packaging formats are independent > of the protocol (in the same way that metadata formats are independent of > OAI-PMH), but I am trying to determine the degree to which the packing > formats are standardized. Specifically, I'm struggling to understand how a > client and a server can exchange content effectively in the packaging format > Foo (which they both agree via a protocol handshake is the format they are > exchanging) if they don't have a shared understanding of the internal > structure of the Foo format, or, more accurately, if the services behind the > client and the server don't understand the internal structure of Foo. > > So, I'm really asking about what happens before the SWORD client sends the > package off to the server, and what happens after the SWORD server hands the > transferred package off to the repository. If a publisher or other service > provider asks "Does your repository support SWORD?" I'd like to be able to > tell them, "Yes, in these formats that we all understand", instead of having > to explain to the publisher how I want the content packaged up, or take the > content in whatever format the publisher provides and figure out how to get > it into the target repository. > > Mark > > ----- Original Message ----- >> Hi Mark, >> >> I have been using SWORDv2 with DSpace. SWORD is just a transfer >> protocol, it doesn't really matter what type of package you send >> with it, as long as the receiving SWORD server understands how to >> handle it. >> >> I used DSpace METS SIP, simple zip files, and binary files because >> the DSpace SWORDv2 server implementation supported those packages. >> Then, we wanted to try BagIt, so I wrote a so called "ingester" to >> let the SWORDv2 DSpace server handle BagIt packages. And since I was >> at it, I also made one for DataBankBagIt packages, which are not in >> the SWORD documentation (and also have a different namespace, >> http://dataflow.ox.ac.uk/package/DataBankBagIt). You can define your >> own package format if you want to. >> >> You can read about our work on SWORD on the blog of our project, >> Sustainable Management of Digital Music Research Data: >> >> http://rdm.c4dm.eecs.qmul.ac.uk/sword-tools >> >> http://rdm.c4dm.eecs.qmul.ac.uk/datastage-and-dspace >> >> Good luck! >> Best regards >> Marco >> >> -------------------------------------------------- >> Marco Fabiani >> Postdoctoral Research Assistant >> Centre for Digital Music >> School of Electronic Engineering and Computer Science >> Queen Mary, University of London >> Mile End Road, London E1 4NS, UK >> >> On 23 May 2012, at 21:40, Mark Jordan wrote: >> >>> Hi, >>> >>> Sorry for this second n00b question to the list in less than a few >>> weeks. >>> >>> Is there any public documentation on SWORD2 packaging formats? The >>> profile uses the DSpace METS SIP and BagIt as examples. I assume >>> that the DSpace packaging format is the one described at >>> https://wiki.duraspace.org/display/DSPACE/DSpaceMETSSIPProfile, >>> but is this actually the case? Does a BagIt profile actually exist >>> or is it just used as an example? >>> >>> Our most immediate use case is that we am exploring using SWORD2 to >>> move theses from our thesis management system to our Drupal-based >>> IR. There is a SWORD1 server module for Drupal but not a SWORD2 >>> server. I'd like to make the SWORD2 server as generic as possible >>> in terms of deposit but am unclear on what the common packaging >>> formats are and how they are documented. >>> >>> Thanks, >>> >>> Mark >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Live Security Virtual Conference >>> Exclusive live event will cover all the ways today's security and >>> threat landscape has changed and how IT managers can respond. >>> Discussions >>> will include endpoint security, mobile security and the latest in >>> malware >>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>> _______________________________________________ >>> sword-app-tech mailing list >>> sword-app-tech@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/sword-app-tech >> > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > sword-app-tech mailing list > sword-app-tech@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sword-app-tech -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ sword-app-tech mailing list sword-app-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sword-app-tech
