sword-app-tech — Mailing list for discussion of SWORD implemenation and development.

Re: [sword-app-tech] Documentation on packaging formats

[Robin T. <rob...@ed...>]

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
>>> swo...@li...
>>> 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
> swo...@li...
> https://lists.sourceforge.net/lists/listinfo/sword-app-tech


-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

Re: [sword-app-tech] Documentation on packaging formats

[Marco F. <mar...@ee...>]

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
>>> swo...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sword-app-tech
>> 
>> 

Re: [sword-app-tech] Documentation on packaging formats

[Mark J. <mj...@sf...>]

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
> > swo...@li...
> > https://lists.sourceforge.net/lists/listinfo/sword-app-tech
> 
> 

Re: [sword-app-tech] Documentation on packaging formats

[Marco F. <mar...@ee...>]

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
> swo...@li...
> https://lists.sourceforge.net/lists/listinfo/sword-app-tech

[sword-app-tech] Documentation on packaging formats

[Mark J. <mj...@sf...>]

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

Re: [sword-app-tech] How does a client discover what metadata formats a SWORD 2.0 server accepts?

[Richard J. <ri...@co...>]

On 15 May 2012 20:56, Mark Jordan <mj...@sf...> wrote:
> Thanks Richard. Is the required format DCTERMS or the legacy, unqualified DC?

It support the full dcterms namespace.

>
> Mark
>
> ----- Original Message -----
>> Hi Mark
>>
>> On 15 May 2012 20:29, Mark Jordan <mj...@sf...> wrote:
>> > Hi,
>> >
>> > Sorry if this question has been documented somewhere (or discussed
>> > in the past) but I couldn't find an answer. How is a SWORD client
>> > supposed to know what metadata formats a SWORD 2.0 server accepts?
>> > I notice there is no mention of supported metadata formats in the
>> > service document; is it up to the packaging format to define what
>> > metadata formats are acceptable?
>>
>> Yes, SWORD doesn't have anything to say about metadata formats that
>> are supported - it is down to the package to define what formats are
>> acceptable.  Nonetheless, SWORDv2 servers are required to support
>> dublin core embedded in atom entry documents, for deposit operations
>> which entail the use of an entry document during deposit.
>>
>> Cheers,
>>
>> Richard
>>
>> >
>> > TIA,
>> >
>> > 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
>> > swo...@li...
>> > https://lists.sourceforge.net/lists/listinfo/sword-app-tech
>>
>>
>>
>> --
>>
>> Richard Jones,
>>
>> Founder, Cottage Labs
>> t: @richard_d_jones, @cottagelabs
>> w: http://cottagelabs.com
>>



-- 

Richard Jones,

Founder, Cottage Labs
t: @richard_d_jones, @cottagelabs
w: http://cottagelabs.com

Re: [sword-app-tech] How does a client discover what metadata formats a SWORD 2.0 server accepts?

[Mark J. <mj...@sf...>]

Thanks Richard. Is the required format DCTERMS or the legacy, unqualified DC?

Mark

----- Original Message -----
> Hi Mark
> 
> On 15 May 2012 20:29, Mark Jordan <mj...@sf...> wrote:
> > Hi,
> >
> > Sorry if this question has been documented somewhere (or discussed
> > in the past) but I couldn't find an answer. How is a SWORD client
> > supposed to know what metadata formats a SWORD 2.0 server accepts?
> > I notice there is no mention of supported metadata formats in the
> > service document; is it up to the packaging format to define what
> > metadata formats are acceptable?
> 
> Yes, SWORD doesn't have anything to say about metadata formats that
> are supported - it is down to the package to define what formats are
> acceptable.  Nonetheless, SWORDv2 servers are required to support
> dublin core embedded in atom entry documents, for deposit operations
> which entail the use of an entry document during deposit.
> 
> Cheers,
> 
> Richard
> 
> >
> > TIA,
> >
> > 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
> > swo...@li...
> > https://lists.sourceforge.net/lists/listinfo/sword-app-tech
> 
> 
> 
> --
> 
> Richard Jones,
> 
> Founder, Cottage Labs
> t: @richard_d_jones, @cottagelabs
> w: http://cottagelabs.com
> 

Re: [sword-app-tech] How does a client discover what metadata formats a SWORD 2.0 server accepts?

[Richard J. <ri...@co...>]

Hi Mark

On 15 May 2012 20:29, Mark Jordan <mj...@sf...> wrote:
> Hi,
>
> Sorry if this question has been documented somewhere (or discussed in the past) but I couldn't find an answer. How is a SWORD client supposed to know what metadata formats a SWORD 2.0 server accepts? I notice there is no mention of supported metadata formats in the service document; is it up to the packaging format to define what metadata formats are acceptable?

Yes, SWORD doesn't have anything to say about metadata formats that
are supported - it is down to the package to define what formats are
acceptable.  Nonetheless, SWORDv2 servers are required to support
dublin core embedded in atom entry documents, for deposit operations
which entail the use of an entry document during deposit.

Cheers,

Richard

>
> TIA,
>
> 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
> swo...@li...
> https://lists.sourceforge.net/lists/listinfo/sword-app-tech



-- 

Richard Jones,

Founder, Cottage Labs
t: @richard_d_jones, @cottagelabs
w: http://cottagelabs.com

[sword-app-tech] How does a client discover what metadata formats a SWORD 2.0 server accepts?

[Mark J. <mj...@sf...>]

Hi,

Sorry if this question has been documented somewhere (or discussed in the past) but I couldn't find an answer. How is a SWORD client supposed to know what metadata formats a SWORD 2.0 server accepts? I notice there is no mention of supported metadata formats in the service document; is it up to the packaging format to define what metadata formats are acceptable? 

TIA,

Mark

[sword-app-tech] FW: Managing Research Data Hack Days Event Report

[LEWIS S. <Stu...@ed...>]

In case you've not seen this, some excellent discussion about the use of SWORD with research data...



-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


-----Original Message-----
From: Research Data Management discussion list [mailto:RES...@JI...] On Behalf Of Mahendra Mahey
Sent: 11 May 2012 11:23
To: RES...@JI...
Subject: Managing Research Data Hack Days Event Report

Colleagues

DevCSI (http://devcsi.ukoln.ac.uk) and JISC recently ran a 'Managing Research Data Hack event' 
(http://devcsi.ukoln.ac.uk/past-events/mrd-hack-days/) on the 3-4 May in Manchester,2012.

The event report has now been published on the DevCSI blog:

http://devcsi.ukoln.ac.uk/2012/05/11/event-report-managing-research-data-hack-day/

Some highlights include:

- Considering the use of SWORD 2 and BitTorrent to deal with large datasets
- A proof-of-concept centralised service for tracking activity data around research projects and individual datasets
- User perspectives on metadata for datasets and examining a common schema to describe metadata for datasets

There are several multimedia interviews with attendees who talked about what they learned, discussed and worked on at the event.

We hope you find the blog report useful and please feel free to reply to it or contact me for further details. Please watch out for similar future follow up events in this area from DevCSI and JISC.

Thanks

----------------------------------------------
Mr Mahendra Mahey

Project Manager DevCSI
Research Officer
Innovation Support Centre
UKOLN
University of Bath,
Bath,
BA2 7AY

Mobile: ++44 (0) 07581069575
Fax: ++44 (0) 1225 386256

email: m....@uk...
skypeID: mr_mahendra_mahey
http://devcsi.ukoln.ac.uk/
http://cerify.ukoln.ac.uk/
http://www.ukoln.ac.uk
-----------------------------------------------

Re: [sword-app-tech] How to deposit items into DSpace Workspace using Sword v2

[Richard J. <ri...@co...>]

Hi Ling,

On 3 May 2012 14:28, Ling He <li...@yo...> wrote:
> Hi,
>
> I have been testing how to deposit items into DSpace Workspace using
> Sword2 for weeks. From my testing, SwordMETSContentIngester will direct
> ingest the package into archive and generate the external identifier, so
> if I want my items stay in workspace first, I can't really use mets
> ingester, right? I tested BinaryContentIngester and
> SimpleZipContentIngester, they can ingest the items into workspace, but
> only for the bitstream not metadata, so how can I put my metadata in? Do
> I need to write my own ingester and client to do it or any other
> existing ingesters I can use?

You have a couple of options:

1/ If you have a custom package format which contains your metadata
you need to write an ingester for it which will create DSpace Items
from your packaged content/metadata.  The METS ingester for SWORDv2 is
experimental, and I wouldn't use it.

2/ send your metadata separately, embedded in an Atom Entry.  If this
is dc metadata, the SimpleDCEntryIngester will suffice, otherwise
you'd need to write another entry ingester.

You can see which protocol operations are available to you by looking
at the spec, here:
http://swordapp.github.com/SWORDv2-Profile/SWORDProfile.html

Also, take a look at the swordv2-server.cfg in the
dspace/config/modules directory, which has some comments inline which
show how to use the plugins for content ingesters.

> And how can I move the items from
> workspace to archive, if later on the workspace item is approved to
> deposit into our DSpace permanently? Will every workspace item have to
> go through the DSpace submission workflow or is there a quick way to do it?

If the SWORD deposit comes with an In-Progress: false header, it will
automatically be injected into the workflow; the items then follow the
standard workflow/archive process for DSpace.  So when you are
finished depositing, just send a "complete" request (spec section 10 -
all of the clients support this I think).

Cheers,

Richard

>
> Thanks,
>
> --
> Ling He
> Digital Services Librarian
> York University Libraries
> Scott Library, 4700 Keele St. Room 105D, Toronto ON M3J 1P3
> Email: li...@yo...
> Phone: 416-736-2100 x20461
>
>
>
>
> ------------------------------------------------------------------------------
> 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
> swo...@li...
> https://lists.sourceforge.net/lists/listinfo/sword-app-tech



-- 

Richard Jones,

Founder, Cottage Labs
t: @richard_d_jones, @cottagelabs
w: http://cottagelabs.com

[sword-app-tech] How to deposit items into DSpace Workspace using Sword v2

[Ling He <li...@yo...>]

Hi,

I have been testing how to deposit items into DSpace Workspace using 
Sword2 for weeks. From my testing, SwordMETSContentIngester will direct 
ingest the package into archive and generate the external identifier, so 
if I want my items stay in workspace first, I can't really use mets 
ingester, right? I tested BinaryContentIngester and 
SimpleZipContentIngester, they can ingest the items into workspace, but 
only for the bitstream not metadata, so how can I put my metadata in? Do 
I need to write my own ingester and client to do it or any other 
existing ingesters I can use? And how can I move the items from 
workspace to archive, if later on the workspace item is approved to 
deposit into our DSpace permanently? Will every workspace item have to 
go through the DSpace submission workflow or is there a quick way to do it?

Thanks,

-- 
Ling He
Digital Services Librarian
York University Libraries
Scott Library, 4700 Keele St. Room 105D, Toronto ON M3J 1P3
Email: li...@yo...
Phone: 416-736-2100 x20461
 

Re: [sword-app-tech] old 1.3 code in svn - help needed!

[Richard J. <ri...@co...>]

Hi Mark,

Thanks for this, very helpful, comments inline ...


>> http://sword-app.svn.sourceforge.net/viewvc/sword-app/java-common/
>> Java common client and server code for 1.x.  This is pretty much
>> comprehensible, but there are a variety of nested tags/branches/trunk
>> structures, and without picking through the commit logs (and maybe not
>> even then) I'm not sure what's supposedly the operational tip of this
>> code.
>>
>
> This was originally the important stuff we need for DSpace, which I had
> runa pilot import to github here.
>
> https://github.com/swordapp/SWORDv1.1
>
> Which was also used to issue a SWORD 1.1 release to the maven central
> repository a few months ago when working on the dspace maven project
> consolidation. I validated that the code used in the release was the last
> stable revision that was used in other projects.
>
>
> http://search.maven.org/#artifactdetails%7Corg.swordapp%7Csword-common%7C1.1%7Cjar
>

Ok, fantastic, that's very helpful.  So, you are happy that the java-common
in the svn is superseded by the SWORDv1.1 in Github?  I've updated the name
of the SWORDv1.1 in github to SWORDv1-Common, to reflect this.


>
> Problem is, the DSpace AIP work altered features of this library and
> DSpace still maintains its own copy of the code here
>
>
> https://github.com/DSpace/DSpace/tree/master/dspace-sword/dspace-sword-api/src/main/java/org/purl/sword
>
> Ultimately, if those changes could be adopted by the 1.1 common project,
> DSpace could stop replicating this code and it would be back under the
> umbrella of swordapp.  But that introduces those changes to anyone else
> using the api (mostly switching from InputStreams to java Files and the
> mode of transferring the package into DSpace Packagers, point being, the
> temp file was already getting created earlier in the upload process)
>


>
> As I suggested earlier, it'd probably be easiest to pull each of these
> separate svn project structures in as separate git repositories, especially
> if some of the code is of questionable long term value.
>

Do you feel that the general applicability of the DSpace modifications is
in question?  We could tag the existing common code, and then branch, and
merge with the DSpace version, and tag that as being DSpace specific (or
more generally, using files instead of inputstreams); that would at least
alleviate DSpace of the burden of maintaining this code, and we could then
work towards a single common library which takes all use cases into account.

I would, in general, be very happy to merge the DSpace modifications into
the main library, as this would no doubt make everyone's lives slightly
simpler in the long run.

Cheers,

Richard


>
> Mark
>
> --
> [image: @mire Inc.]
> *Mark Diggory *(Schedule a Meeting <https://tungle.me/markdiggory>)
> *2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010*
> *Esperantolaan 4, Heverlee 3001, Belgium*
> http://www.atmire.com
>
>
>


-- 

Richard Jones,

Founder, Cottage Labs
t: @richard_d_jones, @cottagelabs
w: http://cottagelabs.com

Re: [sword-app-tech] SSS and sword2ruby now migrated to github

[LEWIS S. <Stu...@ed...>]

Hi Hayden,

Send me your github details off-list and we'll try and get this set up.  Ditto for anyone else.

Thanks,


Stuart



-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


-----Original Message-----
From: Hayden Young [mailto:hay...@wi...] 
Sent: 02 May 2012 21:25
To: swo...@li...
Subject: Re: [sword-app-tech] SSS and sword2ruby now migrated to github

Hi Stuart

> Also, if anyone would like commit rights on the PHP library, or to 
> send pull requests, please let me know and we'll get that sorted 
> (Hayden?)
yes please.

Cheers


Hayden

On 03/05/12 03:59, Richard Jones wrote:
> Hi Stuart,
>
> That's great.  I have now also done the specification:
>
> https://github.com/swordapp/SWORDv2-Profile
>
> And I've set up a github page for the profile, which gives us a nice 
> easy way to view it:
>
> http://swordapp.github.com/SWORDv2-Profile/SWORDProfile.html
>
> Cheers,
>
> Richard
>
> On 2 May 2012 19:57, LEWIS Stuart<Stu...@ed...>  wrote:
>> Hi all,
>>
>> The PHP v1 and v2 libraries have also now been migrated into the swordapp github organisation account:
>>
>>   - https://github.com/swordapp/swordapp-php-library
>>   - https://github.com/swordapp/swordappv2-php-library
>>
>> I also keep the EasyDeposit SWORD client creation toolkit in my personal github, but have no time to maintain this right now.  I'll happily move it into the swordapp account if others want to look after it.
>>
>> Also, if anyone would like commit rights on the PHP library, or to 
>> send pull requests, please let me know and we'll get that sorted 
>> (Hayden?)
>>
>> Thanks,
>>
>>
>> Stuart
>>
>>
>> --
>> The University of Edinburgh is a charitable body, registered in 
>> Scotland, with registration number SC005336.
>>
>>
>> -----Original Message-----
>> From: Richard Jones [mailto:ri...@co...]
>> Sent: 02 May 2012 16:47
>> To:<swo...@li...>
>> Subject: [sword-app-tech] SSS and sword2ruby now migrated to github
>>
>> Hi Folks,
>>
>> I have now migrated SSS from svn to github, and also forked the sword2ruby library to the swordapp organisation.
>>
>> https://github.com/swordapp/Simple-Sword-Server
>>
>> https://github.com/swordapp/sword2ruby
>>
>> I've also started setting up development team permissions, so if you think you should be in one of the teams but aren't please let me know.
>>
>> Cheers,
>>
>> Richard
>>
>> --
>>
>> Richard Jones,
>>
>> Founder, Cottage Labs
>> t: @richard_d_jones, @cottagelabs
>> w: http://cottagelabs.com
>>
>> ---------------------------------------------------------------------
>> ---------
>> 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
>> swo...@li...
>> 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
>> swo...@li...
>> https://lists.sourceforge.net/lists/listinfo/sword-app-tech
>
>

--
Hayden Young
Managing Director
Wijiti Pty Ltd
p. +61 (0) 08 6398 5010
e. hay...@wi...
w. www.wijiti.com
vcard. www.wijiti.com/vcard/haydenyoung.vcf

NOTICE
This e-mail and any attachments are intended for the addressee(s) only and may be confidential. They may contain legally privileged or copyright material. You should not read, copy, use or disclose them without authorization. If you are not the intended recipient please contact the sender as soon as possible by return e-mail and then please delete both messages. This notice should not be removed.


------------------------------------------------------------------------------
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
swo...@li...
https://lists.sourceforge.net/lists/listinfo/sword-app-tech

Re: [sword-app-tech] old 1.3 code in svn - help needed!

[Mark D. <mdi...@at...>]

On Wed, May 2, 2012 at 1:44 PM, Richard Jones <ri...@co...>wrote:

>
> http://sword-app.svn.sourceforge.net/viewvc/sword-app/java-common/
> Java common client and server code for 1.x.  This is pretty much
> comprehensible, but there are a variety of nested tags/branches/trunk
> structures, and without picking through the commit logs (and maybe not
> even then) I'm not sure what's supposedly the operational tip of this
> code.
>

This was originally the important stuff we need for DSpace, which I had
runa pilot import to github here.

https://github.com/swordapp/SWORDv1.1

Which was also used to issue a SWORD 1.1 release to the maven central
repository a few months ago when working on the dspace maven project
consolidation. I validated that the code used in the release was the last
stable revision that was used in other projects.

http://search.maven.org/#artifactdetails%7Corg.swordapp%7Csword-common%7C1.1%7Cjar

Problem is, the DSpace AIP work altered features of this library and DSpace
still maintains its own copy of the code here

https://github.com/DSpace/DSpace/tree/master/dspace-sword/dspace-sword-api/src/main/java/org/purl/sword

Ultimately, if those changes could be adopted by the 1.1 common project,
DSpace could stop replicating this code and it would be back under the
umbrella of swordapp.  But that introduces those changes to anyone else
using the api (mostly switching from InputStreams to java Files and the
mode of transferring the package into DSpace Packagers, point being, the
temp file was already getting created earlier in the upload process)

As I suggested earlier, it'd probably be easiest to pull each of these
separate svn project structures in as separate git repositories, especially
if some of the code is of questionable long term value.

Mark

-- 
[image: @mire Inc.]
*Mark Diggory *(Schedule a Meeting <https://tungle.me/markdiggory>)
*2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010*
*Esperantolaan 4, Heverlee 3001, Belgium*
http://www.atmire.com

[sword-app-tech] old 1.3 code in svn - help needed!

[Richard J. <ri...@co...>]

Hi Folks,

I'm just working my way through the old code in the sword svn, and was
wondering if anyone on-list can help me out with the status of some of
the parts of the svn which pertain to the 1.x release of sword:

http://sword-app.svn.sourceforge.net/viewvc/sword-app/client/
This appears to be a binary distribution of a client environment,
possibly wrapping the java-common library.  It seems that there's not
much in the way of actual new code in this directory, but if someone
knows more about it, would be great to know.

http://sword-app.svn.sourceforge.net/viewvc/sword-app/java-common/
Java common client and server code for 1.x.  This is pretty much
comprehensible, but there are a variety of nested tags/branches/trunk
structures, and without picking through the commit logs (and maybe not
even then) I'm not sure what's supposedly the operational tip of this
code.

http://sword-app.svn.sourceforge.net/viewvc/sword-app/java-webapp/
Not 100% sure what this is, but it also has a variety of nested
tags/branches/trunk structures, so difficult to work out what the
operational bit of the code is.

http://sword-app.svn.sourceforge.net/viewvc/sword-app/java-webvalidator/
Not looked hard at this yet, but is some kind of validator for the 1.3
spec.  It, again, has a variety of nested tags/branches/trunk
structures, so difficult to work out what the operational bit of the
code is.

Any tips by folks who have worked with this code would be much
appreciated.  It may be that the complexity involved in unpicking this
is not worth it, but am interested in people's opinion on whether this
should all be migrated to github.

Cheers,

Richard

-- 

Richard Jones,

Founder, Cottage Labs
t: @richard_d_jones, @cottagelabs
w: http://cottagelabs.com

Re: [sword-app-tech] SSS and sword2ruby now migrated to github

[Hayden Y. <hay...@wi...>]

Hi Stuart

> Also, if anyone would like commit rights on the PHP library, or to send pull requests, please let me know and we'll get that sorted (Hayden?)
yes please.

Cheers


Hayden

On 03/05/12 03:59, Richard Jones wrote:
> Hi Stuart,
>
> That's great.  I have now also done the specification:
>
> https://github.com/swordapp/SWORDv2-Profile
>
> And I've set up a github page for the profile, which gives us a nice
> easy way to view it:
>
> http://swordapp.github.com/SWORDv2-Profile/SWORDProfile.html
>
> Cheers,
>
> Richard
>
> On 2 May 2012 19:57, LEWIS Stuart<Stu...@ed...>  wrote:
>> Hi all,
>>
>> The PHP v1 and v2 libraries have also now been migrated into the swordapp github organisation account:
>>
>>   - https://github.com/swordapp/swordapp-php-library
>>   - https://github.com/swordapp/swordappv2-php-library
>>
>> I also keep the EasyDeposit SWORD client creation toolkit in my personal github, but have no time to maintain this right now.  I'll happily move it into the swordapp account if others want to look after it.
>>
>> Also, if anyone would like commit rights on the PHP library, or to send pull requests, please let me know and we'll get that sorted (Hayden?)
>>
>> Thanks,
>>
>>
>> Stuart
>>
>>
>> --
>> The University of Edinburgh is a charitable body, registered in
>> Scotland, with registration number SC005336.
>>
>>
>> -----Original Message-----
>> From: Richard Jones [mailto:ri...@co...]
>> Sent: 02 May 2012 16:47
>> To:<swo...@li...>
>> Subject: [sword-app-tech] SSS and sword2ruby now migrated to github
>>
>> Hi Folks,
>>
>> I have now migrated SSS from svn to github, and also forked the sword2ruby library to the swordapp organisation.
>>
>> https://github.com/swordapp/Simple-Sword-Server
>>
>> https://github.com/swordapp/sword2ruby
>>
>> I've also started setting up development team permissions, so if you think you should be in one of the teams but aren't please let me know.
>>
>> Cheers,
>>
>> Richard
>>
>> --
>>
>> Richard Jones,
>>
>> Founder, Cottage Labs
>> t: @richard_d_jones, @cottagelabs
>> w: http://cottagelabs.com
>>
>> ------------------------------------------------------------------------------
>> 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
>> swo...@li...
>> 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
>> swo...@li...
>> https://lists.sourceforge.net/lists/listinfo/sword-app-tech
>
>

-- 
Hayden Young
Managing Director
Wijiti Pty Ltd
p. +61 (0) 08 6398 5010
e. hay...@wi...
w. www.wijiti.com
vcard. www.wijiti.com/vcard/haydenyoung.vcf

NOTICE
This e-mail and any attachments are intended for the addressee(s) only and may be confidential. They may contain legally privileged or copyright material. You should not read, copy, use or disclose them without authorization. If you are not the intended recipient please contact the sender as soon as possible by return e-mail and then please delete both messages. This notice should not be removed.

Re: [sword-app-tech] SSS and sword2ruby now migrated to github

[Richard J. <ri...@co...>]

Hi Stuart,

That's great.  I have now also done the specification:

https://github.com/swordapp/SWORDv2-Profile

And I've set up a github page for the profile, which gives us a nice
easy way to view it:

http://swordapp.github.com/SWORDv2-Profile/SWORDProfile.html

Cheers,

Richard

On 2 May 2012 19:57, LEWIS Stuart <Stu...@ed...> wrote:
> Hi all,
>
> The PHP v1 and v2 libraries have also now been migrated into the swordapp github organisation account:
>
>  - https://github.com/swordapp/swordapp-php-library
>  - https://github.com/swordapp/swordappv2-php-library
>
> I also keep the EasyDeposit SWORD client creation toolkit in my personal github, but have no time to maintain this right now.  I'll happily move it into the swordapp account if others want to look after it.
>
> Also, if anyone would like commit rights on the PHP library, or to send pull requests, please let me know and we'll get that sorted (Hayden?)
>
> Thanks,
>
>
> Stuart
>
>
> --
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
>
> -----Original Message-----
> From: Richard Jones [mailto:ri...@co...]
> Sent: 02 May 2012 16:47
> To: <swo...@li...>
> Subject: [sword-app-tech] SSS and sword2ruby now migrated to github
>
> Hi Folks,
>
> I have now migrated SSS from svn to github, and also forked the sword2ruby library to the swordapp organisation.
>
> https://github.com/swordapp/Simple-Sword-Server
>
> https://github.com/swordapp/sword2ruby
>
> I've also started setting up development team permissions, so if you think you should be in one of the teams but aren't please let me know.
>
> Cheers,
>
> Richard
>
> --
>
> Richard Jones,
>
> Founder, Cottage Labs
> t: @richard_d_jones, @cottagelabs
> w: http://cottagelabs.com
>
> ------------------------------------------------------------------------------
> 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
> swo...@li...
> 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
> swo...@li...
> https://lists.sourceforge.net/lists/listinfo/sword-app-tech



-- 

Richard Jones,

Founder, Cottage Labs
t: @richard_d_jones, @cottagelabs
w: http://cottagelabs.com

Re: [sword-app-tech] SSS and sword2ruby now migrated to github

[LEWIS S. <Stu...@ed...>]

Hi all,

The PHP v1 and v2 libraries have also now been migrated into the swordapp github organisation account:

 - https://github.com/swordapp/swordapp-php-library
 - https://github.com/swordapp/swordappv2-php-library

I also keep the EasyDeposit SWORD client creation toolkit in my personal github, but have no time to maintain this right now.  I'll happily move it into the swordapp account if others want to look after it.

Also, if anyone would like commit rights on the PHP library, or to send pull requests, please let me know and we'll get that sorted (Hayden?)

Thanks,


Stuart


-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


-----Original Message-----
From: Richard Jones [mailto:ri...@co...] 
Sent: 02 May 2012 16:47
To: <swo...@li...>
Subject: [sword-app-tech] SSS and sword2ruby now migrated to github

Hi Folks,

I have now migrated SSS from svn to github, and also forked the sword2ruby library to the swordapp organisation.

https://github.com/swordapp/Simple-Sword-Server

https://github.com/swordapp/sword2ruby

I've also started setting up development team permissions, so if you think you should be in one of the teams but aren't please let me know.

Cheers,

Richard

-- 

Richard Jones,

Founder, Cottage Labs
t: @richard_d_jones, @cottagelabs
w: http://cottagelabs.com

------------------------------------------------------------------------------
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
swo...@li...
https://lists.sourceforge.net/lists/listinfo/sword-app-tech

Re: [sword-app-tech] depositMultipart always results in a 500 error

[Hayden Y. <hay...@wi...>]

Hi Stuart

I've reviewed the sword spec you sent through. It seems that the spec 
RECOMMENDS a deposit receipt is returned but doesn't REQUIRE it. Even 
the status code is not mandatory (provided I'm reading the spec 
correctly. The spec goes on to say " The server MAY, though, return any 
response which it feels appropriate" so it seems DSpace is returning the 
bare minimum of what is recommended (I.e. a 201 Created).

Based on this information, I've gone ahead and changed my code to return 
the "raw" result if no response XML is returned, which will stop an 
exception being thrown by SimpleXmlElement when the XML response is empty.

E.g.

             try {
                 if ($sac_resp) {
                     // Get the deposit results
                     $sac_xml = @new SimpleXMLElement($sac_resp);
                     $sac_ns = $sac_xml->getNamespaces(true);

                     // Build the deposit response object
                     $sac_dresponse->buildhierarchy($sac_xml, $sac_ns);
                 }
             } catch (Exception $e) {
                 throw new Exception("Error parsing response entry (" . 
$e->getMessage() . ")");
             }

I've also made some minor modifications to the Sword PHP client so that 
it can be installed as a Joomla! library. Let me know if you would like 
me to send this through to you.

Cheers


Hayden

On 02/05/12 03:36, LEWIS Stuart wrote:
> Hi Hayden,
>
> Thanks for persisting with this - it's great to hear about the positive outcome.  Unfortunately I've not got a working copy of DSpace / SWORD on my PC since changing jobs.  If you're able to debug the PHP client's parsing of the result, that would be great.  The spec doesn't specify the response should be - it may be that no xml is returned, so the build hierarchy code may not be needed.  I don't know what DSpace does in this respect.
>
> http://sword-app.svn.sourceforge.net/viewvc/sword-app/spec/tags/sword-2.0/SWORDProfile.html?revision=377#protocoloperations_addingcontent_mediaresource
>
> Thanks,
>
>
> Stuart
>
>
>
>

-- 
Hayden Young
Managing Director
Wijiti Pty Ltd
p. +61 (0) 08 6398 5010
e. hay...@wi...
w. www.wijiti.com
vcard. www.wijiti.com/vcard/haydenyoung.vcf

NOTICE
This e-mail and any attachments are intended for the addressee(s) only and may be confidential. They may contain legally privileged or copyright material. You should not read, copy, use or disclose them without authorization. If you are not the intended recipient please contact the sender as soon as possible by return e-mail and then please delete both messages. This notice should not be removed.

[sword-app-tech] SSS and sword2ruby now migrated to github

[Richard J. <ri...@co...>]

Hi Folks,

I have now migrated SSS from svn to github, and also forked the
sword2ruby library to the swordapp organisation.

https://github.com/swordapp/Simple-Sword-Server

https://github.com/swordapp/sword2ruby

I've also started setting up development team permissions, so if you
think you should be in one of the teams but aren't please let me know.

Cheers,

Richard

-- 

Richard Jones,

Founder, Cottage Labs
t: @richard_d_jones, @cottagelabs
w: http://cottagelabs.com

Re: [sword-app-tech] Error from DSpace server

[Marco F. <mar...@ee...>]

Hi Richard,


> Are you using the standard DSpace swordv2 or my stabilised
> implementation at https://github.com/nye-duo/DSpace/tree/duo

I am not sure, I will download the latest stabilised implementation and try again!

Cheers
Marco

Re: [sword-app-tech] Error from DSpace server

[Richard J. <ri...@co...>]

Hi Marco,

On 2 May 2012 14:38, Marco Fabiani <mar...@ee...> wrote:
> Hello,
>
> while trying to get DataFlow/DataStage talk to DSpace, I found a possible bug in the DSpace sword2 server (NullPointer exception).
>
> When I update an item using for example (python):
>
> deposit_receipt = c.update(edit_media_iri = new_receipt.edit_media,
>                                                payload = payload,
>                                                filename = filename,
>                                                mimetype = 'application/zip',
>                                                packaging = packaging,
>                                                in_progress = True)
>
> the update is successfully carried out in DSpace (the files are deleted and new files are added), but the server returns a 500 error:
>
> <u>The server encountered an internal error () that prevented it from fulfilling this request.</u></p><p><b>exception</b> <pre>java.lang.NullPointerException
>        org.swordapp.server.MediaResourceAPI.put(MediaResourceAPI.java:174)
>        org.swordapp.server.servlets.MediaResourceServletDefault.doPut(MediaResourceServletDefault.java:56)
>        javax.servlet.http.HttpServlet.service(HttpServlet.java:640)
>        javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>
> I couldn't find out why this happens, maybe you have an idea?

Are you using the standard DSpace swordv2 or my stabilised
implementation at https://github.com/nye-duo/DSpace/tree/duo

The latter fixes a lot of issues in the implementation, and i'll be
seeing if we can merge some of that back into the master at some point
soon.

Cheers,

Richard

>
> Cheers,
>
> 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
>
>
> ------------------------------------------------------------------------------
> 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
> swo...@li...
> https://lists.sourceforge.net/lists/listinfo/sword-app-tech



-- 

Richard Jones,

Founder, Cottage Labs
t: @richard_d_jones, @cottagelabs
w: http://cottagelabs.com

[sword-app-tech] Error from DSpace server

[Marco F. <mar...@ee...>]

Hello,

while trying to get DataFlow/DataStage talk to DSpace, I found a possible bug in the DSpace sword2 server (NullPointer exception).

When I update an item using for example (python):

deposit_receipt = c.update(edit_media_iri = new_receipt.edit_media,
						payload = payload,
						filename = filename,
						mimetype = 'application/zip',
						packaging = packaging,
						in_progress = True)

the update is successfully carried out in DSpace (the files are deleted and new files are added), but the server returns a 500 error:

<u>The server encountered an internal error () that prevented it from fulfilling this request.</u></p><p><b>exception</b> <pre>java.lang.NullPointerException
	org.swordapp.server.MediaResourceAPI.put(MediaResourceAPI.java:174)
	org.swordapp.server.servlets.MediaResourceServletDefault.doPut(MediaResourceServletDefault.java:56)
	javax.servlet.http.HttpServlet.service(HttpServlet.java:640)
	javax.servlet.http.HttpServlet.service(HttpServlet.java:717)

I couldn't find out why this happens, maybe you have an idea?

Cheers,

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

[sword-app-tech] java server library migrated to github

[Richard J. <ri...@co...>]

Hi Folks,

I have now migrated the java server library to github too:

https://github.com/swordapp/JavaServer2.0

I know this is taking some time to migrate, but we'll soon be there.

Also, do we want to migrate all the 1.x code (the client has already
been done by Mark)?

Cheers,

Richard

-- 

Richard Jones,

Founder, Cottage Labs
t: @richard_d_jones, @cottagelabs
w: http://cottagelabs.com