Re: [sword-app-tech] Documentation
Hi Florian, Just to +1 what Ralf said: the swordapp.org website is the best place to start for resources. Depending on what version of the spec you are after, you may find these two pages in particular useful: SWORDv1: http://swordapp.org/sword-v1/the-specification/ SWORDv2: http://swordapp.org/sword-v2/sword-v2-specifications/ There is also some information about the upcoming version that we are working on right now, here: http://swordapp.org/swordv3/ Hope that helps. All the best, Richard On 4 January 2018 at 08:21, Ralf Claussnitzer < ralf.claussnit...@slub-dresden.de> wrote: > Hi Florian, > > you may want to check out http://swordapp.org/ > > Regards, > Ralf > > On 12/31/2017 10:22 AM, Florian Wille wrote: > > Hello List, > I am looking for some Documentation for the SWORD Protocol where there ist > described which commands exist, how to issue them and what kind of answers > to expect, something like: > https://www.openarchives.org/OAI/openarchivesprotocol.html > only for SWORD maybe not in that depths but like it... > Could someone point me to the right direction I can't seem to find > something usefull to me in that manner. > Kind Regards and > best wishes for the upcoming year > Florian > > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > ___ > sword-app-tech mailing > listsword-app-tech@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/sword-app-tech > > > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > sword-app-tech mailing list > sword-app-tech@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sword-app-tech > > -- Richard Jones, Founder, Cottage Labs https://cottagelabs.com || @cottagelabs Lantern: https://lantern.cottagelabs.com Repository Solutions: https://cottagelabs.com/repository -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ sword-app-tech mailing list sword-app-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sword-app-tech
Re: [sword-app-tech] Documentation
Hi Florian, you may want to check out http://swordapp.org/ Regards, Ralf On 12/31/2017 10:22 AM, Florian Wille wrote: Hello List, I am looking for some Documentation for the SWORD Protocol where there ist described which commands exist, how to issue them and what kind of answers to expect, something like: https://www.openarchives.org/OAI/openarchivesprotocol.html only for SWORD maybe not in that depths but like it... Could someone point me to the right direction I can't seem to find something usefull to me in that manner. Kind Regards and best wishes for the upcoming year Florian -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ sword-app-tech mailing list sword-app-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sword-app-tech -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ sword-app-tech mailing list sword-app-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sword-app-tech
Re: [sword-app-tech] Documentation on packaging formats
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
Re: [sword-app-tech] Documentation on packaging formats
Hi Mark, 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. The package formats supported/accepted by the Server are listed in the Service Document provided by the server when a client first connects to it. If the client sends an unsupported package type, the server should reply with an error message stating that the that package type is not supported. Deciding which packages to support and creating packages that comply with the standards is the real problem I think. For example, I think the only way to reliably create DSpace METS SIP files is via the export function in DSpace. As for BagIt, I used the Bagger utility provided by the Library of Congress: http://sourceforge.net/projects/loc-xferutils/files/loc-bagger/ and built my DSpace ingester according to the BagIt specifications. I hope this helps! Marco - 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
Re: [sword-app-tech] Documentation on packaging formats
Hi Mark, Sorry, I had misunderstood. Something like the DSpaceMetsProfile should be sufficiently detailed that if a server says it supports it the client should know what to send. However, in my opinion, the practice hasn't matched the theory. The DSpaceMetsProfile expects the metadata to be Mods, but much of the initial development work for Sword was done using the Eprints DC application profile (SWAP). So, typically, an ePrints repository that says it supports the DSpaceMetsProfile will expect the metadata to conform to the SWAP standard, rather than Mods. If you send it Mods the metadata will disappear down a black hole. I don't mean to pick on ePrints, its just one discrepancy that I happen to know. I agree there is a gap there, we need more and better package standards and profiles and the Sword servers need to support them accurately. Cheers, Robin. On 24/05/12 16:10, Mark Jordan wrote: Hi Robin, I understand the protocol, it's very clear, but what I am asking is, is there a list somewhere of package formats, and their internal structures (e.g., what metadata formats are allowed, how are relationships between multipart objects like a thesis and its two supplemental files described, etc.). Marco used BagIt as an example, and my own institution would use BagIt as a way of moving groups of related files around and storing them together, but, to draw a parallel between SWORD and BagIt, both are just containers that are agnostic to the payloads they carry. METS is the same. Tools that define the container only handle half the process of data exchange; what we need are a set of profiles or other ways of specifying the details of how the payload is structured so that once it is removed from the container, other applications know how to reassemble it. If such a list or registry doesn't exist, would there be interest in starting one, and describing the packaging formats the community is using (and willing to share) in a standardized way, as is done with METS profiles or DC application profiles? Mark - Original Message - 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
