Menu
▾
▴
sword-app-tech — Mailing list for discussion of SWORD implemenation and development.
You can subscribe to this list here.
| 2008 |
Jan
(22) |
Feb
(8) |
Mar
(9) |
Apr
(4) |
May
(17) |
Jun
(29) |
Jul
(11) |
Aug
(13) |
Sep
(17) |
Oct
(14) |
Nov
(41) |
Dec
(8) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
(17) |
Feb
(26) |
Mar
(18) |
Apr
(1) |
May
(11) |
Jun
(20) |
Jul
(5) |
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
|
| 2010 |
Jan
(23) |
Feb
(7) |
Mar
(9) |
Apr
(13) |
May
(5) |
Jun
|
Jul
(3) |
Aug
(5) |
Sep
|
Oct
(1) |
Nov
(3) |
Dec
|
| 2011 |
Jan
(3) |
Feb
|
Mar
(2) |
Apr
(1) |
May
|
Jun
(14) |
Jul
(22) |
Aug
(1) |
Sep
(2) |
Oct
(11) |
Nov
(11) |
Dec
(35) |
| 2012 |
Jan
(17) |
Feb
(12) |
Mar
(41) |
Apr
(40) |
May
(41) |
Jun
(27) |
Jul
(9) |
Aug
(1) |
Sep
|
Oct
(6) |
Nov
|
Dec
(11) |
| 2013 |
Jan
|
Feb
(4) |
Mar
(2) |
Apr
(8) |
May
(1) |
Jun
(18) |
Jul
(10) |
Aug
(16) |
Sep
(2) |
Oct
(1) |
Nov
(14) |
Dec
(11) |
| 2014 |
Jan
(7) |
Feb
(2) |
Mar
|
Apr
|
May
(8) |
Jun
(1) |
Jul
(7) |
Aug
(10) |
Sep
(8) |
Oct
(8) |
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
(2) |
Mar
(2) |
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(4) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(6) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
(4) |
| 2018 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Mark D. <mdi...@at...> - 2012-03-29 16:43:36
|
P.S. Thank Tim Donohue for all this excellent AIP work. I'm just the messenger. On Thu, Mar 29, 2012 at 9:42 AM, Mark Diggory <mdi...@at...> wrote: > The AIP is a zip package with a much more detailed METS manifest than the > METSDSpaceSIP. For further details see: > > http://www.dspace.org/1_7_1Documentation/DSpace%20AIP%20Format.html > > Likewise, you will be able to capture your Community/Collection hierarchy > as Fedora Objects as well. > > So, hypothetically, based upon the observations Glen has made, by its > nature you should be able to import it into Fedora's SWORD interface. > > It will be a very intriguing test to see the outcome of this import > process. > > Regards, > Mark > > On Thu, Mar 29, 2012 at 9:22 AM, Glen Robson <gle...@ll...>wrote: > >> Hi Robin and Ying, >> >> I've just looked through the sword-fedora implementation (for SWORD >> version 1.2) and it looks like if you submit the mime-type as text/xml and >> the packaging as 'http://www.loc.gov/METS/' it will extract any METS >> dmdSecs and store them as Fedora datastreams then go through the file >> section and add those as datastreams to an object in Fedora. I'm not sure >> how that would look in Islandora but if you have a METS document containing >> MODS and links to files you should get them pulled into a Fedora object. >> >> When I developed the METS handler for Fedora SWORD it was meant to handle >> a generic METS documents rather than any specific profile but I'm afraid I >> don't know much about the METSDSpaceSIP so I'm not quite sure whats missing. >> >> Hope that helps. >> >> Glen >> >> On 29 Mar 2012, at 15:56, Robin Taylor wrote: >> > Hi Ying, >> > >> > So the fact that the ServiceDocument contains... >> > >> > <sword:acceptPackaging q="0.9"> >> http://purl.org/net/sword-types/METSDSpaceSIP</sword:acceptPackaging> >> > >> > ...means that in theory it should be happy with a Mets package with Mods >> > metadata. In practice I'll bet that the Fedora Sword implementation >> > expects SWAP metadata. I don't know if there are any Fedora experts >> > listening in who could confirm ? >> > >> > However, Mark makes a good point that SWORD may not be the best vehicle >> > for a bulk transfer of data. You might be best to find out what tools >> > Fedora has for bulk import and aim to export and transform your DSpace >> > data into the required format. >> > >> > Cheers, Robin. >> > >> > >> > >> > On 28/03/12 15:47, Ying Jin wrote: >> >> Hi Robin, >> >> >> >> Thanks for your reply. Here is the service document. I am running >> >> SWORD-Fedora 1.2 - >> >> >> >> = >> >> = >> >> = >> >> = >> >> = >> >> = >> >> = >> >> = >> >> = >> >> = >> >> = >> >> = >> >> = >> >> = >> >> = >> >> = >> >> = >> >> = >> >> = >> >> = >> >> = >> >> = >> >> = >> >> = >> >> = >> >> = >> >> = >> >> >> ======================================================================== >> >> <?xml version="1.0" encoding="UTF-8"?> >> >> <app:service xmlns:atom="http://www.w3.org/2005/Atom" xmlns:app=" >> http://www.w3.org/2007/app >> >> " xmlns:sword="http://purl.org/net/sword/" xmlns:dcterms=" >> http://purl.org/dc/terms/ >> >> "> >> >> <sword:version>1.3</sword:version> >> >> <sword:verbose>true</sword:verbose> >> >> <sword:noOp>true</sword:noOp> >> >> <app:workspace> >> >> <atom:title type="text">Fedora SWORD Workspace</atom:title> >> >> <app:collection href="http://localhost:8080/sword/ >> >> collection:open"> >> >> <atom:title type="text">Open Collection</atom:title> >> >> <app:accept>text/xml</app:accept> >> >> <app:accept>application/zip</app:accept> >> >> <app:accept>application/x-zip-compressed</app:accept> >> >> <app:accept>application/atom+xml</app:accept> >> >> <app:accept>image/gif</app:accept> >> >> <app:accept>image/jpeg</app:accept> >> >> <app:accept>image/jpg</app:accept> >> >> <app:accept>application/pdf</app:accept> >> >> <sword:acceptPackaging q="0.9"> >> http://purl.org/net/sword-types/METSDSpaceSIP >> >> </sword:acceptPackaging> >> >> <sword:acceptPackaging q="0.9">http://www.loc.gov/METS/</ >> >> sword:acceptPackaging> >> >> <sword:collectionPolicy>This collection accepts any deposit >> >> from anyone</sword:collectionPolicy> >> >> <dcterms:abstract>This is a collection of objects which can >> >> be freely deposited to. This is aviable for the SWORD test project</ >> >> dcterms:abstract> >> >> <sword:mediation>true</sword:mediation> >> >> <sword:treatment>Preservation actions may occur on submited >> >> deposits</sword:treatment> >> >> </app:collection> >> >> <app:collection href=" >> http://localhost:8080/sword/geography-collection >> >> "> >> >> <atom:title type="text">Geography Collection</atom:title> >> >> <app:accept>application/zip</app:accept> >> >> <sword:acceptPackaging q="0.9"> >> http://purl.org/net/sword-types/METSDSpaceSIP >> >> </sword:acceptPackaging> >> >> <sword:collectionPolicy>This collection accepts any deposit >> >> </sword:collectionPolicy> >> >> <dcterms:abstract>This is a nested collection of geography >> >> objects</dcterms:abstract> >> >> <sword:service> >> http://localhost:8080/sword/servicedocument/geography.xml >> >> </sword:service> >> >> <sword:mediation>true</sword:mediation> >> >> <sword:treatment>Preservation actions may occur on submited >> >> deposits</sword:treatment> >> >> </app:collection> >> >> </app:workspace> >> >> </app:service> >> >> >> >> = >> >> = >> >> = >> >> = >> >> = >> >> = >> >> = >> >> = >> >> = >> >> = >> >> = >> >> = >> >> = >> >> = >> >> = >> >> = >> >> = >> >> = >> >> = >> >> = >> >> = >> >> = >> >> = >> >> = >> >> = >> >> = >> >> = >> >> >> ======================================================================== >> >> >> >> It shows METSDSpaceSIP as accepting package. However, it doesn't work. >> >> >> >> Best, >> >> Ying >> >> >> >> On Mar 28, 2012, at 4:35 AM, Robin Taylor wrote: >> >> >> >>> Hi Ying, >> >>> >> >>> If you send a request to the Fedora Sword Server for a Sword >> >>> ServiceDocument it should tell you what package formats it supports. >> >>> Would it be possible to do so and post the results here ? >> >>> >> >>> Thanks, Robin. >> >>> >> >>> >> >>> On 27/03/12 21:22, Ying Jin wrote: >> >>>> Hi, >> >>>> >> >>>> I'm working on our DSpace repository and trying to migrate items from >> >>>> DSpace to Fedora (we are going to use Islandora). It looks like SWORD >> >>>> might be a good approach. Here is the question from my testing >> >>>> migration - >> >>>> >> >>>> I exported an item using DSpace packager in METS format, and then use >> >>>> Fedora Sword module to import the item to Fedora. >> >>>> >> >>>> First, I used METSDSpaceSIP packaging, and the ingested item shows a >> >>>> zip file only. >> >>>> Then I tried METS packaging and only content files are uploaded. >> >>>> Obviously, it can't understand dspace mets. >> >>>> >> >>>> I think METSDSpaceSIP packaging is the right way to go but it doesn't >> >>>> seem to work properly. Is there anything I may need to setup for >> >>>> having this work? >> >>>> >> >>>> Thanks any suggestions and helps, >> >>>> Ying >> >>>> >> >>>> ------------------- >> >>>> CDS@Rice University >> >>>> >> >>>> >> ------------------------------------------------------------------------------ >> >>>> This SF email is sponsosred by: >> >>>> Try Windows Azure free for 90 days Click Here >> >>>> http://p.sf.net/sfu/sfd2d-msazure >> >>>> _______________________________________________ >> >>>> 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. >> >>> >> >>> >> >>> >> ------------------------------------------------------------------------------ >> >>> This SF email is sponsosred by: >> >>> Try Windows Azure free for 90 days Click Here >> >>> http://p.sf.net/sfu/sfd2d-msazure >> >>> _______________________________________________ >> >>> 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. >> > >> > >> > >> ------------------------------------------------------------------------------ >> > This SF email is sponsosred by: >> > Try Windows Azure free for 90 days Click Here >> > http://p.sf.net/sfu/sfd2d-msazure >> > _______________________________________________ >> > sword-app-tech mailing list >> > swo...@li... >> > https://lists.sourceforge.net/lists/listinfo/sword-app-tech >> >> >> >> ------------------------------------------------------------------------------ >> This SF email is sponsosred by: >> Try Windows Azure free for 90 days Click Here >> http://p.sf.net/sfu/sfd2d-msazure >> _______________________________________________ >> sword-app-tech mailing list >> swo...@li... >> https://lists.sourceforge.net/lists/listinfo/sword-app-tech >> > > > > -- > [image: @mire Inc.] > *Mark Diggory *(Schedule a Meeting<https://www.google.com/calendar/selfsched?sstoken=UUdDSzJzTTlOUE1mfGRlZmF1bHR8MzgwMmEwYjk1NDc1NDQ1MGI0NWViYjYzZjExZDI3Mzg> > ) > *2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010* > *Esperantolaan 4, Heverlee 3001, Belgium* > http://www.atmire.com > > > -- [image: @mire Inc.] *Mark Diggory *(Schedule a Meeting<https://www.google.com/calendar/selfsched?sstoken=UUdDSzJzTTlOUE1mfGRlZmF1bHR8MzgwMmEwYjk1NDc1NDQ1MGI0NWViYjYzZjExZDI3Mzg> ) *2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010* *Esperantolaan 4, Heverlee 3001, Belgium* http://www.atmire.com |
|
From: Mark D. <mdi...@at...> - 2012-03-29 16:42:20
|
The AIP is a zip package with a much more detailed METS manifest than the METSDSpaceSIP. For further details see: http://www.dspace.org/1_7_1Documentation/DSpace%20AIP%20Format.html Likewise, you will be able to capture your Community/Collection hierarchy as Fedora Objects as well. So, hypothetically, based upon the observations Glen has made, by its nature you should be able to import it into Fedora's SWORD interface. It will be a very intriguing test to see the outcome of this import process. Regards, Mark On Thu, Mar 29, 2012 at 9:22 AM, Glen Robson <gle...@ll...>wrote: > Hi Robin and Ying, > > I've just looked through the sword-fedora implementation (for SWORD > version 1.2) and it looks like if you submit the mime-type as text/xml and > the packaging as 'http://www.loc.gov/METS/' it will extract any METS > dmdSecs and store them as Fedora datastreams then go through the file > section and add those as datastreams to an object in Fedora. I'm not sure > how that would look in Islandora but if you have a METS document containing > MODS and links to files you should get them pulled into a Fedora object. > > When I developed the METS handler for Fedora SWORD it was meant to handle > a generic METS documents rather than any specific profile but I'm afraid I > don't know much about the METSDSpaceSIP so I'm not quite sure whats missing. > > Hope that helps. > > Glen > > On 29 Mar 2012, at 15:56, Robin Taylor wrote: > > Hi Ying, > > > > So the fact that the ServiceDocument contains... > > > > <sword:acceptPackaging q="0.9"> > http://purl.org/net/sword-types/METSDSpaceSIP</sword:acceptPackaging> > > > > ...means that in theory it should be happy with a Mets package with Mods > > metadata. In practice I'll bet that the Fedora Sword implementation > > expects SWAP metadata. I don't know if there are any Fedora experts > > listening in who could confirm ? > > > > However, Mark makes a good point that SWORD may not be the best vehicle > > for a bulk transfer of data. You might be best to find out what tools > > Fedora has for bulk import and aim to export and transform your DSpace > > data into the required format. > > > > Cheers, Robin. > > > > > > > > On 28/03/12 15:47, Ying Jin wrote: > >> Hi Robin, > >> > >> Thanks for your reply. Here is the service document. I am running > >> SWORD-Fedora 1.2 - > >> > >> = > >> = > >> = > >> = > >> = > >> = > >> = > >> = > >> = > >> = > >> = > >> = > >> = > >> = > >> = > >> = > >> = > >> = > >> = > >> = > >> = > >> = > >> = > >> = > >> = > >> = > >> = > >> ======================================================================== > >> <?xml version="1.0" encoding="UTF-8"?> > >> <app:service xmlns:atom="http://www.w3.org/2005/Atom" xmlns:app=" > http://www.w3.org/2007/app > >> " xmlns:sword="http://purl.org/net/sword/" xmlns:dcterms=" > http://purl.org/dc/terms/ > >> "> > >> <sword:version>1.3</sword:version> > >> <sword:verbose>true</sword:verbose> > >> <sword:noOp>true</sword:noOp> > >> <app:workspace> > >> <atom:title type="text">Fedora SWORD Workspace</atom:title> > >> <app:collection href="http://localhost:8080/sword/ > >> collection:open"> > >> <atom:title type="text">Open Collection</atom:title> > >> <app:accept>text/xml</app:accept> > >> <app:accept>application/zip</app:accept> > >> <app:accept>application/x-zip-compressed</app:accept> > >> <app:accept>application/atom+xml</app:accept> > >> <app:accept>image/gif</app:accept> > >> <app:accept>image/jpeg</app:accept> > >> <app:accept>image/jpg</app:accept> > >> <app:accept>application/pdf</app:accept> > >> <sword:acceptPackaging q="0.9"> > http://purl.org/net/sword-types/METSDSpaceSIP > >> </sword:acceptPackaging> > >> <sword:acceptPackaging q="0.9">http://www.loc.gov/METS/</ > >> sword:acceptPackaging> > >> <sword:collectionPolicy>This collection accepts any deposit > >> from anyone</sword:collectionPolicy> > >> <dcterms:abstract>This is a collection of objects which can > >> be freely deposited to. This is aviable for the SWORD test project</ > >> dcterms:abstract> > >> <sword:mediation>true</sword:mediation> > >> <sword:treatment>Preservation actions may occur on submited > >> deposits</sword:treatment> > >> </app:collection> > >> <app:collection href=" > http://localhost:8080/sword/geography-collection > >> "> > >> <atom:title type="text">Geography Collection</atom:title> > >> <app:accept>application/zip</app:accept> > >> <sword:acceptPackaging q="0.9"> > http://purl.org/net/sword-types/METSDSpaceSIP > >> </sword:acceptPackaging> > >> <sword:collectionPolicy>This collection accepts any deposit > >> </sword:collectionPolicy> > >> <dcterms:abstract>This is a nested collection of geography > >> objects</dcterms:abstract> > >> <sword:service> > http://localhost:8080/sword/servicedocument/geography.xml > >> </sword:service> > >> <sword:mediation>true</sword:mediation> > >> <sword:treatment>Preservation actions may occur on submited > >> deposits</sword:treatment> > >> </app:collection> > >> </app:workspace> > >> </app:service> > >> > >> = > >> = > >> = > >> = > >> = > >> = > >> = > >> = > >> = > >> = > >> = > >> = > >> = > >> = > >> = > >> = > >> = > >> = > >> = > >> = > >> = > >> = > >> = > >> = > >> = > >> = > >> = > >> ======================================================================== > >> > >> It shows METSDSpaceSIP as accepting package. However, it doesn't work. > >> > >> Best, > >> Ying > >> > >> On Mar 28, 2012, at 4:35 AM, Robin Taylor wrote: > >> > >>> Hi Ying, > >>> > >>> If you send a request to the Fedora Sword Server for a Sword > >>> ServiceDocument it should tell you what package formats it supports. > >>> Would it be possible to do so and post the results here ? > >>> > >>> Thanks, Robin. > >>> > >>> > >>> On 27/03/12 21:22, Ying Jin wrote: > >>>> Hi, > >>>> > >>>> I'm working on our DSpace repository and trying to migrate items from > >>>> DSpace to Fedora (we are going to use Islandora). It looks like SWORD > >>>> might be a good approach. Here is the question from my testing > >>>> migration - > >>>> > >>>> I exported an item using DSpace packager in METS format, and then use > >>>> Fedora Sword module to import the item to Fedora. > >>>> > >>>> First, I used METSDSpaceSIP packaging, and the ingested item shows a > >>>> zip file only. > >>>> Then I tried METS packaging and only content files are uploaded. > >>>> Obviously, it can't understand dspace mets. > >>>> > >>>> I think METSDSpaceSIP packaging is the right way to go but it doesn't > >>>> seem to work properly. Is there anything I may need to setup for > >>>> having this work? > >>>> > >>>> Thanks any suggestions and helps, > >>>> Ying > >>>> > >>>> ------------------- > >>>> CDS@Rice University > >>>> > >>>> > ------------------------------------------------------------------------------ > >>>> This SF email is sponsosred by: > >>>> Try Windows Azure free for 90 days Click Here > >>>> http://p.sf.net/sfu/sfd2d-msazure > >>>> _______________________________________________ > >>>> 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. > >>> > >>> > >>> > ------------------------------------------------------------------------------ > >>> This SF email is sponsosred by: > >>> Try Windows Azure free for 90 days Click Here > >>> http://p.sf.net/sfu/sfd2d-msazure > >>> _______________________________________________ > >>> 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. > > > > > > > ------------------------------------------------------------------------------ > > This SF email is sponsosred by: > > Try Windows Azure free for 90 days Click Here > > http://p.sf.net/sfu/sfd2d-msazure > > _______________________________________________ > > sword-app-tech mailing list > > swo...@li... > > https://lists.sourceforge.net/lists/listinfo/sword-app-tech > > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > sword-app-tech mailing list > swo...@li... > https://lists.sourceforge.net/lists/listinfo/sword-app-tech > -- [image: @mire Inc.] *Mark Diggory *(Schedule a Meeting<https://www.google.com/calendar/selfsched?sstoken=UUdDSzJzTTlOUE1mfGRlZmF1bHR8MzgwMmEwYjk1NDc1NDQ1MGI0NWViYjYzZjExZDI3Mzg> ) *2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010* *Esperantolaan 4, Heverlee 3001, Belgium* http://www.atmire.com |
|
From: Glen R. <gle...@ll...> - 2012-03-29 16:22:26
|
Hi Robin and Ying, I've just looked through the sword-fedora implementation (for SWORD version 1.2) and it looks like if you submit the mime-type as text/xml and the packaging as 'http://www.loc.gov/METS/' it will extract any METS dmdSecs and store them as Fedora datastreams then go through the file section and add those as datastreams to an object in Fedora. I'm not sure how that would look in Islandora but if you have a METS document containing MODS and links to files you should get them pulled into a Fedora object. When I developed the METS handler for Fedora SWORD it was meant to handle a generic METS documents rather than any specific profile but I'm afraid I don't know much about the METSDSpaceSIP so I'm not quite sure whats missing. Hope that helps. Glen On 29 Mar 2012, at 15:56, Robin Taylor wrote: > Hi Ying, > > So the fact that the ServiceDocument contains... > > <sword:acceptPackaging q="0.9">http://purl.org/net/sword-types/METSDSpaceSIP</sword:acceptPackaging> > > ...means that in theory it should be happy with a Mets package with Mods > metadata. In practice I'll bet that the Fedora Sword implementation > expects SWAP metadata. I don't know if there are any Fedora experts > listening in who could confirm ? > > However, Mark makes a good point that SWORD may not be the best vehicle > for a bulk transfer of data. You might be best to find out what tools > Fedora has for bulk import and aim to export and transform your DSpace > data into the required format. > > Cheers, Robin. > > > > On 28/03/12 15:47, Ying Jin wrote: >> Hi Robin, >> >> Thanks for your reply. Here is the service document. I am running >> SWORD-Fedora 1.2 - >> >> = >> = >> = >> = >> = >> = >> = >> = >> = >> = >> = >> = >> = >> = >> = >> = >> = >> = >> = >> = >> = >> = >> = >> = >> = >> = >> = >> ======================================================================== >> <?xml version="1.0" encoding="UTF-8"?> >> <app:service xmlns:atom="http://www.w3.org/2005/Atom" xmlns:app="http://www.w3.org/2007/app >> " xmlns:sword="http://purl.org/net/sword/" xmlns:dcterms="http://purl.org/dc/terms/ >> "> >> <sword:version>1.3</sword:version> >> <sword:verbose>true</sword:verbose> >> <sword:noOp>true</sword:noOp> >> <app:workspace> >> <atom:title type="text">Fedora SWORD Workspace</atom:title> >> <app:collection href="http://localhost:8080/sword/ >> collection:open"> >> <atom:title type="text">Open Collection</atom:title> >> <app:accept>text/xml</app:accept> >> <app:accept>application/zip</app:accept> >> <app:accept>application/x-zip-compressed</app:accept> >> <app:accept>application/atom+xml</app:accept> >> <app:accept>image/gif</app:accept> >> <app:accept>image/jpeg</app:accept> >> <app:accept>image/jpg</app:accept> >> <app:accept>application/pdf</app:accept> >> <sword:acceptPackaging q="0.9">http://purl.org/net/sword-types/METSDSpaceSIP >> </sword:acceptPackaging> >> <sword:acceptPackaging q="0.9">http://www.loc.gov/METS/</ >> sword:acceptPackaging> >> <sword:collectionPolicy>This collection accepts any deposit >> from anyone</sword:collectionPolicy> >> <dcterms:abstract>This is a collection of objects which can >> be freely deposited to. This is aviable for the SWORD test project</ >> dcterms:abstract> >> <sword:mediation>true</sword:mediation> >> <sword:treatment>Preservation actions may occur on submited >> deposits</sword:treatment> >> </app:collection> >> <app:collection href="http://localhost:8080/sword/geography-collection >> "> >> <atom:title type="text">Geography Collection</atom:title> >> <app:accept>application/zip</app:accept> >> <sword:acceptPackaging q="0.9">http://purl.org/net/sword-types/METSDSpaceSIP >> </sword:acceptPackaging> >> <sword:collectionPolicy>This collection accepts any deposit >> </sword:collectionPolicy> >> <dcterms:abstract>This is a nested collection of geography >> objects</dcterms:abstract> >> <sword:service>http://localhost:8080/sword/servicedocument/geography.xml >> </sword:service> >> <sword:mediation>true</sword:mediation> >> <sword:treatment>Preservation actions may occur on submited >> deposits</sword:treatment> >> </app:collection> >> </app:workspace> >> </app:service> >> >> = >> = >> = >> = >> = >> = >> = >> = >> = >> = >> = >> = >> = >> = >> = >> = >> = >> = >> = >> = >> = >> = >> = >> = >> = >> = >> = >> ======================================================================== >> >> It shows METSDSpaceSIP as accepting package. However, it doesn't work. >> >> Best, >> Ying >> >> On Mar 28, 2012, at 4:35 AM, Robin Taylor wrote: >> >>> Hi Ying, >>> >>> If you send a request to the Fedora Sword Server for a Sword >>> ServiceDocument it should tell you what package formats it supports. >>> Would it be possible to do so and post the results here ? >>> >>> Thanks, Robin. >>> >>> >>> On 27/03/12 21:22, Ying Jin wrote: >>>> Hi, >>>> >>>> I'm working on our DSpace repository and trying to migrate items from >>>> DSpace to Fedora (we are going to use Islandora). It looks like SWORD >>>> might be a good approach. Here is the question from my testing >>>> migration - >>>> >>>> I exported an item using DSpace packager in METS format, and then use >>>> Fedora Sword module to import the item to Fedora. >>>> >>>> First, I used METSDSpaceSIP packaging, and the ingested item shows a >>>> zip file only. >>>> Then I tried METS packaging and only content files are uploaded. >>>> Obviously, it can't understand dspace mets. >>>> >>>> I think METSDSpaceSIP packaging is the right way to go but it doesn't >>>> seem to work properly. Is there anything I may need to setup for >>>> having this work? >>>> >>>> Thanks any suggestions and helps, >>>> Ying >>>> >>>> ------------------- >>>> CDS@Rice University >>>> >>>> ------------------------------------------------------------------------------ >>>> This SF email is sponsosred by: >>>> Try Windows Azure free for 90 days Click Here >>>> http://p.sf.net/sfu/sfd2d-msazure >>>> _______________________________________________ >>>> 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. >>> >>> >>> ------------------------------------------------------------------------------ >>> This SF email is sponsosred by: >>> Try Windows Azure free for 90 days Click Here >>> http://p.sf.net/sfu/sfd2d-msazure >>> _______________________________________________ >>> 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. > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > sword-app-tech mailing list > swo...@li... > https://lists.sourceforge.net/lists/listinfo/sword-app-tech |
|
From: Marco F. <mar...@ee...> - 2012-03-29 15:26:48
|
Hi Richard, I patched this one: https://bitbucket.org/beno/python-sword2 . I will test my code with your version as well, and apply my changes (if needed) to see if everything works. I will let you know. Cheers Marco On 29 Mar 2012, at 16:20, Richard Jones wrote: > Hi Marco, > > Which version of the python-sword2 library have you patched? I have done a large iteration on it recently (not yet formally released, but soon) at: > > https://bitbucket.org/richardjones/python-sword2 > > But if your patch is for that one, or still applicable, I'd be happy to have it. You could post it to the bitbucket issue tracker for the project. > > Cheers, > > Richard > > > On 29 March 2012 16:14, Marco Fabiani <mar...@ee...> wrote: > Hi Richard, > > I created an issue on JIRA as Stuart suggested (https://jira.duraspace.org/browse/DS-1149). I have never used JIRA before, so I'm not quite sure how to submit a patch, but I will give it a try. > > On a similar subject, I also had to slightly change the python-sword2 module to make it work with edit-media. Should I submit these changes as well? > > Cheers > Marco > > On 29 Mar 2012, at 16:09, Richard Jones wrote: > >> That's brilliant, thanks for picking that up. I will apologise in advance that I probably won't do anything about this until after Easter, but it is on my list ... >> >> Cheers, >> >> Richard >> >> >> On 29 March 2012 15:39, LEWIS Stuart <Stu...@ed...> wrote: >> Hi Marco, >> >> Thanks - submitting a patch to DSpace via JIRA would be great! >> >> - https://jira.duraspace.org/browse/DS >> >> Many thanks, >> >> >> Stuart >> >> >> >> -- >> The University of Edinburgh is a charitable body, registered in >> Scotland, with registration number SC005336. >> >> >> -----Original Message----- >> From: Marco Fabiani [mailto:mar...@ee...] >> Sent: 29 March 2012 15:37 >> To: Richard Jones >> Cc: LEWIS Stuart; swo...@li... >> Subject: Re: [sword-app-tech] SWORD 2 and DSpace >> >> Hi Richard and Stuart, >> >> I was looking at the BinaryContentIngester code to try to make my own ingester and I found the ORIGINAL bundle duplication bug: >> >> > Interesting - that looks like a bug with the DSpace implementation (ORIGINAL bundle duplication). I have some time scheduled to work on this implementation over the next month to six weeks, so will look for this and try to put in a fix. Also, I'll look into whether the content type can be put into the bitstream format field. >> >> In BinaryContentIngester, line 138: >> >> Bundle original = null; >> >> is assigned but never used because at lines 148: >> >> Bitstream bs = item.createSingleBitstream(deposit.getInputStream()); >> >> which creates a new bundle disregarding the original bundle. >> I this code should solve the problem, and also add the bitstream format field: >> >> Bitstream bs = original.createBitstream(deposit.getInputStream()); >> BitstreamFormat format = this.getFormat(context,deposit.getFilename()); >> bs.setFormat(format); >> >> At least from my short testing, this works. Should I submit this as an official bug to DSpace? >> >> Cheers >> Marco >> >> >> >> >> >> -- >> >> 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 > > |
|
From: Richard J. <ri...@co...> - 2012-03-29 15:20:46
|
Hi Marco, Which version of the python-sword2 library have you patched? I have done a large iteration on it recently (not yet formally released, but soon) at: https://bitbucket.org/richardjones/python-sword2 But if your patch is for that one, or still applicable, I'd be happy to have it. You could post it to the bitbucket issue tracker for the project. Cheers, Richard On 29 March 2012 16:14, Marco Fabiani <mar...@ee...> wrote: > Hi Richard, > > I created an issue on JIRA as Stuart suggested ( > https://jira.duraspace.org/browse/DS-1149). I have never used JIRA > before, so I'm not quite sure how to submit a patch, but I will give it a > try. > > On a similar subject, I also had to slightly change the python-sword2 > module to make it work with edit-media. Should I submit these changes as > well? > > Cheers > Marco > > On 29 Mar 2012, at 16:09, Richard Jones wrote: > > That's brilliant, thanks for picking that up. I will apologise in advance > that I probably won't do anything about this until after Easter, but it is > on my list ... > > Cheers, > > Richard > > > On 29 March 2012 15:39, LEWIS Stuart <Stu...@ed...> wrote: > >> Hi Marco, >> >> Thanks - submitting a patch to DSpace via JIRA would be great! >> >> - https://jira.duraspace.org/browse/DS >> >> Many thanks, >> >> >> Stuart >> >> >> >> -- >> The University of Edinburgh is a charitable body, registered in >> Scotland, with registration number SC005336. >> >> >> -----Original Message----- >> From: Marco Fabiani [mailto:mar...@ee...] >> Sent: 29 March 2012 15:37 >> To: Richard Jones >> Cc: LEWIS Stuart; swo...@li... >> Subject: Re: [sword-app-tech] SWORD 2 and DSpace >> >> Hi Richard and Stuart, >> >> I was looking at the BinaryContentIngester code to try to make my own >> ingester and I found the ORIGINAL bundle duplication bug: >> >> > Interesting - that looks like a bug with the DSpace implementation >> (ORIGINAL bundle duplication). I have some time scheduled to work on this >> implementation over the next month to six weeks, so will look for this and >> try to put in a fix. Also, I'll look into whether the content type can be >> put into the bitstream format field. >> >> In BinaryContentIngester, line 138: >> >> Bundle original = null; >> >> is assigned but never used because at lines 148: >> >> Bitstream bs = >> item.createSingleBitstream(deposit.getInputStream()); >> >> which creates a new bundle disregarding the original bundle. >> I this code should solve the problem, and also add the bitstream format >> field: >> >> Bitstream bs = original.createBitstream(deposit.getInputStream()); >> BitstreamFormat format = >> this.getFormat(context,deposit.getFilename()); >> bs.setFormat(format); >> >> At least from my short testing, this works. Should I submit this as an >> official bug to DSpace? >> >> Cheers >> Marco >> >> >> > > > -- > > 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 |
|
From: Marco F. <mar...@ee...> - 2012-03-29 15:14:18
|
Hi Richard, I created an issue on JIRA as Stuart suggested (https://jira.duraspace.org/browse/DS-1149). I have never used JIRA before, so I'm not quite sure how to submit a patch, but I will give it a try. On a similar subject, I also had to slightly change the python-sword2 module to make it work with edit-media. Should I submit these changes as well? Cheers Marco On 29 Mar 2012, at 16:09, Richard Jones wrote: > That's brilliant, thanks for picking that up. I will apologise in advance that I probably won't do anything about this until after Easter, but it is on my list ... > > Cheers, > > Richard > > > On 29 March 2012 15:39, LEWIS Stuart <Stu...@ed...> wrote: > Hi Marco, > > Thanks - submitting a patch to DSpace via JIRA would be great! > > - https://jira.duraspace.org/browse/DS > > Many thanks, > > > Stuart > > > > -- > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > > -----Original Message----- > From: Marco Fabiani [mailto:mar...@ee...] > Sent: 29 March 2012 15:37 > To: Richard Jones > Cc: LEWIS Stuart; swo...@li... > Subject: Re: [sword-app-tech] SWORD 2 and DSpace > > Hi Richard and Stuart, > > I was looking at the BinaryContentIngester code to try to make my own ingester and I found the ORIGINAL bundle duplication bug: > > > Interesting - that looks like a bug with the DSpace implementation (ORIGINAL bundle duplication). I have some time scheduled to work on this implementation over the next month to six weeks, so will look for this and try to put in a fix. Also, I'll look into whether the content type can be put into the bitstream format field. > > In BinaryContentIngester, line 138: > > Bundle original = null; > > is assigned but never used because at lines 148: > > Bitstream bs = item.createSingleBitstream(deposit.getInputStream()); > > which creates a new bundle disregarding the original bundle. > I this code should solve the problem, and also add the bitstream format field: > > Bitstream bs = original.createBitstream(deposit.getInputStream()); > BitstreamFormat format = this.getFormat(context,deposit.getFilename()); > bs.setFormat(format); > > At least from my short testing, this works. Should I submit this as an official bug to DSpace? > > Cheers > Marco > > > > > > -- > > Richard Jones, > > Founder, Cottage Labs > t: @richard_d_jones, @cottagelabs > w: http://cottagelabs.com > > |
|
From: Richard J. <ri...@co...> - 2012-03-29 15:10:03
|
That's brilliant, thanks for picking that up. I will apologise in advance that I probably won't do anything about this until after Easter, but it is on my list ... Cheers, Richard On 29 March 2012 15:39, LEWIS Stuart <Stu...@ed...> wrote: > Hi Marco, > > Thanks - submitting a patch to DSpace via JIRA would be great! > > - https://jira.duraspace.org/browse/DS > > Many thanks, > > > Stuart > > > > -- > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > > -----Original Message----- > From: Marco Fabiani [mailto:mar...@ee...] > Sent: 29 March 2012 15:37 > To: Richard Jones > Cc: LEWIS Stuart; swo...@li... > Subject: Re: [sword-app-tech] SWORD 2 and DSpace > > Hi Richard and Stuart, > > I was looking at the BinaryContentIngester code to try to make my own > ingester and I found the ORIGINAL bundle duplication bug: > > > Interesting - that looks like a bug with the DSpace implementation > (ORIGINAL bundle duplication). I have some time scheduled to work on this > implementation over the next month to six weeks, so will look for this and > try to put in a fix. Also, I'll look into whether the content type can be > put into the bitstream format field. > > In BinaryContentIngester, line 138: > > Bundle original = null; > > is assigned but never used because at lines 148: > > Bitstream bs = item.createSingleBitstream(deposit.getInputStream()); > > which creates a new bundle disregarding the original bundle. > I this code should solve the problem, and also add the bitstream format > field: > > Bitstream bs = original.createBitstream(deposit.getInputStream()); > BitstreamFormat format = > this.getFormat(context,deposit.getFilename()); > bs.setFormat(format); > > At least from my short testing, this works. Should I submit this as an > official bug to DSpace? > > Cheers > Marco > > > -- Richard Jones, Founder, Cottage Labs t: @richard_d_jones, @cottagelabs w: http://cottagelabs.com |
|
From: Robin T. <rob...@ed...> - 2012-03-29 14:56:21
|
Hi Ying, So the fact that the ServiceDocument contains... <sword:acceptPackaging q="0.9">http://purl.org/net/sword-types/METSDSpaceSIP</sword:acceptPackaging> ...means that in theory it should be happy with a Mets package with Mods metadata. In practice I'll bet that the Fedora Sword implementation expects SWAP metadata. I don't know if there are any Fedora experts listening in who could confirm ? However, Mark makes a good point that SWORD may not be the best vehicle for a bulk transfer of data. You might be best to find out what tools Fedora has for bulk import and aim to export and transform your DSpace data into the required format. Cheers, Robin. On 28/03/12 15:47, Ying Jin wrote: > Hi Robin, > > Thanks for your reply. Here is the service document. I am running > SWORD-Fedora 1.2 - > > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > ======================================================================== > <?xml version="1.0" encoding="UTF-8"?> > <app:service xmlns:atom="http://www.w3.org/2005/Atom" xmlns:app="http://www.w3.org/2007/app > " xmlns:sword="http://purl.org/net/sword/" xmlns:dcterms="http://purl.org/dc/terms/ > "> > <sword:version>1.3</sword:version> > <sword:verbose>true</sword:verbose> > <sword:noOp>true</sword:noOp> > <app:workspace> > <atom:title type="text">Fedora SWORD Workspace</atom:title> > <app:collection href="http://localhost:8080/sword/ > collection:open"> > <atom:title type="text">Open Collection</atom:title> > <app:accept>text/xml</app:accept> > <app:accept>application/zip</app:accept> > <app:accept>application/x-zip-compressed</app:accept> > <app:accept>application/atom+xml</app:accept> > <app:accept>image/gif</app:accept> > <app:accept>image/jpeg</app:accept> > <app:accept>image/jpg</app:accept> > <app:accept>application/pdf</app:accept> > <sword:acceptPackaging q="0.9">http://purl.org/net/sword-types/METSDSpaceSIP > </sword:acceptPackaging> > <sword:acceptPackaging q="0.9">http://www.loc.gov/METS/</ > sword:acceptPackaging> > <sword:collectionPolicy>This collection accepts any deposit > from anyone</sword:collectionPolicy> > <dcterms:abstract>This is a collection of objects which can > be freely deposited to. This is aviable for the SWORD test project</ > dcterms:abstract> > <sword:mediation>true</sword:mediation> > <sword:treatment>Preservation actions may occur on submited > deposits</sword:treatment> > </app:collection> > <app:collection href="http://localhost:8080/sword/geography-collection > "> > <atom:title type="text">Geography Collection</atom:title> > <app:accept>application/zip</app:accept> > <sword:acceptPackaging q="0.9">http://purl.org/net/sword-types/METSDSpaceSIP > </sword:acceptPackaging> > <sword:collectionPolicy>This collection accepts any deposit > </sword:collectionPolicy> > <dcterms:abstract>This is a nested collection of geography > objects</dcterms:abstract> > <sword:service>http://localhost:8080/sword/servicedocument/geography.xml > </sword:service> > <sword:mediation>true</sword:mediation> > <sword:treatment>Preservation actions may occur on submited > deposits</sword:treatment> > </app:collection> > </app:workspace> > </app:service> > > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > ======================================================================== > > It shows METSDSpaceSIP as accepting package. However, it doesn't work. > > Best, > Ying > > On Mar 28, 2012, at 4:35 AM, Robin Taylor wrote: > >> Hi Ying, >> >> If you send a request to the Fedora Sword Server for a Sword >> ServiceDocument it should tell you what package formats it supports. >> Would it be possible to do so and post the results here ? >> >> Thanks, Robin. >> >> >> On 27/03/12 21:22, Ying Jin wrote: >>> Hi, >>> >>> I'm working on our DSpace repository and trying to migrate items from >>> DSpace to Fedora (we are going to use Islandora). It looks like SWORD >>> might be a good approach. Here is the question from my testing >>> migration - >>> >>> I exported an item using DSpace packager in METS format, and then use >>> Fedora Sword module to import the item to Fedora. >>> >>> First, I used METSDSpaceSIP packaging, and the ingested item shows a >>> zip file only. >>> Then I tried METS packaging and only content files are uploaded. >>> Obviously, it can't understand dspace mets. >>> >>> I think METSDSpaceSIP packaging is the right way to go but it doesn't >>> seem to work properly. Is there anything I may need to setup for >>> having this work? >>> >>> Thanks any suggestions and helps, >>> Ying >>> >>> ------------------- >>> CDS@Rice University >>> >>> ------------------------------------------------------------------------------ >>> This SF email is sponsosred by: >>> Try Windows Azure free for 90 days Click Here >>> http://p.sf.net/sfu/sfd2d-msazure >>> _______________________________________________ >>> 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. >> >> >> ------------------------------------------------------------------------------ >> This SF email is sponsosred by: >> Try Windows Azure free for 90 days Click Here >> http://p.sf.net/sfu/sfd2d-msazure >> _______________________________________________ >> 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. |
|
From: LEWIS S. <Stu...@ed...> - 2012-03-29 14:40:20
|
Hi Marco, Thanks - submitting a patch to DSpace via JIRA would be great! - https://jira.duraspace.org/browse/DS Many thanks, Stuart -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. -----Original Message----- From: Marco Fabiani [mailto:mar...@ee...] Sent: 29 March 2012 15:37 To: Richard Jones Cc: LEWIS Stuart; swo...@li... Subject: Re: [sword-app-tech] SWORD 2 and DSpace Hi Richard and Stuart, I was looking at the BinaryContentIngester code to try to make my own ingester and I found the ORIGINAL bundle duplication bug: > Interesting - that looks like a bug with the DSpace implementation (ORIGINAL bundle duplication). I have some time scheduled to work on this implementation over the next month to six weeks, so will look for this and try to put in a fix. Also, I'll look into whether the content type can be put into the bitstream format field. In BinaryContentIngester, line 138: Bundle original = null; is assigned but never used because at lines 148: Bitstream bs = item.createSingleBitstream(deposit.getInputStream()); which creates a new bundle disregarding the original bundle. I this code should solve the problem, and also add the bitstream format field: Bitstream bs = original.createBitstream(deposit.getInputStream()); BitstreamFormat format = this.getFormat(context,deposit.getFilename()); bs.setFormat(format); At least from my short testing, this works. Should I submit this as an official bug to DSpace? Cheers Marco |
|
From: Marco F. <mar...@ee...> - 2012-03-29 14:37:11
|
Hi Richard and Stuart, I was looking at the BinaryContentIngester code to try to make my own ingester and I found the ORIGINAL bundle duplication bug: > Interesting - that looks like a bug with the DSpace implementation (ORIGINAL bundle duplication). I have some time scheduled to work on this implementation over the next month to six weeks, so will look for this and try to put in a fix. Also, I'll look into whether the content type can be put into the bitstream format field. In BinaryContentIngester, line 138: Bundle original = null; is assigned but never used because at lines 148: Bitstream bs = item.createSingleBitstream(deposit.getInputStream()); which creates a new bundle disregarding the original bundle. I this code should solve the problem, and also add the bitstream format field: Bitstream bs = original.createBitstream(deposit.getInputStream()); BitstreamFormat format = this.getFormat(context,deposit.getFilename()); bs.setFormat(format); At least from my short testing, this works. Should I submit this as an official bug to DSpace? Cheers Marco |
|
From: Marco F. <mar...@ee...> - 2012-03-29 10:45:09
|
Hello, I noticed that all the files we upload via the SWORDv2 server for DSpace, even after being successfully processed and ingested, remain in the upload.tempdir folder specified in the swordv2-server.cfg file. Is there a way to delete them after the ingestion has been completed? Thank you best regards Marco Fabiani -------------------------------------------------- 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 |
|
From: Ying J. <Yin...@ri...> - 2012-03-28 15:30:15
|
Hi Mark, Richard and Robin, thanks so much for all the tips and suggestions. Yes, it is going to be a one-time transfer for us to move all content from DSpace to Fedora/Islandora. Though manipulating AIP package is an easier approach, I'm very interested in developing new crosswalks. I need to discuss this with my boss today. Also, is there any plan getting SWORDv2 services work for DSpace? Thanks, Ying On Mar 28, 2012, at 9:23 AM, Mark Diggory wrote: > Yes, as Robin and Richard point out. You can create your own > crosswalks/packagers. Hypothetically one could try to enable the > AIP Packager through SWORD. You could then expose the AIP via > interface and write tools against the full set of metadata. However > it sounds like Ying is attempting something that is a one time > transfer of all content from DSpace to Fedora/Islandora. I'd > recommend focusing on getting everything out of DSpace into a file > system, then massaging it into the state needed for import into > Fedora. Using SWORD itself for this is not necessarily of great > importance. Though, in the future, enabling such round-tripping for > other migration cases would be of benefit to the community. This is > where the mapping Ying ultimately does may be of interest. > > A tangent... I was just thinking about this over my morning > coffee... SWORDv2 does describe an atomic process for putting and > getting individual media resources in its specification. > > http://sword-app.svn.sourceforge.net/viewvc/sword-app/spec/tags/sword-2.0/SWORDProfile.html?revision=377#protocoloperations_retrievingcontent_feed > > This could represent the basic API layer for a DSpace storage > service to be bound to any SWORDv2 (possibly any APP service) as its > store. I this regard, Richards point about getting SWORDv2 services > for Fedora worked out would be a great benefit to the whole DSpace/ > Fedora initiative. > > Cheers, > Mark > > On Wednesday, March 28, 2012, Robin Taylor wrote: > Just to expand a little - I think the default metadata schema when > creating a Mets package from DSpace is Mods. In theory if the Fedora > Sword Server claims to accept Mets packages conforming to the DSpace > Mets SIP Profile > (https://wiki.duraspace.org/display/DSPACE/DSpaceMETSSIPProfile) it > should be able to deal with the incoming Mods metadata, in practice it > may expect the metadata to conform to SWAP > (http://www.ukoln.ac.uk/repositories/digirep/index/Eprints_Application_Profile > ). > DSpace does allow you to specify the crosswalk for a metadata schema > when creating the Mets package, so you could change it to create SWAP > compliant metadata. However, as Mark points out, the existing SWAP > crosswalk is fairly skeletal. You do have the option of expanding that > crosswalk or adding a new one if none of the existing crosswalks meet > your needs. > > Cheers, Robin. > > > On 27/03/12 21:22, Ying Jin wrote: > > Hi, > > > > I'm working on our DSpace repository and trying to migrate items > from > > DSpace to Fedora (we are going to use Islandora). It looks like > SWORD > > might be a good approach. Here is the question from my testing > > migration - > > > > I exported an item using DSpace packager in METS format, and then > use > > Fedora Sword module to import the item to Fedora. > > > > First, I used METSDSpaceSIP packaging, and the ingested item shows a > > zip file only. > > Then I tried METS packaging and only content files are uploaded. > > Obviously, it can't understand dspace mets. > > > > I think METSDSpaceSIP packaging is the right way to go but it > doesn't > > seem to work properly. Is there anything I may need to setup for > > having this work? > > > > Thanks any suggestions and helps, > > Ying > > > > ------------------- > > CDS@Rice University > > > > > ------------------------------------------------------------------------------ > > This SF email is sponsosred by: > > Try Windows Azure free for 90 days Click Here > > http://p.sf.net/sfu/sfd2d-msazure > > _______________________________________________ > > 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. > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > sword-app-tech mailing list > swo...@li... > https://lists.sourceforge.net/lists/listinfo/sword-app-tech > > > -- > > Mark Diggory (Schedule a Meeting) > 2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010 > Esperantolaan 4, Heverlee 3001, Belgium > http://www.atmire.com > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure_______________________________________________ > sword-app-tech mailing list > swo...@li... > https://lists.sourceforge.net/lists/listinfo/sword-app-tech |
|
From: Ying J. <Yin...@ri...> - 2012-03-28 14:47:19
|
Hi Robin, Thanks for your reply. Here is the service document. I am running SWORD-Fedora 1.2 - = = = = = = = = = = = = = = = = = = = = = = = = = = = ======================================================================== <?xml version="1.0" encoding="UTF-8"?> <app:service xmlns:atom="http://www.w3.org/2005/Atom" xmlns:app="http://www.w3.org/2007/app " xmlns:sword="http://purl.org/net/sword/" xmlns:dcterms="http://purl.org/dc/terms/ "> <sword:version>1.3</sword:version> <sword:verbose>true</sword:verbose> <sword:noOp>true</sword:noOp> <app:workspace> <atom:title type="text">Fedora SWORD Workspace</atom:title> <app:collection href="http://localhost:8080/sword/ collection:open"> <atom:title type="text">Open Collection</atom:title> <app:accept>text/xml</app:accept> <app:accept>application/zip</app:accept> <app:accept>application/x-zip-compressed</app:accept> <app:accept>application/atom+xml</app:accept> <app:accept>image/gif</app:accept> <app:accept>image/jpeg</app:accept> <app:accept>image/jpg</app:accept> <app:accept>application/pdf</app:accept> <sword:acceptPackaging q="0.9">http://purl.org/net/sword-types/METSDSpaceSIP </sword:acceptPackaging> <sword:acceptPackaging q="0.9">http://www.loc.gov/METS/</ sword:acceptPackaging> <sword:collectionPolicy>This collection accepts any deposit from anyone</sword:collectionPolicy> <dcterms:abstract>This is a collection of objects which can be freely deposited to. This is aviable for the SWORD test project</ dcterms:abstract> <sword:mediation>true</sword:mediation> <sword:treatment>Preservation actions may occur on submited deposits</sword:treatment> </app:collection> <app:collection href="http://localhost:8080/sword/geography-collection "> <atom:title type="text">Geography Collection</atom:title> <app:accept>application/zip</app:accept> <sword:acceptPackaging q="0.9">http://purl.org/net/sword-types/METSDSpaceSIP </sword:acceptPackaging> <sword:collectionPolicy>This collection accepts any deposit </sword:collectionPolicy> <dcterms:abstract>This is a nested collection of geography objects</dcterms:abstract> <sword:service>http://localhost:8080/sword/servicedocument/geography.xml </sword:service> <sword:mediation>true</sword:mediation> <sword:treatment>Preservation actions may occur on submited deposits</sword:treatment> </app:collection> </app:workspace> </app:service> = = = = = = = = = = = = = = = = = = = = = = = = = = = ======================================================================== It shows METSDSpaceSIP as accepting package. However, it doesn't work. Best, Ying On Mar 28, 2012, at 4:35 AM, Robin Taylor wrote: > Hi Ying, > > If you send a request to the Fedora Sword Server for a Sword > ServiceDocument it should tell you what package formats it supports. > Would it be possible to do so and post the results here ? > > Thanks, Robin. > > > On 27/03/12 21:22, Ying Jin wrote: >> Hi, >> >> I'm working on our DSpace repository and trying to migrate items from >> DSpace to Fedora (we are going to use Islandora). It looks like SWORD >> might be a good approach. Here is the question from my testing >> migration - >> >> I exported an item using DSpace packager in METS format, and then use >> Fedora Sword module to import the item to Fedora. >> >> First, I used METSDSpaceSIP packaging, and the ingested item shows a >> zip file only. >> Then I tried METS packaging and only content files are uploaded. >> Obviously, it can't understand dspace mets. >> >> I think METSDSpaceSIP packaging is the right way to go but it doesn't >> seem to work properly. Is there anything I may need to setup for >> having this work? >> >> Thanks any suggestions and helps, >> Ying >> >> ------------------- >> CDS@Rice University >> >> ------------------------------------------------------------------------------ >> This SF email is sponsosred by: >> Try Windows Azure free for 90 days Click Here >> http://p.sf.net/sfu/sfd2d-msazure >> _______________________________________________ >> 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. > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > sword-app-tech mailing list > swo...@li... > https://lists.sourceforge.net/lists/listinfo/sword-app-tech > |
|
From: Mark D. <mdi...@at...> - 2012-03-28 14:23:19
|
Yes, as Robin and Richard point out. You can create your own crosswalks/packagers. Hypothetically one could try to enable the AIP Packager through SWORD. You could then expose the AIP via interface and write tools against the full set of metadata. However it sounds like Ying is attempting something that is a one time transfer of all content from DSpace to Fedora/Islandora. I'd recommend focusing on getting everything out of DSpace into a file system, then massaging it into the state needed for import into Fedora. Using SWORD itself for this is not necessarily of great importance. Though, in the future, enabling such round-tripping for other migration cases would be of benefit to the community. This is where the mapping Ying ultimately does may be of interest. A tangent... I was just thinking about this over my morning coffee... SWORDv2 does describe an atomic process for putting and getting individual media resources in its specification. http://sword-app.svn.sourceforge.net/viewvc/sword-app/spec/tags/sword-2.0/SWORDProfile.html?revision=377#protocoloperations_retrievingcontent_feed This could represent the basic API layer for a DSpace storage service to be bound to any SWORDv2 (possibly any APP service) as its store. I this regard, Richards point about getting SWORDv2 services for Fedora worked out would be a great benefit to the whole DSpace/Fedora initiative. Cheers, Mark On Wednesday, March 28, 2012, Robin Taylor wrote: > Just to expand a little - I think the default metadata schema when > creating a Mets package from DSpace is Mods. In theory if the Fedora > Sword Server claims to accept Mets packages conforming to the DSpace > Mets SIP Profile > (https://wiki.duraspace.org/display/DSPACE/DSpaceMETSSIPProfile) it > should be able to deal with the incoming Mods metadata, in practice it > may expect the metadata to conform to SWAP > ( > http://www.ukoln.ac.uk/repositories/digirep/index/Eprints_Application_Profile > ). > DSpace does allow you to specify the crosswalk for a metadata schema > when creating the Mets package, so you could change it to create SWAP > compliant metadata. However, as Mark points out, the existing SWAP > crosswalk is fairly skeletal. You do have the option of expanding that > crosswalk or adding a new one if none of the existing crosswalks meet > your needs. > > Cheers, Robin. > > > On 27/03/12 21:22, Ying Jin wrote: > > Hi, > > > > I'm working on our DSpace repository and trying to migrate items from > > DSpace to Fedora (we are going to use Islandora). It looks like SWORD > > might be a good approach. Here is the question from my testing > > migration - > > > > I exported an item using DSpace packager in METS format, and then use > > Fedora Sword module to import the item to Fedora. > > > > First, I used METSDSpaceSIP packaging, and the ingested item shows a > > zip file only. > > Then I tried METS packaging and only content files are uploaded. > > Obviously, it can't understand dspace mets. > > > > I think METSDSpaceSIP packaging is the right way to go but it doesn't > > seem to work properly. Is there anything I may need to setup for > > having this work? > > > > Thanks any suggestions and helps, > > Ying > > > > ------------------- > > CDS@Rice University > > > > > ------------------------------------------------------------------------------ > > This SF email is sponsosred by: > > Try Windows Azure free for 90 days Click Here > > http://p.sf.net/sfu/sfd2d-msazure > > _______________________________________________ > > 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. > > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > sword-app-tech mailing list > swo...@li... > https://lists.sourceforge.net/lists/listinfo/sword-app-tech > -- [image: @mire Inc.] *Mark Diggory *(Schedule a Meeting<https://www.google.com/calendar/selfsched?sstoken=UUdDSzJzTTlOUE1mfGRlZmF1bHR8MzgwMmEwYjk1NDc1NDQ1MGI0NWViYjYzZjExZDI3Mzg> ) *2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010* *Esperantolaan 4, Heverlee 3001, Belgium* http://www.atmire.com |
|
From: Robin T. <rob...@ed...> - 2012-03-28 09:55:20
|
Just to expand a little - I think the default metadata schema when creating a Mets package from DSpace is Mods. In theory if the Fedora Sword Server claims to accept Mets packages conforming to the DSpace Mets SIP Profile (https://wiki.duraspace.org/display/DSPACE/DSpaceMETSSIPProfile) it should be able to deal with the incoming Mods metadata, in practice it may expect the metadata to conform to SWAP (http://www.ukoln.ac.uk/repositories/digirep/index/Eprints_Application_Profile). DSpace does allow you to specify the crosswalk for a metadata schema when creating the Mets package, so you could change it to create SWAP compliant metadata. However, as Mark points out, the existing SWAP crosswalk is fairly skeletal. You do have the option of expanding that crosswalk or adding a new one if none of the existing crosswalks meet your needs. Cheers, Robin. On 27/03/12 21:22, Ying Jin wrote: > Hi, > > I'm working on our DSpace repository and trying to migrate items from > DSpace to Fedora (we are going to use Islandora). It looks like SWORD > might be a good approach. Here is the question from my testing > migration - > > I exported an item using DSpace packager in METS format, and then use > Fedora Sword module to import the item to Fedora. > > First, I used METSDSpaceSIP packaging, and the ingested item shows a > zip file only. > Then I tried METS packaging and only content files are uploaded. > Obviously, it can't understand dspace mets. > > I think METSDSpaceSIP packaging is the right way to go but it doesn't > seem to work properly. Is there anything I may need to setup for > having this work? > > Thanks any suggestions and helps, > Ying > > ------------------- > CDS@Rice University > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > 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. |
|
From: Robin T. <rob...@ed...> - 2012-03-28 09:35:48
|
Hi Ying, If you send a request to the Fedora Sword Server for a Sword ServiceDocument it should tell you what package formats it supports. Would it be possible to do so and post the results here ? Thanks, Robin. On 27/03/12 21:22, Ying Jin wrote: > Hi, > > I'm working on our DSpace repository and trying to migrate items from > DSpace to Fedora (we are going to use Islandora). It looks like SWORD > might be a good approach. Here is the question from my testing > migration - > > I exported an item using DSpace packager in METS format, and then use > Fedora Sword module to import the item to Fedora. > > First, I used METSDSpaceSIP packaging, and the ingested item shows a > zip file only. > Then I tried METS packaging and only content files are uploaded. > Obviously, it can't understand dspace mets. > > I think METSDSpaceSIP packaging is the right way to go but it doesn't > seem to work properly. Is there anything I may need to setup for > having this work? > > Thanks any suggestions and helps, > Ying > > ------------------- > CDS@Rice University > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > 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. |
|
From: Richard J. <ri...@co...> - 2012-03-28 09:24:39
|
Hi Ying, Just to add something to what Mark says: it is the case that the SWORD package format in use by default isn't sufficiently rich to move all the metadata fields in DSpace, but you are at liberty to develop your own crosswalks/disseminators to ingest/disseminate packages. SWORD is focussed on the transport, though, and not the content. In SWORDv2 this process is slightly easier, but there is currently no formal support in Fedora (it's coming in the next couple of months we expect) for that version. Cheers, Richard On 27 March 2012 22:17, Mark Diggory <mdi...@at...> wrote: > Ying, > > Migrating content from DSpace to Fedora will encounter some loss of > metadata if you utilize sword for this purpose. Namely, the SWAP format > isn't going to contain all the metadata fields in your DSpace items. You > might consider using the AIP PackageDisseminator from the commandline to > extract all the data you can from the DSpace Item. > > As you know theres been underfunded efforts to integrate DSpace and Fedora > going on for a few years in the DSpace community. What you end up deciding > on for a mapping between your DSpace Items and Fedora Objects would be of > the utmost interest to us. Likewise, I think we would have a strong > interest in seeing what your choices are for final metadata storage in your > Items. > > Regards, > Mark > > > On Tue, Mar 27, 2012 at 1:22 PM, Ying Jin <Yin...@ri...> wrote: > >> Hi, >> >> I'm working on our DSpace repository and trying to migrate items from >> DSpace to Fedora (we are going to use Islandora). It looks like SWORD >> might be a good approach. Here is the question from my testing >> migration - >> >> I exported an item using DSpace packager in METS format, and then use >> Fedora Sword module to import the item to Fedora. >> >> First, I used METSDSpaceSIP packaging, and the ingested item shows a >> zip file only. >> Then I tried METS packaging and only content files are uploaded. >> Obviously, it can't understand dspace mets. >> >> I think METSDSpaceSIP packaging is the right way to go but it doesn't >> seem to work properly. Is there anything I may need to setup for >> having this work? >> >> Thanks any suggestions and helps, >> Ying >> >> ------------------- >> CDS@Rice University >> >> >> ------------------------------------------------------------------------------ >> This SF email is sponsosred by: >> Try Windows Azure free for 90 days Click Here >> http://p.sf.net/sfu/sfd2d-msazure >> _______________________________________________ >> sword-app-tech mailing list >> swo...@li... >> https://lists.sourceforge.net/lists/listinfo/sword-app-tech >> > > > > -- > [image: @mire Inc.] > *Mark Diggory *(Schedule a Meeting<https://www.google.com/calendar/selfsched?sstoken=UUdDSzJzTTlOUE1mfGRlZmF1bHR8MzgwMmEwYjk1NDc1NDQ1MGI0NWViYjYzZjExZDI3Mzg> > ) > *2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010* > *Esperantolaan 4, Heverlee 3001, Belgium* > http://www.atmire.com > > > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > 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 |
|
From: Mark D. <mdi...@at...> - 2012-03-27 21:17:12
|
Ying, Migrating content from DSpace to Fedora will encounter some loss of metadata if you utilize sword for this purpose. Namely, the SWAP format isn't going to contain all the metadata fields in your DSpace items. You might consider using the AIP PackageDisseminator from the commandline to extract all the data you can from the DSpace Item. As you know theres been underfunded efforts to integrate DSpace and Fedora going on for a few years in the DSpace community. What you end up deciding on for a mapping between your DSpace Items and Fedora Objects would be of the utmost interest to us. Likewise, I think we would have a strong interest in seeing what your choices are for final metadata storage in your Items. Regards, Mark On Tue, Mar 27, 2012 at 1:22 PM, Ying Jin <Yin...@ri...> wrote: > Hi, > > I'm working on our DSpace repository and trying to migrate items from > DSpace to Fedora (we are going to use Islandora). It looks like SWORD > might be a good approach. Here is the question from my testing > migration - > > I exported an item using DSpace packager in METS format, and then use > Fedora Sword module to import the item to Fedora. > > First, I used METSDSpaceSIP packaging, and the ingested item shows a > zip file only. > Then I tried METS packaging and only content files are uploaded. > Obviously, it can't understand dspace mets. > > I think METSDSpaceSIP packaging is the right way to go but it doesn't > seem to work properly. Is there anything I may need to setup for > having this work? > > Thanks any suggestions and helps, > Ying > > ------------------- > CDS@Rice University > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > sword-app-tech mailing list > swo...@li... > https://lists.sourceforge.net/lists/listinfo/sword-app-tech > -- [image: @mire Inc.] *Mark Diggory *(Schedule a Meeting<https://www.google.com/calendar/selfsched?sstoken=UUdDSzJzTTlOUE1mfGRlZmF1bHR8MzgwMmEwYjk1NDc1NDQ1MGI0NWViYjYzZjExZDI3Mzg> ) *2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010* *Esperantolaan 4, Heverlee 3001, Belgium* http://www.atmire.com |
|
From: Ying J. <Yin...@ri...> - 2012-03-27 20:22:28
|
Hi, I'm working on our DSpace repository and trying to migrate items from DSpace to Fedora (we are going to use Islandora). It looks like SWORD might be a good approach. Here is the question from my testing migration - I exported an item using DSpace packager in METS format, and then use Fedora Sword module to import the item to Fedora. First, I used METSDSpaceSIP packaging, and the ingested item shows a zip file only. Then I tried METS packaging and only content files are uploaded. Obviously, it can't understand dspace mets. I think METSDSpaceSIP packaging is the right way to go but it doesn't seem to work properly. Is there anything I may need to setup for having this work? Thanks any suggestions and helps, Ying ------------------- CDS@Rice University |
|
From: Marco F. <mar...@ee...> - 2012-03-26 16:29:57
|
Hi Stuart, the problem was that in the swordv2-server.cfg file I used: accepts =*/* Changing it to: accepts = application/zip solved the "Unacceptable content type" problem. After that, I was getting a 500 server error, but adding the lines you suggested in this message solved this problem: http://sourceforge.net/mailarchive/message.php?msg_id=28602009 Thanks for all the help! Best wishes Marco > Hi Marco, > > The headers look OK (at a quick glance). > > If you look in dspace.log, you should see an error that will give a bit more information: > > // determine if this is an acceptable file format > if (!swordConfig.isAcceptableContentType(context, deposit.getMimeType(), dso)) > { > log.error("Unacceptable content type detected: " + deposit.getMimeType() + " for object " + dso.getID()); > throw new SwordError(UriRegistry.ERROR_CONTENT, > "Unacceptable content type in deposit request: " + deposit.getMimeType()); > } > > You need to POST the file to the collection URL described in the service document. You don't need to first create an item. > > Thanks, > > > Stuart > > > > -- > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > > -----Original Message----- > From: Marco Fabiani [mailto:mar...@ee...] > Sent: 26 March 2012 16:33 > To: Richard Jones > Cc: swo...@li...; LEWIS Stuart > Subject: Re: [sword-app-tech] SWORD 2 and DSpace > > Hi Richard, > > I will look into how to create my own ingester, thanks. > > Do you have any suggestions regarding the METS package ingestion (I'm using the example package I found on the sword app website)? > >> >> I realise that all these problems might be solved by using a METSDSpaceSIP package instead, but I couldn't manage to ingest one, I keep getting Error 415: Unacceptable content. >> >> Here are the headers I am posting (to the Collection IRI): >> >> 'Content-Length': '33777', 'Content-Disposition': 'attachment; filename=example.zip', 'In-Progress': 'true', 'Content-MD5': '2b25f82ba67284461d4a481d7a06dd28', 'Packaging': 'http://purl.org/net/sword/package/METSDSpaceSIP', 'Content-Type': 'application/zip' >> >> and the error message from the server: >> >> <?xml version="1.0" encoding="ISO-8859-1"?> <sword:error >> href="http://purl.org/net/sword/error/ErrorContent" xmlns:sword="http://purl.org/net/sword/terms/"><atom:title xmlns:atom="http://www.w3.org/2005/Atom"/><atom:updated xmlns:atom="http://www.w3.org/2005/Atom">2012-03-26T14:43:03Z</atom:updated><atom:generator uri="http://www.dspace.org/ns/sword/2.0/" version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">rdm...@gm...</atom:generator><sword:treatment>Processing failed</sword:treatment><atom:summary xmlns:atom="http://www.w3.org/2005/Atom">Unacceptable content type in deposit request: application/zip</atom:summary><sword:verboseDescription>org.swordapp.server.SwordError: Unacceptable content type in deposit request: application/zip >> at org.dspace.sword2.DSpaceSwordAPI.isAcceptable(DSpaceSwordAPI.java:228) >> at org.dspace.sword2.CollectionDepositManagerDSpace.createNewFromBinary(CollectionDepositManagerDSpace.java:218) >> at org.dspace.sword2.CollectionDepositManagerDSpace.createNew(CollectionDepositManagerDSpace.java:112) >> at org.swordapp.server.CollectionAPI.post(CollectionAPI.java:158) >> at org.swordapp.server.servlets.CollectionServletDefault.doPost(CollectionServletDefault.java:48) >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:637) >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) >> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) >> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) >> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) >> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) >> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) >> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) >> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) >> at org.apache.catalina.valves.RequestDumperValve.invoke(RequestDumperValve.java:156) >> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:291) >> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859) >> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:602) >> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489) >> at java.lang.Thread.run(Thread.java:662) >> </sword:verboseDescription></sword:error> >> >> Is it correct to POST the package to the Collection, or should I first create an entry and then post the package to the IRI of the newly created entry? >> > |
|
From: LEWIS S. <Stu...@ed...> - 2012-03-26 15:50:50
|
Hi Marco,
The headers look OK (at a quick glance).
If you look in dspace.log, you should see an error that will give a bit more information:
// determine if this is an acceptable file format
if (!swordConfig.isAcceptableContentType(context, deposit.getMimeType(), dso))
{
log.error("Unacceptable content type detected: " + deposit.getMimeType() + " for object " + dso.getID());
throw new SwordError(UriRegistry.ERROR_CONTENT,
"Unacceptable content type in deposit request: " + deposit.getMimeType());
}
You need to POST the file to the collection URL described in the service document. You don't need to first create an item.
Thanks,
Stuart
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
-----Original Message-----
From: Marco Fabiani [mailto:mar...@ee...]
Sent: 26 March 2012 16:33
To: Richard Jones
Cc: swo...@li...; LEWIS Stuart
Subject: Re: [sword-app-tech] SWORD 2 and DSpace
Hi Richard,
I will look into how to create my own ingester, thanks.
Do you have any suggestions regarding the METS package ingestion (I'm using the example package I found on the sword app website)?
>
> I realise that all these problems might be solved by using a METSDSpaceSIP package instead, but I couldn't manage to ingest one, I keep getting Error 415: Unacceptable content.
>
> Here are the headers I am posting (to the Collection IRI):
>
> 'Content-Length': '33777', 'Content-Disposition': 'attachment; filename=example.zip', 'In-Progress': 'true', 'Content-MD5': '2b25f82ba67284461d4a481d7a06dd28', 'Packaging': 'http://purl.org/net/sword/package/METSDSpaceSIP', 'Content-Type': 'application/zip'
>
> and the error message from the server:
>
> <?xml version="1.0" encoding="ISO-8859-1"?> <sword:error
> href="http://purl.org/net/sword/error/ErrorContent" xmlns:sword="http://purl.org/net/sword/terms/"><atom:title xmlns:atom="http://www.w3.org/2005/Atom"/><atom:updated xmlns:atom="http://www.w3.org/2005/Atom">2012-03-26T14:43:03Z</atom:updated><atom:generator uri="http://www.dspace.org/ns/sword/2.0/" version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">rdm...@gm...</atom:generator><sword:treatment>Processing failed</sword:treatment><atom:summary xmlns:atom="http://www.w3.org/2005/Atom">Unacceptable content type in deposit request: application/zip</atom:summary><sword:verboseDescription>org.swordapp.server.SwordError: Unacceptable content type in deposit request: application/zip
> at org.dspace.sword2.DSpaceSwordAPI.isAcceptable(DSpaceSwordAPI.java:228)
> at org.dspace.sword2.CollectionDepositManagerDSpace.createNewFromBinary(CollectionDepositManagerDSpace.java:218)
> at org.dspace.sword2.CollectionDepositManagerDSpace.createNew(CollectionDepositManagerDSpace.java:112)
> at org.swordapp.server.CollectionAPI.post(CollectionAPI.java:158)
> at org.swordapp.server.servlets.CollectionServletDefault.doPost(CollectionServletDefault.java:48)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> at org.apache.catalina.valves.RequestDumperValve.invoke(RequestDumperValve.java:156)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:291)
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859)
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:602)
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
> at java.lang.Thread.run(Thread.java:662)
> </sword:verboseDescription></sword:error>
>
> Is it correct to POST the package to the Collection, or should I first create an entry and then post the package to the IRI of the newly created entry?
>
|
|
From: Marco F. <mar...@ee...> - 2012-03-26 15:33:17
|
Hi Richard, I will look into how to create my own ingester, thanks. Do you have any suggestions regarding the METS package ingestion (I'm using the example package I found on the sword app website)? > > I realise that all these problems might be solved by using a METSDSpaceSIP package instead, but I couldn't manage to ingest one, I keep getting Error 415: Unacceptable content. > > Here are the headers I am posting (to the Collection IRI): > > 'Content-Length': '33777', 'Content-Disposition': 'attachment; filename=example.zip', 'In-Progress': 'true', 'Content-MD5': '2b25f82ba67284461d4a481d7a06dd28', 'Packaging': 'http://purl.org/net/sword/package/METSDSpaceSIP', 'Content-Type': 'application/zip' > > and the error message from the server: > > <?xml version="1.0" encoding="ISO-8859-1"?> > <sword:error href="http://purl.org/net/sword/error/ErrorContent" xmlns:sword="http://purl.org/net/sword/terms/"><atom:title xmlns:atom="http://www.w3.org/2005/Atom"/><atom:updated xmlns:atom="http://www.w3.org/2005/Atom">2012-03-26T14:43:03Z</atom:updated><atom:generator uri="http://www.dspace.org/ns/sword/2.0/" version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">rdm...@gm...</atom:generator><sword:treatment>Processing failed</sword:treatment><atom:summary xmlns:atom="http://www.w3.org/2005/Atom">Unacceptable content type in deposit request: application/zip</atom:summary><sword:verboseDescription>org.swordapp.server.SwordError: Unacceptable content type in deposit request: application/zip > at org.dspace.sword2.DSpaceSwordAPI.isAcceptable(DSpaceSwordAPI.java:228) > at org.dspace.sword2.CollectionDepositManagerDSpace.createNewFromBinary(CollectionDepositManagerDSpace.java:218) > at org.dspace.sword2.CollectionDepositManagerDSpace.createNew(CollectionDepositManagerDSpace.java:112) > at org.swordapp.server.CollectionAPI.post(CollectionAPI.java:158) > at org.swordapp.server.servlets.CollectionServletDefault.doPost(CollectionServletDefault.java:48) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:637) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) > at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) > at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) > at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) > at org.apache.catalina.valves.RequestDumperValve.invoke(RequestDumperValve.java:156) > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:291) > at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859) > at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:602) > at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489) > at java.lang.Thread.run(Thread.java:662) > </sword:verboseDescription></sword:error> > > Is it correct to POST the package to the Collection, or should I first create an entry and then post the package to the IRI of the newly created entry? > |
|
From: Richard J. <ri...@co...> - 2012-03-26 15:19:38
|
Hi Marco, Interesting - that looks like a bug with the DSpace implementation (ORIGINAL bundle duplication). I have some time scheduled to work on this implementation over the next month to six weeks, so will look for this and try to put in a fix. Also, I'll look into whether the content type can be put into the bitstream format field. You are, meanwhile, free to implement your own ingesters, so if you want an ingester which understands about LICENCE and CCLICENCE you can write one. Cheers, Richard On 26 March 2012 16:13, Marco Fabiani <mar...@ee...> wrote: > > Hi Richard, > > (apologies for the long message) > > I finally managed to POST bitstreams to an item that I previously created > with an ATOM entry, using the Edit media IRI. Thanks for the help! > > However, there are a couple of things that don't work quite right: > - when I create the entry with metadata only, the bundle ORIGINAL is > create, and it is empty. When I POST a new file, a new ORIGINAL bundle is > created, and the file copied into it, and this is repeated for every file I > POST. Normally, all the bitstreams should go into the same ORIGINAL folder > (the first one, which remains empty). This causes some problems in the > visualisation of the item. > - the MIME type and description of the file don't appear in the bitstream > information, can they be sent somehow? For the MIME type, in fact, when I > POST the file, I always have to specify "application/zip" in the headers > for it to work (and not the real MIME type), I suppose because the > bitstream in compressed when it is sent. > - is there a way to POST to a license file the LICENSE or CCLICENSE > bundles? I guess this would solve the ORIGINAL folder as well? > > I realise that all these problems might be solved by using a METSDSpaceSIP > package instead, but I couldn't manage to ingest one, I keep getting Error > 415: Unacceptable content. > > Here are the headers I am posting (to the Collection IRI): > > 'Content-Length': '33777', 'Content-Disposition': 'attachment; > filename=example.zip', 'In-Progress': 'true', 'Content-MD5': > '2b25f82ba67284461d4a481d7a06dd28', 'Packaging': ' > http://purl.org/net/sword/package/METSDSpaceSIP', 'Content-Type': > 'application/zip' > > and the error message from the server: > > <?xml version="1.0" encoding="ISO-8859-1"?> > <sword:error href="http://purl.org/net/sword/error/ErrorContent" > xmlns:sword="http://purl.org/net/sword/terms/"><atom:title xmlns:atom=" > http://www.w3.org/2005/Atom"/><atom:updated xmlns:atom=" > http://www.w3.org/2005/Atom">2012-03-26T14:43:03Z</atom:updated><atom:generator > uri="http://www.dspace.org/ns/sword/2.0/" version="2.0" xmlns:atom=" > http://www.w3.org/2005/Atom">rdm...@gm...</atom:generator><sword:treatment>Processing > failed</sword:treatment><atom:summary xmlns:atom=" > http://www.w3.org/2005/Atom">Unacceptable content type in deposit > request: > application/zip</atom:summary><sword:verboseDescription>org.swordapp.server.SwordError: > Unacceptable content type in deposit request: application/zip > at > org.dspace.sword2.DSpaceSwordAPI.isAcceptable(DSpaceSwordAPI.java:228) > at > org.dspace.sword2.CollectionDepositManagerDSpace.createNewFromBinary(CollectionDepositManagerDSpace.java:218) > at > org.dspace.sword2.CollectionDepositManagerDSpace.createNew(CollectionDepositManagerDSpace.java:112) > at org.swordapp.server.CollectionAPI.post(CollectionAPI.java:158) > at > org.swordapp.server.servlets.CollectionServletDefault.doPost(CollectionServletDefault.java:48) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:637) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) > at > org.apache.catalina.valves.RequestDumperValve.invoke(RequestDumperValve.java:156) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:291) > at > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859) > at > org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:602) > at > org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489) > at java.lang.Thread.run(Thread.java:662) > </sword:verboseDescription></sword:error> > > Is it correct to POST the package to the Collection, or should I first > create an entry and then post the package to the IRI of the newly created > entry? > > Thank you again for the help, > > 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 > > > -- Richard Jones, Founder, Cottage Labs t: @richard_d_jones, @cottagelabs w: http://cottagelabs.com |
|
From: Marco F. <mar...@ee...> - 2012-03-26 15:13:31
|
Hi Richard, (apologies for the long message) I finally managed to POST bitstreams to an item that I previously created with an ATOM entry, using the Edit media IRI. Thanks for the help! However, there are a couple of things that don't work quite right: - when I create the entry with metadata only, the bundle ORIGINAL is create, and it is empty. When I POST a new file, a new ORIGINAL bundle is created, and the file copied into it, and this is repeated for every file I POST. Normally, all the bitstreams should go into the same ORIGINAL folder (the first one, which remains empty). This causes some problems in the visualisation of the item. - the MIME type and description of the file don't appear in the bitstream information, can they be sent somehow? For the MIME type, in fact, when I POST the file, I always have to specify "application/zip" in the headers for it to work (and not the real MIME type), I suppose because the bitstream in compressed when it is sent. - is there a way to POST to a license file the LICENSE or CCLICENSE bundles? I guess this would solve the ORIGINAL folder as well? I realise that all these problems might be solved by using a METSDSpaceSIP package instead, but I couldn't manage to ingest one, I keep getting Error 415: Unacceptable content. Here are the headers I am posting (to the Collection IRI): 'Content-Length': '33777', 'Content-Disposition': 'attachment; filename=example.zip', 'In-Progress': 'true', 'Content-MD5': '2b25f82ba67284461d4a481d7a06dd28', 'Packaging': 'http://purl.org/net/sword/package/METSDSpaceSIP', 'Content-Type': 'application/zip' and the error message from the server: <?xml version="1.0" encoding="ISO-8859-1"?> <sword:error href="http://purl.org/net/sword/error/ErrorContent" xmlns:sword="http://purl.org/net/sword/terms/"><atom:title xmlns:atom="http://www.w3.org/2005/Atom"/><atom:updated xmlns:atom="http://www.w3.org/2005/Atom">2012-03-26T14:43:03Z</atom:updated><atom:generator uri="http://www.dspace.org/ns/sword/2.0/" version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">rdm...@gm...</atom:generator><sword:treatment>Processing failed</sword:treatment><atom:summary xmlns:atom="http://www.w3.org/2005/Atom">Unacceptable content type in deposit request: application/zip</atom:summary><sword:verboseDescription>org.swordapp.server.SwordError: Unacceptable content type in deposit request: application/zip at org.dspace.sword2.DSpaceSwordAPI.isAcceptable(DSpaceSwordAPI.java:228) at org.dspace.sword2.CollectionDepositManagerDSpace.createNewFromBinary(CollectionDepositManagerDSpace.java:218) at org.dspace.sword2.CollectionDepositManagerDSpace.createNew(CollectionDepositManagerDSpace.java:112) at org.swordapp.server.CollectionAPI.post(CollectionAPI.java:158) at org.swordapp.server.servlets.CollectionServletDefault.doPost(CollectionServletDefault.java:48) at javax.servlet.http.HttpServlet.service(HttpServlet.java:637) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.valves.RequestDumperValve.invoke(RequestDumperValve.java:156) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:291) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:602) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489) at java.lang.Thread.run(Thread.java:662) </sword:verboseDescription></sword:error> Is it correct to POST the package to the Collection, or should I first create an entry and then post the package to the IRI of the newly created entry? Thank you again for the help, 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 |
|
From: Richard J. <ri...@co...> - 2012-03-22 17:20:39
|
Hi Marco,
You should be able to POST to either of those. They only differ on GET.
Cheers,
Richard
On 22 March 2012 16:20, Marco Fabiani <mar...@ee...> wrote:
>
> Hi Stuart,
>
> I *think* (Richard Jones cc’d can confirm this) that the problem is
> because you are POSTing the file to the Edit-IRI rather than the
> EditMedia-IRI. The Edit-IRI is the object as a whole, but since you are
> adding a file, this needs to go to the Edit Media IRI (the container of
> files) instead.****
>
>
> from the DSpace server I get two Edit Media IRI:
>
> Link rel:'edit-media' -- [
> {'href': 'http://c4dm.eecs.qmul.ac.uk/smdmrd-test/swordv2/edit-media/171',
> 'type': 'application/zip'},
> {'href': '
> http://c4dm.eecs.qmul.ac.uk/smdmrd-test/swordv2/edit-media/171.atom',
> 'type': 'application/atom+xml; type=feed'}]
>
> Do you know what is the difference? Which one should I use?
>
> Cheers
> Marco
>
>
>
>
> Hello Stuart,****
> ** **
>
> Are you able to turn on some sort of debugging so we can see the HTTP
> request + headers that are being sent?****
>
> ** **
> here is the history of HTTP requests, and the replies from the server (I
> am in debug mode in the Python httplib2):****
> ** **
> * First I create a metadata entry only:****
> ** **
> send:****
> 'POST /smdmrd-test/swordv2/collection/123456789/108 HTTP/1.1\r\n****
> Host: c4dm.eecs.qmul.ac.uk\r\n****
> in-progress: true\r\n****
> content-length: 621\r\n****
> content-type: application/atom+xml;type=entry\r\n****
> accept-encoding: gzip, deflate\r\n****
> user-agent: Python-httplib2/0.7.2 (gzip)\r\n****
> authorization: Basic
> bWFyY28uZmFiaWFuaUBlZWNzLnFtdWwuYWMudWs6aG91c2Vjb3VjaDI5\r\n****
> \r\n****
> <?xml version="1.0"?><ns0:entry xmlns:ns0="http://www.w3.org/2005/Atom"
> xmlns:ns1="http://purl.org/dc/terms/">\n <ns0:generator uri="
> http://bitbucket.org/beno/python-sword2" version="0.1"
> />\n<ns1:title>Test SWORD deposit</ns1:title><ns1:abstract>My
> Thesis</ns1:abstract><ns1:isReferencedBy>Myself (2009). Another test
> deposit.</ns1:isReferencedBy><ns0:updated>2012-03-22T14:27:30.211672</ns0:updated><ns1:creator>Fabiani,
> Marco</ns1:creator><ns1:type>Dataset</ns1:type><ns1:subject>test</ns1:subject><ns1:publisher>C4DM</ns1:publisher><ns1:created>2009</ns1:created><ns1:creator>Pallino,
> Pinco</ns1:creator></ns0:entry>'****
> ** **
> * and the server does its job:****
> ** **
> reply: 'HTTP/1.1 201 Created\r\n'****
> header: Date: Thu, 22 Mar 2012 14:27:03 GMT****
> header: Server: Apache-Coyote/1.1****
> header: Location: http://c4dm.eecs.qmul.ac.uk/smdmrd-test/swordv2/edit/158
> ****
> header: Last-Modified: Thu, 22 Mar 2012 14:27:04 GMT****
> header: Content-MD5: 977eda8ee9b6bc8ca4ee7a8ea6f667ee****
> header: Content-Type: application/atom+xml;type=entry****
> header: Transfer-Encoding: chunked****
> ** **
> * Then I try to add a file to this entry:****
> ** **
> send:****
> 'POST /smdmrd-test/swordv2/edit/158 HTTP/1.1\r\n****
> Host: c4dm.eecs.qmul.ac.uk\r\n****
> content-length: 11083\r\n****
> accept-encoding: gzip, deflate\r\n****
> content-disposition: attachment; filename=foo.pdf\r\n****
> in-progress: false\r\n****
> content-md5: 348fb9ceae472a41df626a1610d764c5\r\n****
> packaging: http://purl.org/net/sword/package/Binary\r\n<http://purl.org/net/sword/package/Binary/r/n>
> ****
> user-agent: Python-httplib2/0.7.2 (gzip)\r\n****
> content-type: application/pdf\r\n****
> authorization: Basic
> bWFyY28uZmFiaWFuaUBlZWNzLnFtdWwuYWMudWs6aG91c2Vjb3VjaDI5\r\n****
> \r\n****
> %PDF-1.4\n****
> %\xc3\xa4\xc3\xbc\xc3\xb6\xc3\x9f\n2 0 obj\n<</Length 3 0
> R/Filter/FlateDecode>>\nstream\nx\x9c%\xc9;\n\x800\x10\x05\xc0~O\xf1j\x8b\xf5E\x93\x98\x80X\x08\xda\x0b\x0b^\xc0\x0fX\x08\xdax}\x05\x99r\x88G.\x10T\x87\x90\x83\xd6H\xdei\xc6\xbdb.p\xfe\xf7\xb9w\xe9MB\xd4\x84\xc6g\x8d\xb0\x05\xe5\xe8\xe0\t\xdb\xd0\xd2\xb1bM\xcf\xd0\xc1\x0e\x19L&\x99\xf0\x02\x97r\x13\x93\nendstream\nendobj\n\n3
> 0 obj\n92\nendobj\n\n5 0 obj\n<</Length 6 0 R/Filter/FlateDecode/Length1
> 20360>>\nstream\nx\x9c\xed|{|T\xd5\xb9\xe8\xb7\xf6\xde\xf3\xc8c\x92I
> \xef\x84\xd9\x93\x9d\xc9\x83\xc9;`H\x18\xcd\x84<0\x04H\x84\x00\t\x95\x92\x9d\x99\x9ddd\x92\x19\xe6\x91\x18\xeai\xb0\xd6W\xd0\xc2\xa9\xd6G\x8f\x05Z\x0fj\x0b\xd6IP\x1b\xd0#\xe8\xbd\xb5\xa7O|\xd5jk+\xbd\xd5\xb6\xb6\xa5\x87Z\xb5\xed\x112\xe7[k\xef\xc9\x03\xd0\xdas\xcf\x1f\xf7\xf7\xbb\xcc\xceZ\xeb[k}\xeb[\xdf{\xed=;I(\x10V
> ****
> …****
> …****
> …****
> 20070829203726+01\'00\')>>\nendobj\n\nxref\n0 14\n0000000000 65535 f
> \n0000010169 00000 n \n0000000019 00000 n \n0000000182 00000 n \n0000010312
> 00000 n \n0000000201 00000 n \n0000009370 00000 n \n0000009391 00000 n
> \n0000009587 00000 n \n0000009901 00000 n \n0000010082 00000 n \n0000010115
> 00000 n \n0000010411 00000 n \n0000010459 00000 n \ntrailer\n<</Size
> 14/Root 12 0 R\n/Info 13 0 R\n/ID [
> <5F3776DDFB6D4A2230F9DA4444B836BE>\n<5F3776DDFB6D4A2230F9DA4444B836BE>
> ]\n>>\nstartxref\n10646\n%%EOF\n'****
> ** **
> * and the server replies:****
> ** **
> reply: 'HTTP/1.1 400 Bad Request\r\n'****
> header: Date: Thu, 22 Mar 2012 14:27:03 GMT****
> header: Server: Apache-Coyote/1.1****
> header: Content-Type: text/xml****
> header: Connection: close****
> header: Transfer-Encoding: chunked****
> ** **
> * The content of the reply is:****
> ** **
> <?xml version="1.0" encoding="ISO-8859-1"?>****
> <sword:error href="http://purl.org/net/sword/error/ErrorBadRequest"
> xmlns:sword="http://purl.org/net/sword/terms/"><atom:title xmlns:atom="
> http://www.w3.org/2005/Atom"/><atom:updated xmlns:atom="
> http://www.w3.org/2005/Atom">2012-03-22T14:27:04Z</atom:updated><atom:generator
> uri="http://www.dspace.org/ns/sword/2.0/" version="2.0" xmlns:atom="
> http://www.w3.org/2005/Atom">rdm...@gm...</atom:generator><sword:treatment>Processing
> failed</sword:treatment><atom:summary xmlns:atom="
> http://www.w3.org/2005/Atom">
> http://purl.org/net/sword/error/ErrorBadRequest</atom:summary><sword:verboseDescription>org.swordapp.server.SwordError:
> http://purl.org/net/sword/error/ErrorBadRequest****
> at
> org.swordapp.server.ContainerAPI.post(ContainerAPI.java:342)****
> at
> org.swordapp.server.servlets.ContainerServletDefault.doPost(ContainerServletDefault.java:62)
> ****
> at
> javax.servlet.http.HttpServlet.service(HttpServlet.java:637)****
> at
> javax.servlet.http.HttpServlet.service(HttpServlet.java:717)****
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> ****
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> ****
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
> ****
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> ****
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> ****
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> ****
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> ****
> at
> org.apache.catalina.valves.RequestDumperValve.invoke(RequestDumperValve.java:156)
> ****
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:291)
> ****
> at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859)
> ****
> at
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:602)
> ****
> at
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)***
> *
> at java.lang.Thread.run(Thread.java:662)****
> </sword:verboseDescription></sword:error>****
> ** **
> Any idea? At least I would like to understand if it is a problem with the
> python module or with the SWORDv2 server in DSpace…****
> ** **
> Cheers,****
> ** **
> Marco****
>
>
> ****
> Thanks,
>
>
> Stuart
>
>
>
> Hello,
>
> I have been trying for sometime now to ingest data into our DSpace test
> repository using SWORD 2, but with little success.
> Specifically, I have been using the python-sword2 module, and followed the
> examples there. I can successfully create an item submitting only metadata
> ("Creating a Resource with an Atom Entry"), but when I try to send a file
> (binary), I keep getting errors from the server.
>
> If I try the multipart submission way, I get a 500 error with this cause:
> "Attempting to store and check deposit which has no input stream"
>
> If I try to append the file to an item I previously created with the Atom
> Entry, I get a 400 errorhttp://purl.org/net/sword/error/ErrorBadRequest,
> that goes down to here:
>
>
> at
> org.swordapp.server.ContainerAPI.post(ContainerAPI.java:342)
> at
> org.swordapp.server.servlets.ContainerServletDefault.doPost(ContainerServletDefault.java:62)
> at
> javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
> at
> javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> at
> org.apache.catalina.valves.RequestDumperValve.invoke(RequestDumperValve.java:156)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:291)
> at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859)
> at
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:602)
> at
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
> at java.lang.Thread.run(Thread.java:662)
>
> I know this is very little information to get some help, but I just
> started using DSpace and SWORD, so I don't really know if it is a problem
> with DSpace (maybe in the configuration), with my python-sword2 requests or
> something else, so I would appreciate if you could point me to the right
> direction.
>
> Thank you in advance for any help,
> 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
>
>
> --
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
>
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> 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
|
13 messages has been excluded from this view by a project administrator.
