sword-app-tech Mailing List for SWORD (Page 12)

Brought to you by: adrianstevenson, glen_robson, jallinson, jimdowning, and 4 others

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

Flat | Threaded

<< < 1 .. 10 11 12 13 14 .. 33 > >> (Page 12 of 33)

[sword-app-tech] Demo client NoClassDefFoundError PropertyConfigurator

From: Joke P. <jok...@da...> - 2012-04-17 12:04:30

I downloaded sword-client-1.1.zip from http://sourceforge.net/projects/sword-app/files/SWORD%20Java%20Library/
Went to the unzipped directory and launched swordclient.sh

I have been playing with the classpath but keep getting the stack trace below. Anny suggestion what I might have overlooked?

Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/log4j/PropertyConfigurator
        at org.purl.sword.client.ClientFactory.<init>(ClientFactory.java:56)
        at org.purl.sword.client.ClientFactory.main(ClientFactory.java:183)
Caused by: java.lang.ClassNotFoundException: org.apache.log4j.PropertyConfigurator
        at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
        ... 2 more


With kind regards,
Joke Pol

Developer
+31(0)6 201 055 18
jok...@da...

Data Archiving and Networked Services (DANS)
DANS offers durable access to digital research data.
Please visit http://www.dans.knaw.nl for more information and contact details.
DANS is an institute of KNAW and NWO.

Re: [sword-app-tech] suggested move to github

From: Richard J. <ri...@co...> - 2012-04-17 11:10:46

Hi Folks,

I did a basic import of the JavaClient2.0 part of the svn repository:

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

And tagged a 0.9.1 release

I've been looking into migrate options, and have found that git-svn is
sufficient for stuff which has not been previously branched or tagged, but
in cases where that has happened we may want to look at svn2git instead
(which I currently can't make work):

https://github.com/nirvdrum/svn2git

Cheers,

All development on the JavaClient2.0 should now migrate to the github.
 Please send me your github user details if you think you should have
access to the repositories we are migrating there.

I will continue to migrate the svn over time, although may not bother with
the 1.x versions of the code.

Cheers,

Richard

On 3 April 2012 16:40, Mark Diggory <mdi...@at...> wrote:

> There is an option in the git svn importer to not expect the
> trunk/tags/branches in the initial directory of the project being imported.
>   I expect that there has to be some way to still map the
> tags/branches/trunk for projects... something like:
>
>
> http://stackoverflow.com/questions/3075171/importing-subversion-to-git-problem-with-subpaths
>
> I would try to work out the mappings on export from svn to git rather than
> retrospectively.
>
> The repos I created can be deleted if they are not ideal for your interest.
>
> Mark
>
>
> [image: @mire Inc.]
> *Mark Diggory (Schedule a Meeting <http://bit.ly/xNePTl>)*
> *2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010*
> *Esperantolaan 4, Heverlee 3001, Belgium*
> http://www.atmire.com
>
> On Tuesday, April 3, 2012 at 1:12 AM, Richard Jones wrote:
>
> Hi Guys,
>
> Ok, sounds like a go to me :)
>
> I was thinking that the best way to structure the github repos would be
> via a SWORD organisation (which I see Mark has already done) with a repo
> for each output (again, as per Mark's initial work).  I thought to just
> export the trunk from the original svn, though, rather than keeping the svn
> structure (trunk, tags, branches), etc.  Not sure how easy it will be to
> retrospectively tag any releases, but there's certainly a command to do it.
>
> How does that sound?
>
> Cheers,
>
> R
>
> On 3 April 2012 07:24, Mark Diggory <mdi...@at...> wrote:
>
>  That was pretty easy... couple repos ported with authors intact... I gave
> rights over for the Sword1.1 repo I originally made.  Probably want to
> reimport it with authors files setup correctly.
>
> https://github.com/swordapp
>
> Mark
>
>
> [image: @mire Inc.]
> *Mark Diggory (Schedule a Meeting <http://bit.ly/xNePTl>)*
> *2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010*
> *Esperantolaan 4, Heverlee 3001, Belgium*
> http://www.atmire.com
>
> On Monday, April 2, 2012 at 11:17 AM, LEWIS Stuart wrote:
>
> Sounds good to me too - that's where all the cool kids play these days!
> (so I'm told! ;)
>
> There are some other SWORD related projects in github too:
>
> https://github.com/stuartlewis/EasyDeposit
> https://github.com/stuartlewis/swordapp-php-library
> https://github.com/stuartlewis/swordappv2-php-library
> https://github.com/kshepherd/RightClickDeposit
> https://github.com/oerpub/
>
> Cheers,
>
>
> Stuart
>
>
> --
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
>
> -----Original Message-----
> From: Mark Diggory [mailto:mdi...@at... <mdi...@at...>]
> Sent: 02 April 2012 18:41
> To: Richard Jones
> Cc: <swo...@li...>
> Subject: Re: [sword-app-tech] suggested move to github
>
> I subversively did some thing similar in my own github account to get the
> 1.1 SWORD jar into maven.
>
> https://github.com/mdiggory/SWORDv1.1
>
> I'd enjoy assisting this along with you.
>
> Mark
>
>
> On Mon, Apr 2, 2012 at 9:25 AM, Richard Jones <ri...@co...>
> wrote:
>
> Hi Folks,
>
> During one of my many bouts of frustration with sourceforge, I started
> to wonder if there's any mileage in moving to github?  Would anyone
> object?  If not, I'll look into doing this at some point soon.
>
> Cheers,
>
> Richard
>
>
> --
>
> Richard Jones,
>
> Founder, Cottage Labs
> t: @richard_d_jones, @cottagelabs
> w: http://cottagelabs.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
>
>
>
>
> --
>
> 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
>
> ------------------------------------------------------------------------------
> 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
>
>
>
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> _______________________________________________
> sword-app-tech mailing list
> swo...@li...
> https://lists.sourceforge.net/lists/listinfo/sword-app-tech
>
>
>
>
> --
>
> Richard Jones,
>
> Founder, Cottage Labs
> t: @richard_d_jones, @cottagelabs
> w: http://cottagelabs.com
>
>
>
>


-- 

Richard Jones,

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

Re: [sword-app-tech] Retrieving workflow id of deposited package

From: LEWIS S. <Stu...@ed...> - 2012-04-17 10:09:37

Hi Hayden,

Unfortunately not - from a SWORD point of view, this is just a URL.  The SWORD specification does not describe how URLs should encode item identifiers, so this is an implementation choice for the repository.  Therefore the client library can't know how to extract the ID.

Thanks,


Stuart



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


-----Original Message-----
From: Hayden Young [mailto:hay...@wi...] 
Sent: 17 April 2012 05:34
To: swo...@li...
Subject: [sword-app-tech] Retrieving workflow id of deposited package

Is there a simple method of retrieve the workflow id of a deposited package via the PHP Sword Client?

I can access $SwordAppEntry::sac_id but that gives me the full url to the edit endpoint:

<id>http://ubuntu1104.wijiti.local:8080/i/saber/swordv2/edit/23</id>

Is there a variable which returns just the id portion?

E.g.

$response->id

<id>23</id>

Cheers


Hayden

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

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


------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
sword-app-tech mailing list
swo...@li...
https://lists.sourceforge.net/lists/listinfo/sword-app-tech

[sword-app-tech] Retrieving workflow id of deposited package

From: Hayden Y. <hay...@wi...> - 2012-04-17 05:00:45

Is there a simple method of retrieve the workflow id of a deposited 
package via the PHP Sword Client?

I can access $SwordAppEntry::sac_id but that gives me the full url to 
the edit endpoint:

<id>http://ubuntu1104.wijiti.local:8080/i/saber/swordv2/edit/23</id>

Is there a variable which returns just the id portion?

E.g.

$response->id

<id>23</id>

Cheers


Hayden

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

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

Re: [sword-app-tech] migrate DSpace to Islandora using SWORD

From: Ying J. <Yin...@ri...> - 2012-04-09 15:05:47

Hi Glen,

Thanks so much for the tips. I will try it out.

Best,
Ying

On Apr 6, 2012, at 6:38 PM, Glen Robson wrote:

> Hi Ying,
>
> If you wanted to customise the layout of the Fedora object you could  
> create a Java class that implements:
>
> org.purl.sword.server.fedora.fileHandlers.FileHandler
>
> and add an entry to the following in the config:
>
>        <file_handlers>
>                 <!--
>                         Group of classes which handle ingesting  
> specific files into Fedora
>                         You can add your own classes as long as they  
> implement
>                                  
> org.purl.sword.server.fedora.fileHandlers.FileHandler interface
>                         and have a default constructor
>                 -->
>                 <handler  
> class="org.purl.sword.server.fedora.fileHandlers.JpegHandler" />
>                 <handler  
> class="org.purl.sword.server.fedora.fileHandlers.METSFileHandler" />
>                 <handler  
> class="org.purl.sword.server.fedora.fileHandlers.ZipFileHandler" />
>                 <handler  
> class 
> ="org.purl.sword.server.fedora.fileHandlers.ZipMETSFileHandler" />
>         </file_handlers>
>
> There are two methods to implement:
>
> public boolean isHandled(final String pMimeType, final String  
> pPackaging);
>
> which determines if the handler should be used for the supplied  
> packaging and mime type. The other method is:
>
> public SWORDEntry ingestDepost(final DepositCollection pDeposit,  
> final ServiceDocument pServiceDocument) throws            
> SWORDException;
>
> Which handles the ingest of the SWORD deposit. You could look at the  
> METSFileHandler which handles the ingest of a standalone METS file  
> as a basis for your extension.
>
> Thanks
>
> Glen
>
> On 6 Apr 2012, at 22:46, Ying Jin wrote:
>
>> Hi Glen and Mark,
>>
>> Here I'd like to give a summary of all my testing results and see  
>> if that makes sense to use SWORD in such situation -
>> (Note, I'm using Fedora SWORD 1.2)
>>
>> 1. My first testing was getting a zipped DSpace SIP package and  
>> upload zip (mimetype as application/zip) -
>>
>> 	1> Using METSDSpaceSIP package, uploaded zip file as it is
>> 	2> Using METS package, uploaded content files only, in my case,  
>> three pdf files, and mets file was ignored
>>
>> 2. getting a zipped DSpace AIP package, upload using METS package,  
>> and mimetype as application/zip
>> 	got ArrayIndexOutOfBoundsException
>>
>> 3. Using mets.xml extracted from DSpace AIP package (added absolute  
>> file path to the file), upload using METS package, mimetype is text/ 
>> xml
>> 	Here is the list of datastreams in fedora after uploading
>> 	1> DC - Dublin Core Metadata
>> 	2> RELS-EXT
>> 	3> MODS (extracted from ingested mets file)
>> 	4> DIM (extracted from ingested mets file)
>> 	5> bitstream_2 (ingested file in mets file section)
>> 	6> METS (METS as it was deposited)
>>
>> It looks like the third method is suitable to use though I need to  
>> fix the file path. However, I realize that we also need to remove  
>> thumbnail and extracted txt  so they won't be uploaded to fedora  
>> and probably provenance information too. Having an xslt to pre- 
>> process AIP mets before uploading might be a good idea. Of course,  
>> I also need to make sure islandora is happy with the format.
>>
>>
>> Thanks,
>> Ying
>>
>> On Mar 30, 2012, at 6:38 PM, Glen Robson wrote:
>>
>>> Hi Mark,
>>>
>>> I think I've misunderstood what Ying was trying to do, I though it  
>>> was a plain METS document being submitted rather than a METS  
>>> document in a zip file which was why you would need a http URL or  
>>> relative file URL for the sword-fedora plugin to find what it  
>>> needs to ingest. If you want to submit a zip file with a METS  
>>> manifest you could use a mime-type of application/zip and a  
>>> packaging of http://www.loc.gov/METS/ and looking at the code it  
>>> will add any dmdSecs as metadata datastreams in Fedora and any  
>>> files it finds in the zip file.
>>>
>>> Its not the ideal way of doing it as you mention below, ideally it  
>>> should take the METS file as a manifest and understand the myriad  
>>> of URL possibilities and only ingest the items mentioned in the  
>>> METS file but the way it works currently may be enough to get Ying  
>>> started. As it currently doesn't parse the METS:file section it  
>>> shouldn't matter if the LOCTYPE is URL or something else (assuming  
>>> I'm reading the code correctly).
>>>
>>> Sorry for the confusion but hope this is a possible solution.
>>>
>>> Thanks
>>>
>>> Glen
>>>
>>> On 30 Mar 2012, at 23:05, Mark Diggory wrote:
>>>
>>>> I assume the file at that point is in some tomcat temp directory  
>>>> and expanded into a directory with a list of files.  Changing the  
>>>> AIP on the DSpace side is either changing java code and  
>>>> rebuilding, or transforming the packages after they have been  
>>>> generated.
>>>>
>>>> My point is that the logic of xlink is that like its html  
>>>> conterparts, an IRI/URL may be a path relative to the document.   
>>>> In such cases, it really should not matter "where" the document  
>>>> resides.
>>>>
>>>> .../mypackage/mets.xml
>>>> .../mypackage/bitstream_613090.jpeg
>>>>
>>>> http://host/mypackage/mets.xml
>>>> http://host/mypackage/bitstream_613090.jpeg
>>>>
>>>> zip:file://./mypackage.zip!/bitstream_613090.jpeg
>>>>
>>>> These are all valid IRI/URL
>>>>
>>>> Maybe I'm just arguing semantics here, but the specified behavior  
>>>> for LOCTYPE = URL shouldn't force users to only be able to use a  
>>>> subset of XLINK/IRI/URL possibilities in METS.  In fact, for  
>>>> proper portability, relative linking is a necessity.  This seems  
>>>> a bug in the Fedora METS import code.
>>>>
>>>> Mark
>>>>
>>>> If its inside html, METS or some other xml, the definition  
>>>> applies that the applicatin should interpret relative xlinks as  
>>>> relative to the document, regardless of the protocol (file, http,  
>>>> ftp, ...)
>>>>
>>>> On Fri, Mar 30, 2012 at 2:45 PM, Glen Robson <gle...@ll... 
>>>> > wrote:
>>>> Hi Mark & Ying,
>>>>
>>>> I think if you use a local file rather than a http URL then it  
>>>> will be relative to something unhelpful like the tomcat directory  
>>>> where the fedora-sword package is installed. The best solution is  
>>>> probably to change the links to http URLs if you can and if not  
>>>> if you could change the file paths to absolute (assuming the  
>>>> files are on the same server the fedora sword web app is  
>>>> installed).
>>>>
>>>> I hope that helps.
>>>>
>>>> Cheers
>>>>
>>>> Glen
>>>>
>>>>
>>>> -- 
>>>>
>>>> Mark Diggory (Schedule a Meeting)
>>>> 2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010
>>>> Esperantolaan 4, Heverlee 3001, Belgium
>>>> http://www.atmire.com
>>>>
>>>>
>>>
>>
>

Re: [sword-app-tech] migrate DSpace to Islandora using SWORD

From: Glen R. <gle...@ll...> - 2012-04-06 23:38:45

Hi Ying,

If you wanted to customise the layout of the Fedora object you could create a Java class that implements:

org.purl.sword.server.fedora.fileHandlers.FileHandler

and add an entry to the following in the config:

       <file_handlers>
                <!--
                        Group of classes which handle ingesting specific files into Fedora 
                        You can add your own classes as long as they implement 
                                org.purl.sword.server.fedora.fileHandlers.FileHandler interface 
                        and have a default constructor
                -->
                <handler class="org.purl.sword.server.fedora.fileHandlers.JpegHandler" />
                <handler class="org.purl.sword.server.fedora.fileHandlers.METSFileHandler" />
                <handler class="org.purl.sword.server.fedora.fileHandlers.ZipFileHandler" />
                <handler class="org.purl.sword.server.fedora.fileHandlers.ZipMETSFileHandler" />
        </file_handlers>

There are two methods to implement:

public boolean isHandled(final String pMimeType, final String pPackaging);

which determines if the handler should be used for the supplied packaging and mime type. The other method is:

public SWORDEntry ingestDepost(final DepositCollection pDeposit, final ServiceDocument pServiceDocument) throws           SWORDException;

Which handles the ingest of the SWORD deposit. You could look at the METSFileHandler which handles the ingest of a standalone METS file as a basis for your extension.

Thanks

Glen

On 6 Apr 2012, at 22:46, Ying Jin wrote:

> Hi Glen and Mark,
> 
> Here I'd like to give a summary of all my testing results and see if that makes sense to use SWORD in such situation -
> (Note, I'm using Fedora SWORD 1.2)
> 
> 1. My first testing was getting a zipped DSpace SIP package and upload zip (mimetype as application/zip) -
> 
> 	1> Using METSDSpaceSIP package, uploaded zip file as it is
> 	2> Using METS package, uploaded content files only, in my case, three pdf files, and mets file was ignored
> 
> 2. getting a zipped DSpace AIP package, upload using METS package, and mimetype as application/zip
> 	got ArrayIndexOutOfBoundsException
> 
> 3. Using mets.xml extracted from DSpace AIP package (added absolute file path to the file), upload using METS package, mimetype is text/xml   
> 	Here is the list of datastreams in fedora after uploading
> 	1> DC - Dublin Core Metadata
> 	2> RELS-EXT
> 	3> MODS (extracted from ingested mets file)
> 	4> DIM (extracted from ingested mets file)
> 	5> bitstream_2 (ingested file in mets file section)
> 	6> METS (METS as it was deposited)
> 
> It looks like the third method is suitable to use though I need to fix the file path. However, I realize that we also need to remove thumbnail and extracted txt  so they won't be uploaded to fedora and probably provenance information too. Having an xslt to pre-process AIP mets before uploading might be a good idea. Of course, I also need to make sure islandora is happy with the format.
> 
> 
> Thanks,
> Ying
> 
> On Mar 30, 2012, at 6:38 PM, Glen Robson wrote:
> 
>> Hi Mark,
>> 
>> I think I've misunderstood what Ying was trying to do, I though it was a plain METS document being submitted rather than a METS document in a zip file which was why you would need a http URL or relative file URL for the sword-fedora plugin to find what it needs to ingest. If you want to submit a zip file with a METS manifest you could use a mime-type of application/zip and a packaging of http://www.loc.gov/METS/ and looking at the code it will add any dmdSecs as metadata datastreams in Fedora and any files it finds in the zip file. 
>> 
>> Its not the ideal way of doing it as you mention below, ideally it should take the METS file as a manifest and understand the myriad of URL possibilities and only ingest the items mentioned in the METS file but the way it works currently may be enough to get Ying started. As it currently doesn't parse the METS:file section it shouldn't matter if the LOCTYPE is URL or something else (assuming I'm reading the code correctly).
>> 
>> Sorry for the confusion but hope this is a possible solution.
>> 
>> Thanks
>> 
>> Glen
>> 
>> On 30 Mar 2012, at 23:05, Mark Diggory wrote:
>> 
>>> I assume the file at that point is in some tomcat temp directory and expanded into a directory with a list of files.  Changing the AIP on the DSpace side is either changing java code and rebuilding, or transforming the packages after they have been generated.
>>> 
>>> My point is that the logic of xlink is that like its html conterparts, an IRI/URL may be a path relative to the document.  In such cases, it really should not matter "where" the document resides. 
>>> 
>>> .../mypackage/mets.xml
>>> .../mypackage/bitstream_613090.jpeg
>>> 
>>> http://host/mypackage/mets.xml
>>> http://host/mypackage/bitstream_613090.jpeg
>>> 
>>> zip:file://./mypackage.zip!/bitstream_613090.jpeg
>>> 
>>> These are all valid IRI/URL
>>> 
>>> Maybe I'm just arguing semantics here, but the specified behavior for LOCTYPE = URL shouldn't force users to only be able to use a subset of XLINK/IRI/URL possibilities in METS.  In fact, for proper portability, relative linking is a necessity.  This seems a bug in the Fedora METS import code.
>>> 
>>> Mark
>>> 
>>> If its inside html, METS or some other xml, the definition applies that the applicatin should interpret relative xlinks as relative to the document, regardless of the protocol (file, http, ftp, ...)
>>> 
>>> On Fri, Mar 30, 2012 at 2:45 PM, Glen Robson <gle...@ll...> wrote:
>>> Hi Mark & Ying,
>>> 
>>> I think if you use a local file rather than a http URL then it will be relative to something unhelpful like the tomcat directory where the fedora-sword package is installed. The best solution is probably to change the links to http URLs if you can and if not if you could change the file paths to absolute (assuming the files are on the same server the fedora sword web app is installed).
>>> 
>>> I hope that helps.
>>> 
>>> Cheers
>>> 
>>> Glen
>>> 
>>> 
>>> -- 
>>>  
>>> Mark Diggory (Schedule a Meeting)
>>> 2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010
>>> Esperantolaan 4, Heverlee 3001, Belgium
>>> http://www.atmire.com
>>> 
>>> 
>> 
>

Re: [sword-app-tech] migrate DSpace to Islandora using SWORD

From: Ying J. <Yin...@ri...> - 2012-04-06 21:46:40

Hi Glen and Mark,

Here I'd like to give a summary of all my testing results and see if  
that makes sense to use SWORD in such situation -
(Note, I'm using Fedora SWORD 1.2)

1. My first testing was getting a zipped DSpace SIP package and upload  
zip (mimetype as application/zip) -

	1> Using METSDSpaceSIP package, uploaded zip file as it is
	2> Using METS package, uploaded content files only, in my case, three  
pdf files, and mets file was ignored

2. getting a zipped DSpace AIP package, upload using METS package, and  
mimetype as application/zip
	got ArrayIndexOutOfBoundsException

3. Using mets.xml extracted from DSpace AIP package (added absolute  
file path to the file), upload using METS package, mimetype is text/xml
	Here is the list of datastreams in fedora after uploading
	1> DC - Dublin Core Metadata
	2> RELS-EXT
	3> MODS (extracted from ingested mets file)
	4> DIM (extracted from ingested mets file)
	5> bitstream_2 (ingested file in mets file section)
	6> METS (METS as it was deposited)

It looks like the third method is suitable to use though I need to fix  
the file path. However, I realize that we also need to remove  
thumbnail and extracted txt  so they won't be uploaded to fedora and  
probably provenance information too. Having an xslt to pre-process AIP  
mets before uploading might be a good idea. Of course, I also need to  
make sure islandora is happy with the format.


Thanks,
Ying

On Mar 30, 2012, at 6:38 PM, Glen Robson wrote:

> Hi Mark,
>
> I think I've misunderstood what Ying was trying to do, I though it  
> was a plain METS document being submitted rather than a METS  
> document in a zip file which was why you would need a http URL or  
> relative file URL for the sword-fedora plugin to find what it needs  
> to ingest. If you want to submit a zip file with a METS manifest you  
> could use a mime-type of application/zip and a packaging of http://www.loc.gov/METS/ 
>  and looking at the code it will add any dmdSecs as metadata  
> datastreams in Fedora and any files it finds in the zip file.
>
> Its not the ideal way of doing it as you mention below, ideally it  
> should take the METS file as a manifest and understand the myriad of  
> URL possibilities and only ingest the items mentioned in the METS  
> file but the way it works currently may be enough to get Ying  
> started. As it currently doesn't parse the METS:file section it  
> shouldn't matter if the LOCTYPE is URL or something else (assuming  
> I'm reading the code correctly).
>
> Sorry for the confusion but hope this is a possible solution.
>
> Thanks
>
> Glen
>
> On 30 Mar 2012, at 23:05, Mark Diggory wrote:
>
>> I assume the file at that point is in some tomcat temp directory  
>> and expanded into a directory with a list of files.  Changing the  
>> AIP on the DSpace side is either changing java code and rebuilding,  
>> or transforming the packages after they have been generated.
>>
>> My point is that the logic of xlink is that like its html  
>> conterparts, an IRI/URL may be a path relative to the document.  In  
>> such cases, it really should not matter "where" the document resides.
>>
>> .../mypackage/mets.xml
>> .../mypackage/bitstream_613090.jpeg
>>
>> http://host/mypackage/mets.xml
>> http://host/mypackage/bitstream_613090.jpeg
>>
>> zip:file://./mypackage.zip!/bitstream_613090.jpeg
>>
>> These are all valid IRI/URL
>>
>> Maybe I'm just arguing semantics here, but the specified behavior  
>> for LOCTYPE = URL shouldn't force users to only be able to use a  
>> subset of XLINK/IRI/URL possibilities in METS.  In fact, for proper  
>> portability, relative linking is a necessity.  This seems a bug in  
>> the Fedora METS import code.
>>
>> Mark
>>
>> If its inside html, METS or some other xml, the definition applies  
>> that the applicatin should interpret relative xlinks as relative to  
>> the document, regardless of the protocol (file, http, ftp, ...)
>>
>> On Fri, Mar 30, 2012 at 2:45 PM, Glen Robson  
>> <gle...@ll...> wrote:
>> Hi Mark & Ying,
>>
>> I think if you use a local file rather than a http URL then it will  
>> be relative to something unhelpful like the tomcat directory where  
>> the fedora-sword package is installed. The best solution is  
>> probably to change the links to http URLs if you can and if not if  
>> you could change the file paths to absolute (assuming the files are  
>> on the same server the fedora sword web app is installed).
>>
>> I hope that helps.
>>
>> Cheers
>>
>> Glen
>>
>>
>> -- 
>>
>> Mark Diggory (Schedule a Meeting)
>> 2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010
>> Esperantolaan 4, Heverlee 3001, Belgium
>> http://www.atmire.com
>>
>>
>

[sword-app-tech] "RESTful thinking considered harmful" article

From: Ben O'S. <bo...@gm...> - 2012-04-03 23:43:38

http://www.shopify.com/technology/5898287-restful-thinking-considered-harmful

Article and comments discuss the links between CRUD and HTTP methods and in
particular, pick up on the problems with POST and PUT semantics.

Worth reading through and touches on some of the pain points that SWORD2
encountered on the way.


Ben

Re: [sword-app-tech] suggested move to github

From: Mark D. <mdi...@at...> - 2012-04-03 15:40:49

There is an option in the git svn importer to not expect the trunk/tags/branches in the initial directory of the project being imported.   I expect that there has to be some way to still map the tags/branches/trunk for projects... something like:

http://stackoverflow.com/questions/3075171/importing-subversion-to-git-problem-with-subpaths

I would try to work out the mappings on export from svn to git rather than retrospectively.

The repos I created can be deleted if they are not ideal for your interest.

Mark 


 
Mark Diggory (Schedule a Meeting (http://bit.ly/xNePTl))
2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010
Esperantolaan 4, Heverlee 3001, Belgium
http://www.atmire.com (http://www.atmire.com/)


On Tuesday, April 3, 2012 at 1:12 AM, Richard Jones wrote:

> Hi Guys,
> 
> Ok, sounds like a go to me :)
> 
> I was thinking that the best way to structure the github repos would be via a SWORD organisation (which I see Mark has already done) with a repo for each output (again, as per Mark's initial work).  I thought to just export the trunk from the original svn, though, rather than keeping the svn structure (trunk, tags, branches), etc.  Not sure how easy it will be to retrospectively tag any releases, but there's certainly a command to do it. 
> 
> How does that sound?
> 
> Cheers,
> 
> R
> 
> On 3 April 2012 07:24, Mark Diggory <mdi...@at... (mailto:mdi...@at...)> wrote:
> >  That was pretty easy... couple repos ported with authors intact... I gave rights over for the Sword1.1 repo I originally made.  Probably want to reimport it with authors files setup correctly.
> > 
> > https://github.com/swordapp
> > 
> > Mark 
> > 
> > 
> >  
> > Mark Diggory (Schedule a Meeting (http://bit.ly/xNePTl))
> > 2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010
> > Esperantolaan 4, Heverlee 3001, Belgium
> > http://www.atmire.com (http://www.atmire.com/)
> > 
> > 
> > On Monday, April 2, 2012 at 11:17 AM, LEWIS Stuart wrote:
> > 
> > > Sounds good to me too - that's where all the cool kids play these days! (so I'm told! ;)
> > > 
> > > There are some other SWORD related projects in github too:
> > > 
> > > https://github.com/stuartlewis/EasyDeposit
> > > https://github.com/stuartlewis/swordapp-php-library
> > > https://github.com/stuartlewis/swordappv2-php-library
> > > https://github.com/kshepherd/RightClickDeposit
> > > https://github.com/oerpub/
> > > 
> > > Cheers,
> > > 
> > > 
> > > Stuart
> > > 
> > > 
> > > -- 
> > > The University of Edinburgh is a charitable body, registered in
> > > Scotland, with registration number SC005336.
> > > 
> > > 
> > > -----Original Message-----
> > > From: Mark Diggory [mailto:mdi...@at...] 
> > >  Sent: 02 April 2012 18:41
> > > To: Richard Jones
> > > Cc: <swo...@li... (mailto:swo...@li...)>
> > > Subject: Re: [sword-app-tech] suggested move to github
> > > 
> > > I subversively did some thing similar in my own github account to get the 1.1 SWORD jar into maven.
> > > 
> > > https://github.com/mdiggory/SWORDv1.1
> > > 
> > >  I'd enjoy assisting this along with you.
> > > 
> > > Mark
> > > 
> > > 
> > > On Mon, Apr 2, 2012 at 9:25 AM, Richard Jones <ri...@co... (mailto:ri...@co...)> wrote:
> > > > Hi Folks,
> > > > 
> > > > During one of my many bouts of frustration with sourceforge, I started 
> > > > to wonder if there's any mileage in moving to github?  Would anyone 
> > > > object?  If not, I'll look into doing this at some point soon.
> > > > 
> > > > Cheers,
> > > > 
> > > > Richard
> > > > 
> > > > 
> > > > --
> > > > 
> > > > Richard Jones,
> > > > 
> > > > Founder, Cottage Labs
> > > > t: @richard_d_jones, @cottagelabs
> > > > w: http://cottagelabs.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... (mailto: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... (mailto: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... (mailto:swo...@li...)
> > > https://lists.sourceforge.net/lists/listinfo/sword-app-tech
> > 
> > 
> > ------------------------------------------------------------------------------
> >  Better than sec? Nothing is better than sec when it comes to
> >  monitoring Big Data applications. Try Boundary one-second
> >  resolution app monitoring today. Free.
> > http://p.sf.net/sfu/Boundary-dev2dev
> > _______________________________________________
> >  sword-app-tech mailing list
> > swo...@li... (mailto:swo...@li...)
> > https://lists.sourceforge.net/lists/listinfo/sword-app-tech
> > 
> 
> 
> 
> -- 
> 
> Richard Jones, 
> 
> Founder, Cottage Labs 
> t: @richard_d_jones, @cottagelabs
> w: http://cottagelabs.com
> 
>

Re: [sword-app-tech] SWORD 2 and DSpace

From: Marco F. <mar...@ee...> - 2012-04-03 15:18:29

Hi Ben,

> Excellent work Marco, and thank you for adding in issues too, they're very helpful!
> 
> If your fixes are in a repo, it'll be great to take a look.
> 

I forked Richard's fork and submitted my changes to Bitbucket ( https://bitbucket.org/marcofabiani/python-sword2 ). Observe that I only fixed issues #1, #4 and #5. The workaround to the etree.xml problems was to install lxml!

Cheers,

Marco

> Ben
> 
> On Apr 3, 2012 1:46 PM, "Marco Fabiani" <mar...@ee...> wrote:
> Hi Richard,
> 
> I having been testing the latest version of the Python libraries from your fork on bitbucket. I added 5 issues to the project, and indicated the causes.
> 
> I did small changes on my local copy and everything works now, but I am not sure if my solutions are correct or just workarounds, so I prefer to leave it to you. In particular, I don't know if errors in parsing the service document and the deposit receipts are caused by the DSpace Sword2 server sending incorrect information, or by the python client.
> 
> Cheers
> Marco
> 
> On 29 Mar 2012, at 16:26, Marco Fabiani wrote:
> 
>> 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
>>> 
>>> 
>> 
>> ------------------------------------------------------------------------------
>> 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
> 
> 
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> _______________________________________________
> sword-app-tech mailing list
> swo...@li...
> https://lists.sourceforge.net/lists/listinfo/sword-app-tech
>

Re: [sword-app-tech] SWORD 2 and DSpace

From: Ben O'S. <bo...@gm...> - 2012-04-03 14:03:54

Hi,

Excellent work Marco, and thank you for adding in issues too, they're very
helpful!

If your fixes are in a repo, it'll be great to take a look.

Ben
On Apr 3, 2012 1:46 PM, "Marco Fabiani" <mar...@ee...>
wrote:

> Hi Richard,
>
> I having been testing the latest version of the Python libraries from your
> fork on bitbucket. I added 5 issues to the project, and indicated the
> causes.
>
> I did small changes on my local copy and everything works now, but I am
> not sure if my solutions are correct or just workarounds, so I prefer to
> leave it to you. In particular, I don't know if errors in parsing the
> service document and the deposit receipts are caused by the DSpace Sword2
> server sending incorrect information, or by the python client.
>
> Cheers
> Marco
>
> On 29 Mar 2012, at 16:26, Marco Fabiani wrote:
>
> 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
>
>
>
>
> ------------------------------------------------------------------------------
> 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
>
>
>
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> _______________________________________________
> sword-app-tech mailing list
> swo...@li...
> https://lists.sourceforge.net/lists/listinfo/sword-app-tech
>
>

Re: [sword-app-tech] SWORD 2 and DSpace

From: Marco F. <mar...@ee...> - 2012-04-03 12:46:34

Hi Richard,

I having been testing the latest version of the Python libraries from your fork on bitbucket. I added 5 issues to the project, and indicated the causes.

I did small changes on my local copy and everything works now, but I am not sure if my solutions are correct or just workarounds, so I prefer to leave it to you. In particular, I don't know if errors in parsing the service document and the deposit receipts are caused by the DSpace Sword2 server sending incorrect information, or by the python client.

Cheers
Marco

On 29 Mar 2012, at 16:26, Marco Fabiani wrote:

> 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
>> 
>> 
> 
> ------------------------------------------------------------------------------
> 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

Re: [sword-app-tech] suggested move to github

From: Richard J. <ri...@co...> - 2012-04-03 08:13:02

Hi Guys,

Ok, sounds like a go to me :)

I was thinking that the best way to structure the github repos would be via
a SWORD organisation (which I see Mark has already done) with a repo for
each output (again, as per Mark's initial work).  I thought to just export
the trunk from the original svn, though, rather than keeping the svn
structure (trunk, tags, branches), etc.  Not sure how easy it will be to
retrospectively tag any releases, but there's certainly a command to do it.

How does that sound?

Cheers,

R

On 3 April 2012 07:24, Mark Diggory <mdi...@at...> wrote:

>  That was pretty easy... couple repos ported with authors intact... I gave
> rights over for the Sword1.1 repo I originally made.  Probably want to
> reimport it with authors files setup correctly.
>
> https://github.com/swordapp
>
> Mark
>
>
> [image: @mire Inc.]
> *Mark Diggory (Schedule a Meeting <http://bit.ly/xNePTl>)*
> *2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010*
> *Esperantolaan 4, Heverlee 3001, Belgium*
> http://www.atmire.com
>
> On Monday, April 2, 2012 at 11:17 AM, LEWIS Stuart wrote:
>
> Sounds good to me too - that's where all the cool kids play these days!
> (so I'm told! ;)
>
> There are some other SWORD related projects in github too:
>
> https://github.com/stuartlewis/EasyDeposit
> https://github.com/stuartlewis/swordapp-php-library
> https://github.com/stuartlewis/swordappv2-php-library
> https://github.com/kshepherd/RightClickDeposit
> https://github.com/oerpub/
>
> Cheers,
>
>
> Stuart
>
>
> --
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
>
> -----Original Message-----
> From: Mark Diggory [mailto:mdi...@at... <mdi...@at...>]
> Sent: 02 April 2012 18:41
> To: Richard Jones
> Cc: <swo...@li...>
> Subject: Re: [sword-app-tech] suggested move to github
>
> I subversively did some thing similar in my own github account to get the
> 1.1 SWORD jar into maven.
>
> https://github.com/mdiggory/SWORDv1.1
>
> I'd enjoy assisting this along with you.
>
> Mark
>
>
> On Mon, Apr 2, 2012 at 9:25 AM, Richard Jones <ri...@co...>
> wrote:
>
> Hi Folks,
>
> During one of my many bouts of frustration with sourceforge, I started
> to wonder if there's any mileage in moving to github?  Would anyone
> object?  If not, I'll look into doing this at some point soon.
>
> Cheers,
>
> Richard
>
>
> --
>
> Richard Jones,
>
> Founder, Cottage Labs
> t: @richard_d_jones, @cottagelabs
> w: http://cottagelabs.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
>
>
>
>
> --
>
> 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
>
> ------------------------------------------------------------------------------
> 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
>
>
>
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> _______________________________________________
> sword-app-tech mailing list
> swo...@li...
> https://lists.sourceforge.net/lists/listinfo/sword-app-tech
>
>


-- 

Richard Jones,

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

Re: [sword-app-tech] suggested move to github

From: Mark D. <mdi...@at...> - 2012-04-03 06:25:02

 That was pretty easy... couple repos ported with authors intact... I gave rights over for the Sword1.1 repo I originally made.  Probably want to reimport it with authors files setup correctly.

https://github.com/swordapp

Mark 


 
Mark Diggory (Schedule a Meeting (http://bit.ly/xNePTl))
2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010
Esperantolaan 4, Heverlee 3001, Belgium
http://www.atmire.com (http://www.atmire.com/)


On Monday, April 2, 2012 at 11:17 AM, LEWIS Stuart wrote:

> Sounds good to me too - that's where all the cool kids play these days! (so I'm told! ;)
> 
> There are some other SWORD related projects in github too:
> 
> https://github.com/stuartlewis/EasyDeposit
> https://github.com/stuartlewis/swordapp-php-library
> https://github.com/stuartlewis/swordappv2-php-library
> https://github.com/kshepherd/RightClickDeposit
> https://github.com/oerpub/
> 
> Cheers,
> 
> 
> Stuart
> 
> 
> -- 
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
> 
> 
> -----Original Message-----
> From: Mark Diggory [mailto:mdi...@at...] 
> Sent: 02 April 2012 18:41
> To: Richard Jones
> Cc: <swo...@li... (mailto:swo...@li...)>
> Subject: Re: [sword-app-tech] suggested move to github
> 
> I subversively did some thing similar in my own github account to get the 1.1 SWORD jar into maven.
> 
> https://github.com/mdiggory/SWORDv1.1
> 
> I'd enjoy assisting this along with you.
> 
> Mark
> 
> 
> On Mon, Apr 2, 2012 at 9:25 AM, Richard Jones <ri...@co... (mailto:ri...@co...)> wrote:
> > Hi Folks,
> > 
> > During one of my many bouts of frustration with sourceforge, I started 
> > to wonder if there's any mileage in moving to github?  Would anyone 
> > object?  If not, I'll look into doing this at some point soon.
> > 
> > Cheers,
> > 
> > Richard
> > 
> > 
> > --
> > 
> > Richard Jones,
> > 
> > Founder, Cottage Labs
> > t: @richard_d_jones, @cottagelabs
> > w: http://cottagelabs.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... (mailto: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... (mailto: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... (mailto:swo...@li...)
> https://lists.sourceforge.net/lists/listinfo/sword-app-tech

Re: [sword-app-tech] suggested move to github

From: LEWIS S. <Stu...@ed...> - 2012-04-02 18:17:09

Sounds good to me too - that's where all the cool kids play these days! (so I'm told! ;)

There are some other SWORD related projects in github too:

https://github.com/stuartlewis/EasyDeposit
https://github.com/stuartlewis/swordapp-php-library
https://github.com/stuartlewis/swordappv2-php-library
https://github.com/kshepherd/RightClickDeposit
https://github.com/oerpub/

Cheers,


Stuart


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


-----Original Message-----
From: Mark Diggory [mailto:mdi...@at...] 
Sent: 02 April 2012 18:41
To: Richard Jones
Cc: <swo...@li...>
Subject: Re: [sword-app-tech] suggested move to github

I subversively did some thing similar in my own github account to get the 1.1 SWORD jar into maven.

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

I'd enjoy assisting this along with you.

Mark


On Mon, Apr 2, 2012 at 9:25 AM, Richard Jones <ri...@co...> wrote:
> Hi Folks,
>
> During one of my many bouts of frustration with sourceforge, I started 
> to wonder if there's any mileage in moving to github?  Would anyone 
> object?  If not, I'll look into doing this at some point soon.
>
> Cheers,
>
> Richard
>
>
> --
>
> Richard Jones,
>
> Founder, Cottage Labs
> t: @richard_d_jones, @cottagelabs
> w: http://cottagelabs.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
>



-- 

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

Re: [sword-app-tech] suggested move to github

From: Mark D. <mdi...@at...> - 2012-04-02 17:41:17

I subversively did some thing similar in my own github account to get
the 1.1 SWORD jar into maven.

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

I'd enjoy assisting this along with you.

Mark


On Mon, Apr 2, 2012 at 9:25 AM, Richard Jones <ri...@co...> wrote:
> Hi Folks,
>
> During one of my many bouts of frustration with sourceforge, I started to
> wonder if there's any mileage in moving to github?  Would anyone object?  If
> not, I'll look into doing this at some point soon.
>
> Cheers,
>
> Richard
>
>
> --
>
> Richard Jones,
>
> Founder, Cottage Labs
> t: @richard_d_jones, @cottagelabs
> w: http://cottagelabs.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
>



-- 

Mark Diggory (Schedule a Meeting)
2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010
Esperantolaan 4, Heverlee 3001, Belgium
http://www.atmire.com

[sword-app-tech] suggested move to github

From: Richard J. <ri...@co...> - 2012-04-02 16:25:48

Hi Folks,

During one of my many bouts of frustration with sourceforge, I started to
wonder if there's any mileage in moving to github?  Would anyone object?
 If not, I'll look into doing this at some point soon.

Cheers,

Richard


-- 

Richard Jones,

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

Re: [sword-app-tech] migrate DSpace to Islandora using SWORD

From: Mark D. <mdi...@at...> - 2012-03-31 00:40:31

 Yes, my recommendation is to push the entire AIP package into SWORD as a
whole zip. I assumed because we're talking about separate system that would
be the interest.

Mark

On Friday, March 30, 2012, Glen Robson wrote:

> Hi Mark,
>
> I think I've misunderstood what Ying was trying to do, I though it was a
> plain METS document being submitted rather than a METS document in a zip
> file which was why you would need a http URL or relative file URL for the
> sword-fedora plugin to find what it needs to ingest. If you want to submit
> a zip file with a METS manifest you could use a mime-type of
> application/zip and a packaging of http://www.loc.gov/METS/ and looking
> at the code it will add any dmdSecs as metadata datastreams in Fedora and
> any files it finds in the zip file.
>
> Its not the ideal way of doing it as you mention below, ideally it should
> take the METS file as a manifest and understand the myriad of URL
> possibilities and only ingest the items mentioned in the METS file but the
> way it works currently may be enough to get Ying started. As it currently
> doesn't parse the METS:file section it shouldn't matter if the LOCTYPE is
> URL or something else (assuming I'm reading the code correctly).
>
> Sorry for the confusion but hope this is a possible solution.
>
> Thanks
>
> Glen
>
> On 30 Mar 2012, at 23:05, Mark Diggory wrote:
>
> I assume the file at that point is in some tomcat temp directory and
> expanded into a directory with a list of files.  Changing the AIP on the
> DSpace side is either changing java code and rebuilding, or transforming
> the packages after they have been generated.
>
> My point is that the logic of xlink is that like its html conterparts, an
> IRI/URL may be a path relative to the document.  In such cases, it really
> should not matter "where" the document resides.
>
> .../mypackage/mets.xml
> .../mypackage/bitstream_613090.jpeg
>
> http://host/mypackage/mets.xml
> http://host/mypackage/bitstream_613090.jpeg
>
> zip:file://./mypackage.zip!/bitstream_613090.jpeg
>
> These are all valid IRI/URL
>
> Maybe I'm just arguing semantics here, but the specified behavior for LOCTYPE
> = URL shouldn't force users to only be able to use a subset of
> XLINK/IRI/URL possibilities in METS.  In fact, for proper portability,
> relative linking is a necessity.  This seems a bug in the Fedora METS
> import code.
>
> Mark
>
> If its inside html, METS or some other xml, the definition applies that
> the applicatin should interpret relative xlinks as relative to the
> document, regardless of the protocol (file, http, ftp, ...)
>
> On Fri, Mar 30, 2012 at 2:45 PM, Glen Robson <gle...@ll...<javascript:_e({}, 'cvml', 'gle...@ll...');>
> > wrote:
>
>> Hi Mark & Ying,
>>
>> I think if you use a local file rather than a http URL then it will be
>> relative to something unhelpful like the tomcat directory where the
>> fedora-sword package is installed. The best solution is probably to change
>> the links to http URLs if you can and if not if you could change the file
>> paths to absolute (assuming the files are on the same server the fedora
>> sword web app is installed).
>>
>> I hope that helps.
>>
>> Cheers
>>
>> Glen
>>
>
>
> --
>  [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

Re: [sword-app-tech] migrate DSpace to Islandora using SWORD

From: Glen R. <gle...@ll...> - 2012-03-30 23:38:42

Hi Mark,

I think I've misunderstood what Ying was trying to do, I though it was a plain METS document being submitted rather than a METS document in a zip file which was why you would need a http URL or relative file URL for the sword-fedora plugin to find what it needs to ingest. If you want to submit a zip file with a METS manifest you could use a mime-type of application/zip and a packaging of http://www.loc.gov/METS/ and looking at the code it will add any dmdSecs as metadata datastreams in Fedora and any files it finds in the zip file. 

Its not the ideal way of doing it as you mention below, ideally it should take the METS file as a manifest and understand the myriad of URL possibilities and only ingest the items mentioned in the METS file but the way it works currently may be enough to get Ying started. As it currently doesn't parse the METS:file section it shouldn't matter if the LOCTYPE is URL or something else (assuming I'm reading the code correctly).

Sorry for the confusion but hope this is a possible solution.

Thanks

Glen

On 30 Mar 2012, at 23:05, Mark Diggory wrote:

> I assume the file at that point is in some tomcat temp directory and expanded into a directory with a list of files.  Changing the AIP on the DSpace side is either changing java code and rebuilding, or transforming the packages after they have been generated.
> 
> My point is that the logic of xlink is that like its html conterparts, an IRI/URL may be a path relative to the document.  In such cases, it really should not matter "where" the document resides. 
> 
> .../mypackage/mets.xml
> .../mypackage/bitstream_613090.jpeg
> 
> http://host/mypackage/mets.xml
> http://host/mypackage/bitstream_613090.jpeg
> 
> zip:file://./mypackage.zip!/bitstream_613090.jpeg
> 
> These are all valid IRI/URL
> 
> Maybe I'm just arguing semantics here, but the specified behavior for LOCTYPE = URL shouldn't force users to only be able to use a subset of XLINK/IRI/URL possibilities in METS.  In fact, for proper portability, relative linking is a necessity.  This seems a bug in the Fedora METS import code.
> 
> Mark
> 
> If its inside html, METS or some other xml, the definition applies that the applicatin should interpret relative xlinks as relative to the document, regardless of the protocol (file, http, ftp, ...)
> 
> On Fri, Mar 30, 2012 at 2:45 PM, Glen Robson <gle...@ll...> wrote:
> Hi Mark & Ying,
> 
> I think if you use a local file rather than a http URL then it will be relative to something unhelpful like the tomcat directory where the fedora-sword package is installed. The best solution is probably to change the links to http URLs if you can and if not if you could change the file paths to absolute (assuming the files are on the same server the fedora sword web app is installed).
> 
> I hope that helps.
> 
> Cheers
> 
> Glen
> 
> 
> -- 
>  
> Mark Diggory (Schedule a Meeting)
> 2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010
> Esperantolaan 4, Heverlee 3001, Belgium
> http://www.atmire.com
> 
>

Re: [sword-app-tech] migrate DSpace to Islandora using SWORD

From: Mark D. <mdi...@at...> - 2012-03-30 22:05:47

I assume the file at that point is in some tomcat temp directory and
expanded into a directory with a list of files.  Changing the AIP on the
DSpace side is either changing java code and rebuilding, or transforming
the packages after they have been generated.

My point is that the logic of xlink is that like its html conterparts, an
IRI/URL may be a path relative to the document.  In such cases, it really
should not matter "where" the document resides.

.../mypackage/mets.xml
.../mypackage/bitstream_613090.jpeg

http://host/mypackage/mets.xml
http://host/mypackage/bitstream_613090.jpeg

zip:file://./mypackage.zip!/bitstream_613090.jpeg

These are all valid IRI/URL

Maybe I'm just arguing semantics here, but the specified behavior for LOCTYPE
= URL shouldn't force users to only be able to use a subset of
XLINK/IRI/URL possibilities in METS.  In fact, for proper portability,
relative linking is a necessity.  This seems a bug in the Fedora METS
import code.

Mark

If its inside html, METS or some other xml, the definition applies that the
applicatin should interpret relative xlinks as relative to the document,
regardless of the protocol (file, http, ftp, ...)

On Fri, Mar 30, 2012 at 2:45 PM, Glen Robson <gle...@ll...>wrote:

> Hi Mark & Ying,
>
> I think if you use a local file rather than a http URL then it will be
> relative to something unhelpful like the tomcat directory where the
> fedora-sword package is installed. The best solution is probably to change
> the links to http URLs if you can and if not if you could change the file
> paths to absolute (assuming the files are on the same server the fedora
> sword web app is installed).
>
> I hope that helps.
>
> Cheers
>
> Glen
>

-- 
[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

Re: [sword-app-tech] migrate DSpace to Islandora using SWORD

From: Glen R. <gle...@ll...> - 2012-03-30 21:46:05

Hi Mark & Ying,

I think if you use a local file rather than a http URL then it will be relative to something unhelpful like the tomcat directory where the fedora-sword package is installed. The best solution is probably to change the links to http URLs if you can and if not if you could change the file paths to absolute (assuming the files are on the same server the fedora sword web app is installed).

I hope that helps.

Cheers

Glen
 
On 30 Mar 2012, at 21:10, Mark Diggory wrote:

> Seems like the interpretation is that it need to be absolute resolvable HTTP URL?
> 
> Why are not general relative URL supported? IE, a relative URL of a file on the filesystem for some directory "x" would be "somefile.ext" where the file was located under .../x/somefile.txt
> 
> Mark
> 
> 
> 
> 
> On Fri, Mar 30, 2012 at 1:02 PM, Ying Jin <Yin...@ri...> wrote:
> Hi Glen,
> 
> You are right. In DSpace AIP mets, LOCTYPE = URL but the xlink:href is
> only a filename -
> <FLocat LOCTYPE="URL" xlink:type="simple"
> xlink:href="bitstream_613090.jpeg"/>
> 
> I changed URL to OTHER and the error message in fedora log is gone.
> But there is still error report in http response. This time, the
> exception messages are in tomcat log -
> 
> Caused by: java.io.IOException: File doesn't exists:
> bitstream_613090.jpeg
>        at
> org
> .purl
> .sword
> .server
> .fedora.fedoraObjects.LocalDatastream.upload(LocalDatastream.java:116)
>        at
> org
> .purl
> .sword
> .server
> .fedora
> .fedoraObjects.FedoraObject.uploadLocalDatastreams(FedoraObject.java:
> 240)
> 
> I put mets.xml file and all bitstreams under the same directory and
> run the CURL the same dir too. And there is no permission issue. Do
> you have any suggestions?
> 
> Thanks,
> Ying
> 
> On Mar 29, 2012, at 5:34 PM, Glen Robson wrote:
> 
> > Hi Ying,
> >
> > Looking at the code it looks like you need to specify the full URL
> > if you use the LOCTYPE = URL in the FLocat for your METS:file but if
> > you use any other value for LOCTYPE it will try and upload a local
> > file to Fedora then ingest the object with a reference to the
> > uploaded file. Its been a while since I looked at this so let me
> > know if that works.
> >
> > Thanks
> >
> > Glen
> >
> > On 29 Mar 2012, at 22:58, Ying Jin wrote:
> >
> >> Hi Glen,
> >>
> >> Thanks for pointing out this possibility. Robin and Mark, thank you
> >> for the continue support.
> >>
> >> I tried an AIP mets and get following error messages in my log -
> >>
> >> ERROR 2012-03-29 16:33:11.068 [http-8080-3]
> >> (FedoraAPIMBindingSOAPHTTPImpl) Error ingesting
> >> org.fcrepo.server.errors.ObjectIntegrityException: FOXML IO stream
> >> was bad : Malformed URL: bitstream_613090.jpeg
> >>      at
> >> org
> >> .fcrepo
> >> .server
> >> .storage
> >> .translation
> >> .FOXMLDODeserializer.deserialize(FOXMLDODeserializer.java:258)
> >> [fcrepo-server-3.4.2.jar:na]
> >>      at
> >> org
> >> .fcrepo
> >> .server
> >> .storage
> >> .translation.DOTranslatorImpl.deserialize(DOTranslatorImpl.java:75)
> >> [fcrepo-server-3.4.2.jar:na]
> >>      at
> >> org
> >> .fcrepo
> >> .server
> >> .storage
> >> .translation.DOTranslatorModule.deserialize(DOTranslatorModule.java:
> >> 126) [fcrepo-server-3.4.2.jar:na]
> >>      at
> >> org
> >> .fcrepo
> >> .server
> >> .storage.DefaultDOManager.getIngestWriter(DefaultDOManager.java:
> >> 802) [fcrepo-server-3.4.2.jar:na]
> >>      at
> >> org
> >> .fcrepo
> >> .server.management.DefaultManagement.ingest(DefaultManagement.java:
> >> 160) [fcrepo-server-3.4.2.jar:na]
> >>      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [na:
> >> 1.6.0_23]
> >>      at
> >> sun
> >> .reflect
> >> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> >> [na:1.6.0_23]
> >>      at
> >> sun
> >> .reflect
> >> .DelegatingMethodAccessorImpl
> >> .invoke(DelegatingMethodAccessorImpl.java:43) [na:1.6.0_23]
> >>      at java.lang.reflect.Method.invoke(Method.java:616) [na:1.6.0_23]
> >>      at
> >> org
> >> .fcrepo
> >> .server
> >> .messaging
> >> .NotificationInvocationHandler
> >> .invoke(NotificationInvocationHandler.java:68) [fcrepo-
> >> server-3.4.2.jar:na]
> >>      at $Proxy4.ingest(Unknown Source) [na:na]
> >>      at
> >> org
> >> .fcrepo
> >> .server.management.ManagementModule.ingest(ManagementModule.java:
> >> 354) [fcrepo-server-3.4.2.jar:na]
> >>      at
> >> org
> >> .fcrepo
> >> .server
> >> .management
> >> .FedoraAPIMBindingSOAPHTTPImpl
> >> .ingest(FedoraAPIMBindingSOAPHTTPImpl.java:83) [fcrepo-
> >> server-3.4.2.jar:na]
> >>      at
> >> org
> >> .fcrepo
> >> .server
> >> .management
> >> .FedoraAPIMBindingSOAPHTTPSkeleton
> >> .ingest(FedoraAPIMBindingSOAPHTTPSkeleton.java:355) [fcrepo-
> >> common-3.4.2.jar:na]
> >>      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [na:
> >> 1.6.0_23]
> >>      at
> >> sun
> >> .reflect
> >> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> >> [na:1.6.0_23]
> >>      at
> >> sun
> >> .reflect
> >> .DelegatingMethodAccessorImpl
> >> .invoke(DelegatingMethodAccessorImpl.java:43) [na:1.6.0_23]
> >>      at java.lang.reflect.Method.invoke(Method.java:616) [na:1.6.0_23]
> >>      at
> >> org
> >> .apache
> >> .axis.providers.java.RPCProvider.invokeMethod(RPCProvider.java:397)
> >> [axis-1.3-PATCHED.jar:na]
> >>      at
> >> org
> >> .apache
> >> .axis.providers.java.RPCProvider.processMessage(RPCProvider.java:
> >> 186) [axis-1.3-PATCHED.jar:na]
> >>      at
> >> org
> >> .apache.axis.providers.java.JavaProvider.invoke(JavaProvider.java:
> >> 323) [axis-1.3-PATCHED.jar:na]
> >>      at
> >> org
> >> .apache
> >> .axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:
> >> 32) [axis-1.3-PATCHED.jar:na]
> >>      at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118)
> >> [axis-1.3-PATCHED.jar:na]
> >>      at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83)
> >> [axis-1.3-PATCHED.jar:na]
> >>      at
> >> org.apache.axis.handlers.soap.SOAPService.invoke(SOAPService.java:
> >> 453) [axis-1.3-PATCHED.jar:na]
> >>      at org.apache.axis.server.AxisServer.invoke(AxisServer.java:281)
> >> [axis-1.3-PATCHED.jar:na]
> >>      at
> >> org.apache.axis.transport.http.AxisServlet.doPost(AxisServlet.java:
> >> 699) [axis-1.3-PATCHED.jar:na]
> >>      at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
> >> [servlet-api.jar:na]
> >>      at
> >> org
> >> .apache
> >> .axis.transport.http.AxisServletBase.service(AxisServletBase.java:
> >> 327) [axis-1.3-PATCHED.jar:na]
> >>      at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> >> [servlet-api.jar:na]
> >>      at
> >> org
> >> .apache
> >> .catalina
> >> .core
> >> .ApplicationFilterChain
> >> .internalDoFilter(ApplicationFilterChain.java:290) [catalina.jar:na]
> >>      at
> >> org
> >> .apache
> >> .catalina
> >> .core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:
> >> 206) [catalina.jar:na]
> >>      at
> >> org
> >> .fcrepo
> >> .server
> >> .security.servletfilters.FilterSetup.doFilter(FilterSetup.java:235)
> >> [fcrepo-server-3.4.2.jar:na]
> >>      at
> >> org
> >> .apache
> >> .catalina
> >> .core
> >> .ApplicationFilterChain
> >> .internalDoFilter(ApplicationFilterChain.java:235) [catalina.jar:na]
> >>      at
> >> org
> >> .apache
> >> .catalina
> >> .core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:
> >> 206) [catalina.jar:na]
> >>      at
> >> org
> >> .fcrepo
> >> .server
> >> .security.servletfilters.FilterSetup.doFilter(FilterSetup.java:235)
> >> [fcrepo-server-3.4.2.jar:na]
> >>      at
> >> org
> >> .apache
> >> .catalina
> >> .core
> >> .ApplicationFilterChain
> >> .internalDoFilter(ApplicationFilterChain.java:235) [catalina.jar:na]
> >>      at
> >> org
> >> .apache
> >> .catalina
> >> .core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:
> >> 206) [catalina.jar:na]
> >>      at
> >> org
> >> .fcrepo
> >> .server
> >> .security.servletfilters.FilterSetup.doFilter(FilterSetup.java:235)
> >> [fcrepo-server-3.4.2.jar:na]
> >>      at
> >> org
> >> .apache
> >> .catalina
> >> .core
> >> .ApplicationFilterChain
> >> .internalDoFilter(ApplicationFilterChain.java:235) [catalina.jar:na]
> >>      at
> >> org
> >> .apache
> >> .catalina
> >> .core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:
> >> 206) [catalina.jar:na]
> >>      at
> >> org
> >> .fcrepo
> >> .server
> >> .security.servletfilters.FilterSetup.doFilter(FilterSetup.java:235)
> >> [fcrepo-server-3.4.2.jar:na]
> >>      at
> >> org
> >> .apache
> >> .catalina
> >> .core
> >> .ApplicationFilterChain
> >> .internalDoFilter(ApplicationFilterChain.java:235) [catalina.jar:na]
> >>      at
> >> org
> >> .apache
> >> .catalina
> >> .core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:
> >> 206) [catalina.jar:na]
> >>      at
> >> org
> >> .fcrepo
> >> .server
> >> .security.servletfilters.FilterSetup.doFilter(FilterSetup.java:235)
> >> [fcrepo-server-3.4.2.jar:na]
> >>      at
> >> org
> >> .apache
> >> .catalina
> >> .core
> >> .ApplicationFilterChain
> >> .internalDoFilter(ApplicationFilterChain.java:235) [catalina.jar:na]
> >>      at
> >> org
> >> .apache
> >> .catalina
> >> .core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:
> >> 206) [catalina.jar:na]
> >>      at
> >> org
> >> .fcrepo
> >> .server
> >> .security.servletfilters.FilterSetup.doFilter(FilterSetup.java:235)
> >> [fcrepo-server-3.4.2.jar:na]
> >>      at
> >> org
> >> .apache
> >> .catalina
> >> .core
> >> .ApplicationFilterChain
> >> .internalDoFilter(ApplicationFilterChain.java:235) [catalina.jar:na]
> >>      at
> >> org
> >> .apache
> >> .catalina
> >> .core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:
> >> 206) [catalina.jar:na]
> >>      at
> >> org
> >> .apache
> >> .catalina
> >> .core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
> >> [catalina.jar:na]
> >>      at
> >> org
> >> .apache
> >> .catalina
> >> .core.StandardContextValve.invoke(StandardContextValve.java:191)
> >> [catalina.jar:na]
> >>      at
> >> org
> >> .apache
> >> .catalina
> >> .authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)
> >> [catalina.jar:na]
> >>      at
> >> org
> >> .apache
> >> .catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
> >> [catalina.jar:na]
> >>      at
> >> org
> >> .apache
> >> .catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> >> [catalina.jar:na]
> >>      at
> >> org
> >> .apache
> >> .catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:
> >> 109) [catalina.jar:na]
> >>      at
> >> org
> >> .apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:
> >> 293) [catalina.jar:na]
> >>      at
> >> org
> >> .apache.coyote.http11.Http11Processor.process(Http11Processor.java:
> >> 849) [tomcat-coyote.jar:na]
> >>      at org.apache.coyote.http11.Http11Protocol
> >> $Http11ConnectionHandler.process(Http11Protocol.java:583) [tomcat-
> >> coyote.jar:na]
> >>      at org.apache.tomcat.util.net.JIoEndpoint
> >> $Worker.run(JIoEndpoint.java:454) [tomcat-coyote.jar:na]
> >>      at java.lang.Thread.run(Thread.java:679) [na:1.6.0_23]
> >> Caused by: org.xml.sax.SAXException: Malformed URL:
> >> bitstream_613090.jpeg
> >>      at
> >> org
> >> .fcrepo
> >> .server
> >> .storage
> >> .translation
> >> .FOXMLDODeserializer.startElement(FOXMLDODeserializer.java:453)
> >> [fcrepo-server-3.4.2.jar:na]
> >>      at
> >> org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown
> >> Source) [xercesImpl-2.9.1.jar:na]
> >>      at
> >> org
> >> .apache
> >> .xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown
> >> Source) [xercesImpl-2.9.1.jar:na]
> >>      at
> >> org
> >> .apache
> >> .xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown
> >> Source) [xercesImpl-2.9.1.jar:na]
> >>      at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl
> >> $FragmentContentDispatcher.dispatch(Unknown Source)
> >> [xercesImpl-2.9.1.jar:na]
> >>      at
> >> org
> >> .apache
> >> .xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
> >> Source) [xercesImpl-2.9.1.jar:na]
> >>      at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
> >> Source) [xercesImpl-2.9.1.jar:na]
> >>      at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
> >> Source) [xercesImpl-2.9.1.jar:na]
> >>      at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> >> [xercesImpl-2.9.1.jar:na]
> >>      at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown
> >> Source) [xercesImpl-2.9.1.jar:na]
> >>      at org.apache.xerces.jaxp.SAXParserImpl
> >> $JAXPSAXParser.parse(Unknown Source) [xercesImpl-2.9.1.jar:na]
> >>      at org.apache.xerces.jaxp.SAXParserImpl.parse(Unknown Source)
> >> [xercesImpl-2.9.1.jar:na]
> >>      at javax.xml.parsers.SAXParser.parse(SAXParser.java:195) [na:
> >> 1.6.0_23]
> >>      at
> >> org
> >> .fcrepo
> >> .server
> >> .storage
> >> .translation
> >> .FOXMLDODeserializer.deserialize(FOXMLDODeserializer.java:253)
> >> [fcrepo-server-3.4.2.jar:na]
> >>      ... 60 common frames omitted
> >>
> >> I suspect that fedora SWORD is expecting a URL link to the file
> >> instead of a local file name. However, if that's the case, should
> >> be a easy fix in the code.
> >>
> >> Thanks,
> >> Ying
> >> On Mar 29, 2012, at 11:22 AM, Glen Robson 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
> >>>
> >>
> >
> >
> 
> 
> ------------------------------------------------------------------------------
> 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
> 
>

Re: [sword-app-tech] migrate DSpace to Islandora using SWORD

From: Mark D. <mdi...@at...> - 2012-03-30 20:10:40

Seems like the interpretation is that it need to be absolute resolvable
HTTP URL?

Why are not general relative URL supported? IE, a relative URL of a file on
the filesystem for some directory "x" would be "somefile.ext" where the
file was located under .../x/somefile.txt

Mark




On Fri, Mar 30, 2012 at 1:02 PM, Ying Jin <Yin...@ri...> wrote:

> Hi Glen,
>
> You are right. In DSpace AIP mets, LOCTYPE = URL but the xlink:href is
> only a filename -
> <FLocat LOCTYPE="URL" xlink:type="simple"
> xlink:href="bitstream_613090.jpeg"/>
>
> I changed URL to OTHER and the error message in fedora log is gone.
> But there is still error report in http response. This time, the
> exception messages are in tomcat log -
>
> Caused by: java.io.IOException: File doesn't exists:
> bitstream_613090.jpeg
>        at
> org
> .purl
> .sword
> .server
> .fedora.fedoraObjects.LocalDatastream.upload(LocalDatastream.java:116)
>        at
> org
> .purl
> .sword
> .server
> .fedora
> .fedoraObjects.FedoraObject.uploadLocalDatastreams(FedoraObject.java:
> 240)
>
> I put mets.xml file and all bitstreams under the same directory and
> run the CURL the same dir too. And there is no permission issue. Do
> you have any suggestions?
>
> Thanks,
> Ying
>
> On Mar 29, 2012, at 5:34 PM, Glen Robson wrote:
>
> > Hi Ying,
> >
> > Looking at the code it looks like you need to specify the full URL
> > if you use the LOCTYPE = URL in the FLocat for your METS:file but if
> > you use any other value for LOCTYPE it will try and upload a local
> > file to Fedora then ingest the object with a reference to the
> > uploaded file. Its been a while since I looked at this so let me
> > know if that works.
> >
> > Thanks
> >
> > Glen
> >
> > On 29 Mar 2012, at 22:58, Ying Jin wrote:
> >
> >> Hi Glen,
> >>
> >> Thanks for pointing out this possibility. Robin and Mark, thank you
> >> for the continue support.
> >>
> >> I tried an AIP mets and get following error messages in my log -
> >>
> >> ERROR 2012-03-29 16:33:11.068 [http-8080-3]
> >> (FedoraAPIMBindingSOAPHTTPImpl) Error ingesting
> >> org.fcrepo.server.errors.ObjectIntegrityException: FOXML IO stream
> >> was bad : Malformed URL: bitstream_613090.jpeg
> >>      at
> >> org
> >> .fcrepo
> >> .server
> >> .storage
> >> .translation
> >> .FOXMLDODeserializer.deserialize(FOXMLDODeserializer.java:258)
> >> [fcrepo-server-3.4.2.jar:na]
> >>      at
> >> org
> >> .fcrepo
> >> .server
> >> .storage
> >> .translation.DOTranslatorImpl.deserialize(DOTranslatorImpl.java:75)
> >> [fcrepo-server-3.4.2.jar:na]
> >>      at
> >> org
> >> .fcrepo
> >> .server
> >> .storage
> >> .translation.DOTranslatorModule.deserialize(DOTranslatorModule.java:
> >> 126) [fcrepo-server-3.4.2.jar:na]
> >>      at
> >> org
> >> .fcrepo
> >> .server
> >> .storage.DefaultDOManager.getIngestWriter(DefaultDOManager.java:
> >> 802) [fcrepo-server-3.4.2.jar:na]
> >>      at
> >> org
> >> .fcrepo
> >> .server.management.DefaultManagement.ingest(DefaultManagement.java:
> >> 160) [fcrepo-server-3.4.2.jar:na]
> >>      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [na:
> >> 1.6.0_23]
> >>      at
> >> sun
> >> .reflect
> >> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> >> [na:1.6.0_23]
> >>      at
> >> sun
> >> .reflect
> >> .DelegatingMethodAccessorImpl
> >> .invoke(DelegatingMethodAccessorImpl.java:43) [na:1.6.0_23]
> >>      at java.lang.reflect.Method.invoke(Method.java:616) [na:1.6.0_23]
> >>      at
> >> org
> >> .fcrepo
> >> .server
> >> .messaging
> >> .NotificationInvocationHandler
> >> .invoke(NotificationInvocationHandler.java:68) [fcrepo-
> >> server-3.4.2.jar:na]
> >>      at $Proxy4.ingest(Unknown Source) [na:na]
> >>      at
> >> org
> >> .fcrepo
> >> .server.management.ManagementModule.ingest(ManagementModule.java:
> >> 354) [fcrepo-server-3.4.2.jar:na]
> >>      at
> >> org
> >> .fcrepo
> >> .server
> >> .management
> >> .FedoraAPIMBindingSOAPHTTPImpl
> >> .ingest(FedoraAPIMBindingSOAPHTTPImpl.java:83) [fcrepo-
> >> server-3.4.2.jar:na]
> >>      at
> >> org
> >> .fcrepo
> >> .server
> >> .management
> >> .FedoraAPIMBindingSOAPHTTPSkeleton
> >> .ingest(FedoraAPIMBindingSOAPHTTPSkeleton.java:355) [fcrepo-
> >> common-3.4.2.jar:na]
> >>      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [na:
> >> 1.6.0_23]
> >>      at
> >> sun
> >> .reflect
> >> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> >> [na:1.6.0_23]
> >>      at
> >> sun
> >> .reflect
> >> .DelegatingMethodAccessorImpl
> >> .invoke(DelegatingMethodAccessorImpl.java:43) [na:1.6.0_23]
> >>      at java.lang.reflect.Method.invoke(Method.java:616) [na:1.6.0_23]
> >>      at
> >> org
> >> .apache
> >> .axis.providers.java.RPCProvider.invokeMethod(RPCProvider.java:397)
> >> [axis-1.3-PATCHED.jar:na]
> >>      at
> >> org
> >> .apache
> >> .axis.providers.java.RPCProvider.processMessage(RPCProvider.java:
> >> 186) [axis-1.3-PATCHED.jar:na]
> >>      at
> >> org
> >> .apache.axis.providers.java.JavaProvider.invoke(JavaProvider.java:
> >> 323) [axis-1.3-PATCHED.jar:na]
> >>      at
> >> org
> >> .apache
> >> .axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:
> >> 32) [axis-1.3-PATCHED.jar:na]
> >>      at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118)
> >> [axis-1.3-PATCHED.jar:na]
> >>      at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83)
> >> [axis-1.3-PATCHED.jar:na]
> >>      at
> >> org.apache.axis.handlers.soap.SOAPService.invoke(SOAPService.java:
> >> 453) [axis-1.3-PATCHED.jar:na]
> >>      at org.apache.axis.server.AxisServer.invoke(AxisServer.java:281)
> >> [axis-1.3-PATCHED.jar:na]
> >>      at
> >> org.apache.axis.transport.http.AxisServlet.doPost(AxisServlet.java:
> >> 699) [axis-1.3-PATCHED.jar:na]
> >>      at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
> >> [servlet-api.jar:na]
> >>      at
> >> org
> >> .apache
> >> .axis.transport.http.AxisServletBase.service(AxisServletBase.java:
> >> 327) [axis-1.3-PATCHED.jar:na]
> >>      at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> >> [servlet-api.jar:na]
> >>      at
> >> org
> >> .apache
> >> .catalina
> >> .core
> >> .ApplicationFilterChain
> >> .internalDoFilter(ApplicationFilterChain.java:290) [catalina.jar:na]
> >>      at
> >> org
> >> .apache
> >> .catalina
> >> .core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:
> >> 206) [catalina.jar:na]
> >>      at
> >> org
> >> .fcrepo
> >> .server
> >> .security.servletfilters.FilterSetup.doFilter(FilterSetup.java:235)
> >> [fcrepo-server-3.4.2.jar:na]
> >>      at
> >> org
> >> .apache
> >> .catalina
> >> .core
> >> .ApplicationFilterChain
> >> .internalDoFilter(ApplicationFilterChain.java:235) [catalina.jar:na]
> >>      at
> >> org
> >> .apache
> >> .catalina
> >> .core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:
> >> 206) [catalina.jar:na]
> >>      at
> >> org
> >> .fcrepo
> >> .server
> >> .security.servletfilters.FilterSetup.doFilter(FilterSetup.java:235)
> >> [fcrepo-server-3.4.2.jar:na]
> >>      at
> >> org
> >> .apache
> >> .catalina
> >> .core
> >> .ApplicationFilterChain
> >> .internalDoFilter(ApplicationFilterChain.java:235) [catalina.jar:na]
> >>      at
> >> org
> >> .apache
> >> .catalina
> >> .core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:
> >> 206) [catalina.jar:na]
> >>      at
> >> org
> >> .fcrepo
> >> .server
> >> .security.servletfilters.FilterSetup.doFilter(FilterSetup.java:235)
> >> [fcrepo-server-3.4.2.jar:na]
> >>      at
> >> org
> >> .apache
> >> .catalina
> >> .core
> >> .ApplicationFilterChain
> >> .internalDoFilter(ApplicationFilterChain.java:235) [catalina.jar:na]
> >>      at
> >> org
> >> .apache
> >> .catalina
> >> .core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:
> >> 206) [catalina.jar:na]
> >>      at
> >> org
> >> .fcrepo
> >> .server
> >> .security.servletfilters.FilterSetup.doFilter(FilterSetup.java:235)
> >> [fcrepo-server-3.4.2.jar:na]
> >>      at
> >> org
> >> .apache
> >> .catalina
> >> .core
> >> .ApplicationFilterChain
> >> .internalDoFilter(ApplicationFilterChain.java:235) [catalina.jar:na]
> >>      at
> >> org
> >> .apache
> >> .catalina
> >> .core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:
> >> 206) [catalina.jar:na]
> >>      at
> >> org
> >> .fcrepo
> >> .server
> >> .security.servletfilters.FilterSetup.doFilter(FilterSetup.java:235)
> >> [fcrepo-server-3.4.2.jar:na]
> >>      at
> >> org
> >> .apache
> >> .catalina
> >> .core
> >> .ApplicationFilterChain
> >> .internalDoFilter(ApplicationFilterChain.java:235) [catalina.jar:na]
> >>      at
> >> org
> >> .apache
> >> .catalina
> >> .core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:
> >> 206) [catalina.jar:na]
> >>      at
> >> org
> >> .fcrepo
> >> .server
> >> .security.servletfilters.FilterSetup.doFilter(FilterSetup.java:235)
> >> [fcrepo-server-3.4.2.jar:na]
> >>      at
> >> org
> >> .apache
> >> .catalina
> >> .core
> >> .ApplicationFilterChain
> >> .internalDoFilter(ApplicationFilterChain.java:235) [catalina.jar:na]
> >>      at
> >> org
> >> .apache
> >> .catalina
> >> .core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:
> >> 206) [catalina.jar:na]
> >>      at
> >> org
> >> .apache
> >> .catalina
> >> .core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
> >> [catalina.jar:na]
> >>      at
> >> org
> >> .apache
> >> .catalina
> >> .core.StandardContextValve.invoke(StandardContextValve.java:191)
> >> [catalina.jar:na]
> >>      at
> >> org
> >> .apache
> >> .catalina
> >> .authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)
> >> [catalina.jar:na]
> >>      at
> >> org
> >> .apache
> >> .catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
> >> [catalina.jar:na]
> >>      at
> >> org
> >> .apache
> >> .catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> >> [catalina.jar:na]
> >>      at
> >> org
> >> .apache
> >> .catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:
> >> 109) [catalina.jar:na]
> >>      at
> >> org
> >> .apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:
> >> 293) [catalina.jar:na]
> >>      at
> >> org
> >> .apache.coyote.http11.Http11Processor.process(Http11Processor.java:
> >> 849) [tomcat-coyote.jar:na]
> >>      at org.apache.coyote.http11.Http11Protocol
> >> $Http11ConnectionHandler.process(Http11Protocol.java:583) [tomcat-
> >> coyote.jar:na]
> >>      at org.apache.tomcat.util.net.JIoEndpoint
> >> $Worker.run(JIoEndpoint.java:454) [tomcat-coyote.jar:na]
> >>      at java.lang.Thread.run(Thread.java:679) [na:1.6.0_23]
> >> Caused by: org.xml.sax.SAXException: Malformed URL:
> >> bitstream_613090.jpeg
> >>      at
> >> org
> >> .fcrepo
> >> .server
> >> .storage
> >> .translation
> >> .FOXMLDODeserializer.startElement(FOXMLDODeserializer.java:453)
> >> [fcrepo-server-3.4.2.jar:na]
> >>      at
> >> org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown
> >> Source) [xercesImpl-2.9.1.jar:na]
> >>      at
> >> org
> >> .apache
> >> .xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown
> >> Source) [xercesImpl-2.9.1.jar:na]
> >>      at
> >> org
> >> .apache
> >> .xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown
> >> Source) [xercesImpl-2.9.1.jar:na]
> >>      at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl
> >> $FragmentContentDispatcher.dispatch(Unknown Source)
> >> [xercesImpl-2.9.1.jar:na]
> >>      at
> >> org
> >> .apache
> >> .xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
> >> Source) [xercesImpl-2.9.1.jar:na]
> >>      at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
> >> Source) [xercesImpl-2.9.1.jar:na]
> >>      at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
> >> Source) [xercesImpl-2.9.1.jar:na]
> >>      at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> >> [xercesImpl-2.9.1.jar:na]
> >>      at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown
> >> Source) [xercesImpl-2.9.1.jar:na]
> >>      at org.apache.xerces.jaxp.SAXParserImpl
> >> $JAXPSAXParser.parse(Unknown Source) [xercesImpl-2.9.1.jar:na]
> >>      at org.apache.xerces.jaxp.SAXParserImpl.parse(Unknown Source)
> >> [xercesImpl-2.9.1.jar:na]
> >>      at javax.xml.parsers.SAXParser.parse(SAXParser.java:195) [na:
> >> 1.6.0_23]
> >>      at
> >> org
> >> .fcrepo
> >> .server
> >> .storage
> >> .translation
> >> .FOXMLDODeserializer.deserialize(FOXMLDODeserializer.java:253)
> >> [fcrepo-server-3.4.2.jar:na]
> >>      ... 60 common frames omitted
> >>
> >> I suspect that fedora SWORD is expecting a URL link to the file
> >> instead of a local file name. However, if that's the case, should
> >> be a easy fix in the code.
> >>
> >> Thanks,
> >> Ying
> >> On Mar 29, 2012, at 11:22 AM, Glen Robson 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
> >>>
> >>
> >
> >
>
>
>
> ------------------------------------------------------------------------------
> 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

Re: [sword-app-tech] migrate DSpace to Islandora using SWORD

From: Ying J. <Yin...@ri...> - 2012-03-30 20:02:32

Hi Glen,

You are right. In DSpace AIP mets, LOCTYPE = URL but the xlink:href is  
only a filename -
<FLocat LOCTYPE="URL" xlink:type="simple"  
xlink:href="bitstream_613090.jpeg"/>

I changed URL to OTHER and the error message in fedora log is gone.  
But there is still error report in http response. This time, the  
exception messages are in tomcat log -

Caused by: java.io.IOException: File doesn't exists:  
bitstream_613090.jpeg
	at  
org 
.purl 
.sword 
.server 
.fedora.fedoraObjects.LocalDatastream.upload(LocalDatastream.java:116)
	at  
org 
.purl 
.sword 
.server 
.fedora 
.fedoraObjects.FedoraObject.uploadLocalDatastreams(FedoraObject.java: 
240)

I put mets.xml file and all bitstreams under the same directory and  
run the CURL the same dir too. And there is no permission issue. Do  
you have any suggestions?

Thanks,
Ying

On Mar 29, 2012, at 5:34 PM, Glen Robson wrote:

> Hi Ying,
>
> Looking at the code it looks like you need to specify the full URL  
> if you use the LOCTYPE = URL in the FLocat for your METS:file but if  
> you use any other value for LOCTYPE it will try and upload a local  
> file to Fedora then ingest the object with a reference to the  
> uploaded file. Its been a while since I looked at this so let me  
> know if that works.
>
> Thanks
>
> Glen
>
> On 29 Mar 2012, at 22:58, Ying Jin wrote:
>
>> Hi Glen,
>>
>> Thanks for pointing out this possibility. Robin and Mark, thank you  
>> for the continue support.
>>
>> I tried an AIP mets and get following error messages in my log -
>>
>> ERROR 2012-03-29 16:33:11.068 [http-8080-3]  
>> (FedoraAPIMBindingSOAPHTTPImpl) Error ingesting
>> org.fcrepo.server.errors.ObjectIntegrityException: FOXML IO stream  
>> was bad : Malformed URL: bitstream_613090.jpeg
>> 	at  
>> org 
>> .fcrepo 
>> .server 
>> .storage 
>> .translation 
>> .FOXMLDODeserializer.deserialize(FOXMLDODeserializer.java:258)  
>> [fcrepo-server-3.4.2.jar:na]
>> 	at  
>> org 
>> .fcrepo 
>> .server 
>> .storage 
>> .translation.DOTranslatorImpl.deserialize(DOTranslatorImpl.java:75)  
>> [fcrepo-server-3.4.2.jar:na]
>> 	at  
>> org 
>> .fcrepo 
>> .server 
>> .storage 
>> .translation.DOTranslatorModule.deserialize(DOTranslatorModule.java: 
>> 126) [fcrepo-server-3.4.2.jar:na]
>> 	at  
>> org 
>> .fcrepo 
>> .server 
>> .storage.DefaultDOManager.getIngestWriter(DefaultDOManager.java: 
>> 802) [fcrepo-server-3.4.2.jar:na]
>> 	at  
>> org 
>> .fcrepo 
>> .server.management.DefaultManagement.ingest(DefaultManagement.java: 
>> 160) [fcrepo-server-3.4.2.jar:na]
>> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [na: 
>> 1.6.0_23]
>> 	at  
>> sun 
>> .reflect 
>> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)  
>> [na:1.6.0_23]
>> 	at  
>> sun 
>> .reflect 
>> .DelegatingMethodAccessorImpl 
>> .invoke(DelegatingMethodAccessorImpl.java:43) [na:1.6.0_23]
>> 	at java.lang.reflect.Method.invoke(Method.java:616) [na:1.6.0_23]
>> 	at  
>> org 
>> .fcrepo 
>> .server 
>> .messaging 
>> .NotificationInvocationHandler 
>> .invoke(NotificationInvocationHandler.java:68) [fcrepo- 
>> server-3.4.2.jar:na]
>> 	at $Proxy4.ingest(Unknown Source) [na:na]
>> 	at  
>> org 
>> .fcrepo 
>> .server.management.ManagementModule.ingest(ManagementModule.java: 
>> 354) [fcrepo-server-3.4.2.jar:na]
>> 	at  
>> org 
>> .fcrepo 
>> .server 
>> .management 
>> .FedoraAPIMBindingSOAPHTTPImpl 
>> .ingest(FedoraAPIMBindingSOAPHTTPImpl.java:83) [fcrepo- 
>> server-3.4.2.jar:na]
>> 	at  
>> org 
>> .fcrepo 
>> .server 
>> .management 
>> .FedoraAPIMBindingSOAPHTTPSkeleton 
>> .ingest(FedoraAPIMBindingSOAPHTTPSkeleton.java:355) [fcrepo- 
>> common-3.4.2.jar:na]
>> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [na: 
>> 1.6.0_23]
>> 	at  
>> sun 
>> .reflect 
>> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)  
>> [na:1.6.0_23]
>> 	at  
>> sun 
>> .reflect 
>> .DelegatingMethodAccessorImpl 
>> .invoke(DelegatingMethodAccessorImpl.java:43) [na:1.6.0_23]
>> 	at java.lang.reflect.Method.invoke(Method.java:616) [na:1.6.0_23]
>> 	at  
>> org 
>> .apache 
>> .axis.providers.java.RPCProvider.invokeMethod(RPCProvider.java:397)  
>> [axis-1.3-PATCHED.jar:na]
>> 	at  
>> org 
>> .apache 
>> .axis.providers.java.RPCProvider.processMessage(RPCProvider.java: 
>> 186) [axis-1.3-PATCHED.jar:na]
>> 	at  
>> org 
>> .apache.axis.providers.java.JavaProvider.invoke(JavaProvider.java: 
>> 323) [axis-1.3-PATCHED.jar:na]
>> 	at  
>> org 
>> .apache 
>> .axis.strategies.InvocationStrategy.visit(InvocationStrategy.java: 
>> 32) [axis-1.3-PATCHED.jar:na]
>> 	at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118)  
>> [axis-1.3-PATCHED.jar:na]
>> 	at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83)  
>> [axis-1.3-PATCHED.jar:na]
>> 	at  
>> org.apache.axis.handlers.soap.SOAPService.invoke(SOAPService.java: 
>> 453) [axis-1.3-PATCHED.jar:na]
>> 	at org.apache.axis.server.AxisServer.invoke(AxisServer.java:281)  
>> [axis-1.3-PATCHED.jar:na]
>> 	at  
>> org.apache.axis.transport.http.AxisServlet.doPost(AxisServlet.java: 
>> 699) [axis-1.3-PATCHED.jar:na]
>> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)  
>> [servlet-api.jar:na]
>> 	at  
>> org 
>> .apache 
>> .axis.transport.http.AxisServletBase.service(AxisServletBase.java: 
>> 327) [axis-1.3-PATCHED.jar:na]
>> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)  
>> [servlet-api.jar:na]
>> 	at  
>> org 
>> .apache 
>> .catalina 
>> .core 
>> .ApplicationFilterChain 
>> .internalDoFilter(ApplicationFilterChain.java:290) [catalina.jar:na]
>> 	at  
>> org 
>> .apache 
>> .catalina 
>> .core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java: 
>> 206) [catalina.jar:na]
>> 	at  
>> org 
>> .fcrepo 
>> .server 
>> .security.servletfilters.FilterSetup.doFilter(FilterSetup.java:235)  
>> [fcrepo-server-3.4.2.jar:na]
>> 	at  
>> org 
>> .apache 
>> .catalina 
>> .core 
>> .ApplicationFilterChain 
>> .internalDoFilter(ApplicationFilterChain.java:235) [catalina.jar:na]
>> 	at  
>> org 
>> .apache 
>> .catalina 
>> .core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java: 
>> 206) [catalina.jar:na]
>> 	at  
>> org 
>> .fcrepo 
>> .server 
>> .security.servletfilters.FilterSetup.doFilter(FilterSetup.java:235)  
>> [fcrepo-server-3.4.2.jar:na]
>> 	at  
>> org 
>> .apache 
>> .catalina 
>> .core 
>> .ApplicationFilterChain 
>> .internalDoFilter(ApplicationFilterChain.java:235) [catalina.jar:na]
>> 	at  
>> org 
>> .apache 
>> .catalina 
>> .core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java: 
>> 206) [catalina.jar:na]
>> 	at  
>> org 
>> .fcrepo 
>> .server 
>> .security.servletfilters.FilterSetup.doFilter(FilterSetup.java:235)  
>> [fcrepo-server-3.4.2.jar:na]
>> 	at  
>> org 
>> .apache 
>> .catalina 
>> .core 
>> .ApplicationFilterChain 
>> .internalDoFilter(ApplicationFilterChain.java:235) [catalina.jar:na]
>> 	at  
>> org 
>> .apache 
>> .catalina 
>> .core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java: 
>> 206) [catalina.jar:na]
>> 	at  
>> org 
>> .fcrepo 
>> .server 
>> .security.servletfilters.FilterSetup.doFilter(FilterSetup.java:235)  
>> [fcrepo-server-3.4.2.jar:na]
>> 	at  
>> org 
>> .apache 
>> .catalina 
>> .core 
>> .ApplicationFilterChain 
>> .internalDoFilter(ApplicationFilterChain.java:235) [catalina.jar:na]
>> 	at  
>> org 
>> .apache 
>> .catalina 
>> .core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java: 
>> 206) [catalina.jar:na]
>> 	at  
>> org 
>> .fcrepo 
>> .server 
>> .security.servletfilters.FilterSetup.doFilter(FilterSetup.java:235)  
>> [fcrepo-server-3.4.2.jar:na]
>> 	at  
>> org 
>> .apache 
>> .catalina 
>> .core 
>> .ApplicationFilterChain 
>> .internalDoFilter(ApplicationFilterChain.java:235) [catalina.jar:na]
>> 	at  
>> org 
>> .apache 
>> .catalina 
>> .core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java: 
>> 206) [catalina.jar:na]
>> 	at  
>> org 
>> .fcrepo 
>> .server 
>> .security.servletfilters.FilterSetup.doFilter(FilterSetup.java:235)  
>> [fcrepo-server-3.4.2.jar:na]
>> 	at  
>> org 
>> .apache 
>> .catalina 
>> .core 
>> .ApplicationFilterChain 
>> .internalDoFilter(ApplicationFilterChain.java:235) [catalina.jar:na]
>> 	at  
>> org 
>> .apache 
>> .catalina 
>> .core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java: 
>> 206) [catalina.jar:na]
>> 	at  
>> org 
>> .apache 
>> .catalina 
>> .core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)  
>> [catalina.jar:na]
>> 	at  
>> org 
>> .apache 
>> .catalina 
>> .core.StandardContextValve.invoke(StandardContextValve.java:191)  
>> [catalina.jar:na]
>> 	at  
>> org 
>> .apache 
>> .catalina 
>> .authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)  
>> [catalina.jar:na]
>> 	at  
>> org 
>> .apache 
>> .catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)  
>> [catalina.jar:na]
>> 	at  
>> org 
>> .apache 
>> .catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)  
>> [catalina.jar:na]
>> 	at  
>> org 
>> .apache 
>> .catalina.core.StandardEngineValve.invoke(StandardEngineValve.java: 
>> 109) [catalina.jar:na]
>> 	at  
>> org 
>> .apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java: 
>> 293) [catalina.jar:na]
>> 	at  
>> org 
>> .apache.coyote.http11.Http11Processor.process(Http11Processor.java: 
>> 849) [tomcat-coyote.jar:na]
>> 	at org.apache.coyote.http11.Http11Protocol 
>> $Http11ConnectionHandler.process(Http11Protocol.java:583) [tomcat- 
>> coyote.jar:na]
>> 	at org.apache.tomcat.util.net.JIoEndpoint 
>> $Worker.run(JIoEndpoint.java:454) [tomcat-coyote.jar:na]
>> 	at java.lang.Thread.run(Thread.java:679) [na:1.6.0_23]
>> Caused by: org.xml.sax.SAXException: Malformed URL:  
>> bitstream_613090.jpeg
>> 	at  
>> org 
>> .fcrepo 
>> .server 
>> .storage 
>> .translation 
>> .FOXMLDODeserializer.startElement(FOXMLDODeserializer.java:453)  
>> [fcrepo-server-3.4.2.jar:na]
>> 	at  
>> org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown  
>> Source) [xercesImpl-2.9.1.jar:na]
>> 	at  
>> org 
>> .apache 
>> .xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown  
>> Source) [xercesImpl-2.9.1.jar:na]
>> 	at  
>> org 
>> .apache 
>> .xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown  
>> Source) [xercesImpl-2.9.1.jar:na]
>> 	at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl 
>> $FragmentContentDispatcher.dispatch(Unknown Source)  
>> [xercesImpl-2.9.1.jar:na]
>> 	at  
>> org 
>> .apache 
>> .xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown  
>> Source) [xercesImpl-2.9.1.jar:na]
>> 	at org.apache.xerces.parsers.XML11Configuration.parse(Unknown  
>> Source) [xercesImpl-2.9.1.jar:na]
>> 	at org.apache.xerces.parsers.XML11Configuration.parse(Unknown  
>> Source) [xercesImpl-2.9.1.jar:na]
>> 	at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)  
>> [xercesImpl-2.9.1.jar:na]
>> 	at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown  
>> Source) [xercesImpl-2.9.1.jar:na]
>> 	at org.apache.xerces.jaxp.SAXParserImpl 
>> $JAXPSAXParser.parse(Unknown Source) [xercesImpl-2.9.1.jar:na]
>> 	at org.apache.xerces.jaxp.SAXParserImpl.parse(Unknown Source)  
>> [xercesImpl-2.9.1.jar:na]
>> 	at javax.xml.parsers.SAXParser.parse(SAXParser.java:195) [na: 
>> 1.6.0_23]
>> 	at  
>> org 
>> .fcrepo 
>> .server 
>> .storage 
>> .translation 
>> .FOXMLDODeserializer.deserialize(FOXMLDODeserializer.java:253)  
>> [fcrepo-server-3.4.2.jar:na]
>> 	... 60 common frames omitted
>>
>> I suspect that fedora SWORD is expecting a URL link to the file  
>> instead of a local file name. However, if that's the case, should  
>> be a easy fix in the code.
>>
>> Thanks,
>> Ying
>> On Mar 29, 2012, at 11:22 AM, Glen Robson 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
>>>
>>
>
>

Re: [sword-app-tech] migrate DSpace to Islandora using SWORD

From: Glen R. <gle...@ll...> - 2012-03-29 22:34:15

Hi Ying,

Looking at the code it looks like you need to specify the full URL if you use the LOCTYPE = URL in the FLocat for your METS:file but if you use any other value for LOCTYPE it will try and upload a local file to Fedora then ingest the object with a reference to the uploaded file. Its been a while since I looked at this so let me know if that works.

Thanks

Glen
 
On 29 Mar 2012, at 22:58, Ying Jin wrote:

> Hi Glen,
> 
> Thanks for pointing out this possibility. Robin and Mark, thank you for the continue support.
> 
> I tried an AIP mets and get following error messages in my log -
> 
> ERROR 2012-03-29 16:33:11.068 [http-8080-3] (FedoraAPIMBindingSOAPHTTPImpl) Error ingesting
> org.fcrepo.server.errors.ObjectIntegrityException: FOXML IO stream was bad : Malformed URL: bitstream_613090.jpeg
> 	at org.fcrepo.server.storage.translation.FOXMLDODeserializer.deserialize(FOXMLDODeserializer.java:258) [fcrepo-server-3.4.2.jar:na]
> 	at org.fcrepo.server.storage.translation.DOTranslatorImpl.deserialize(DOTranslatorImpl.java:75) [fcrepo-server-3.4.2.jar:na]
> 	at org.fcrepo.server.storage.translation.DOTranslatorModule.deserialize(DOTranslatorModule.java:126) [fcrepo-server-3.4.2.jar:na]
> 	at org.fcrepo.server.storage.DefaultDOManager.getIngestWriter(DefaultDOManager.java:802) [fcrepo-server-3.4.2.jar:na]
> 	at org.fcrepo.server.management.DefaultManagement.ingest(DefaultManagement.java:160) [fcrepo-server-3.4.2.jar:na]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [na:1.6.0_23]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [na:1.6.0_23]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [na:1.6.0_23]
> 	at java.lang.reflect.Method.invoke(Method.java:616) [na:1.6.0_23]
> 	at org.fcrepo.server.messaging.NotificationInvocationHandler.invoke(NotificationInvocationHandler.java:68) [fcrepo-server-3.4.2.jar:na]
> 	at $Proxy4.ingest(Unknown Source) [na:na]
> 	at org.fcrepo.server.management.ManagementModule.ingest(ManagementModule.java:354) [fcrepo-server-3.4.2.jar:na]
> 	at org.fcrepo.server.management.FedoraAPIMBindingSOAPHTTPImpl.ingest(FedoraAPIMBindingSOAPHTTPImpl.java:83) [fcrepo-server-3.4.2.jar:na]
> 	at org.fcrepo.server.management.FedoraAPIMBindingSOAPHTTPSkeleton.ingest(FedoraAPIMBindingSOAPHTTPSkeleton.java:355) [fcrepo-common-3.4.2.jar:na]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [na:1.6.0_23]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [na:1.6.0_23]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [na:1.6.0_23]
> 	at java.lang.reflect.Method.invoke(Method.java:616) [na:1.6.0_23]
> 	at org.apache.axis.providers.java.RPCProvider.invokeMethod(RPCProvider.java:397) [axis-1.3-PATCHED.jar:na]
> 	at org.apache.axis.providers.java.RPCProvider.processMessage(RPCProvider.java:186) [axis-1.3-PATCHED.jar:na]
> 	at org.apache.axis.providers.java.JavaProvider.invoke(JavaProvider.java:323) [axis-1.3-PATCHED.jar:na]
> 	at org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32) [axis-1.3-PATCHED.jar:na]
> 	at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118) [axis-1.3-PATCHED.jar:na]
> 	at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83) [axis-1.3-PATCHED.jar:na]
> 	at org.apache.axis.handlers.soap.SOAPService.invoke(SOAPService.java:453) [axis-1.3-PATCHED.jar:na]
> 	at org.apache.axis.server.AxisServer.invoke(AxisServer.java:281) [axis-1.3-PATCHED.jar:na]
> 	at org.apache.axis.transport.http.AxisServlet.doPost(AxisServlet.java:699) [axis-1.3-PATCHED.jar:na]
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:637) [servlet-api.jar:na]
> 	at org.apache.axis.transport.http.AxisServletBase.service(AxisServletBase.java:327) [axis-1.3-PATCHED.jar:na]
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) [servlet-api.jar:na]
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) [catalina.jar:na]
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) [catalina.jar:na]
> 	at org.fcrepo.server.security.servletfilters.FilterSetup.doFilter(FilterSetup.java:235) [fcrepo-server-3.4.2.jar:na]
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) [catalina.jar:na]
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) [catalina.jar:na]
> 	at org.fcrepo.server.security.servletfilters.FilterSetup.doFilter(FilterSetup.java:235) [fcrepo-server-3.4.2.jar:na]
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) [catalina.jar:na]
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) [catalina.jar:na]
> 	at org.fcrepo.server.security.servletfilters.FilterSetup.doFilter(FilterSetup.java:235) [fcrepo-server-3.4.2.jar:na]
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) [catalina.jar:na]
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) [catalina.jar:na]
> 	at org.fcrepo.server.security.servletfilters.FilterSetup.doFilter(FilterSetup.java:235) [fcrepo-server-3.4.2.jar:na]
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) [catalina.jar:na]
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) [catalina.jar:na]
> 	at org.fcrepo.server.security.servletfilters.FilterSetup.doFilter(FilterSetup.java:235) [fcrepo-server-3.4.2.jar:na]
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) [catalina.jar:na]
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) [catalina.jar:na]
> 	at org.fcrepo.server.security.servletfilters.FilterSetup.doFilter(FilterSetup.java:235) [fcrepo-server-3.4.2.jar:na]
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) [catalina.jar:na]
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) [catalina.jar:na]
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) [catalina.jar:na]
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) [catalina.jar:na]
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525) [catalina.jar:na]
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) [catalina.jar:na]
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [catalina.jar:na]
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [catalina.jar:na]
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) [catalina.jar:na]
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849) [tomcat-coyote.jar:na]
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) [tomcat-coyote.jar:na]
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454) [tomcat-coyote.jar:na]
> 	at java.lang.Thread.run(Thread.java:679) [na:1.6.0_23]
> Caused by: org.xml.sax.SAXException: Malformed URL: bitstream_613090.jpeg
> 	at org.fcrepo.server.storage.translation.FOXMLDODeserializer.startElement(FOXMLDODeserializer.java:453) [fcrepo-server-3.4.2.jar:na]
> 	at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) [xercesImpl-2.9.1.jar:na]
> 	at org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown Source) [xercesImpl-2.9.1.jar:na]
> 	at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source) [xercesImpl-2.9.1.jar:na]
> 	at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) [xercesImpl-2.9.1.jar:na]
> 	at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) [xercesImpl-2.9.1.jar:na]
> 	at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) [xercesImpl-2.9.1.jar:na]
> 	at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) [xercesImpl-2.9.1.jar:na]
> 	at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) [xercesImpl-2.9.1.jar:na]
> 	at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) [xercesImpl-2.9.1.jar:na]
> 	at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) [xercesImpl-2.9.1.jar:na]
> 	at org.apache.xerces.jaxp.SAXParserImpl.parse(Unknown Source) [xercesImpl-2.9.1.jar:na]
> 	at javax.xml.parsers.SAXParser.parse(SAXParser.java:195) [na:1.6.0_23]
> 	at org.fcrepo.server.storage.translation.FOXMLDODeserializer.deserialize(FOXMLDODeserializer.java:253) [fcrepo-server-3.4.2.jar:na]
> 	... 60 common frames omitted
> 
> I suspect that fedora SWORD is expecting a URL link to the file instead of a local file name. However, if that's the case, should be a easy fix in the code.
> 
> Thanks,
> Ying
> On Mar 29, 2012, at 11:22 AM, Glen Robson 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
>> 
>

Re: [sword-app-tech] migrate DSpace to Islandora using SWORD

From: Ying J. <Yin...@ri...> - 2012-03-29 21:58:51

Hi Glen,

Thanks for pointing out this possibility. Robin and Mark, thank you  
for the continue support.

I tried an AIP mets and get following error messages in my log -

ERROR 2012-03-29 16:33:11.068 [http-8080-3]  
(FedoraAPIMBindingSOAPHTTPImpl) Error ingesting
org.fcrepo.server.errors.ObjectIntegrityException: FOXML IO stream was  
bad : Malformed URL: bitstream_613090.jpeg
	at  
org 
.fcrepo 
.server 
.storage 
.translation.FOXMLDODeserializer.deserialize(FOXMLDODeserializer.java: 
258) [fcrepo-server-3.4.2.jar:na]
	at  
org 
.fcrepo 
.server 
.storage 
.translation.DOTranslatorImpl.deserialize(DOTranslatorImpl.java:75)  
[fcrepo-server-3.4.2.jar:na]
	at  
org 
.fcrepo 
.server 
.storage 
.translation.DOTranslatorModule.deserialize(DOTranslatorModule.java: 
126) [fcrepo-server-3.4.2.jar:na]
	at  
org 
.fcrepo 
.server.storage.DefaultDOManager.getIngestWriter(DefaultDOManager.java: 
802) [fcrepo-server-3.4.2.jar:na]
	at  
org 
.fcrepo 
.server.management.DefaultManagement.ingest(DefaultManagement.java: 
160) [fcrepo-server-3.4.2.jar:na]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [na: 
1.6.0_23]
	at  
sun 
.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java: 
57) [na:1.6.0_23]
	at  
sun 
.reflect 
.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: 
43) [na:1.6.0_23]
	at java.lang.reflect.Method.invoke(Method.java:616) [na:1.6.0_23]
	at  
org 
.fcrepo 
.server 
.messaging 
.NotificationInvocationHandler 
.invoke(NotificationInvocationHandler.java:68) [fcrepo- 
server-3.4.2.jar:na]
	at $Proxy4.ingest(Unknown Source) [na:na]
	at  
org 
.fcrepo 
.server.management.ManagementModule.ingest(ManagementModule.java:354)  
[fcrepo-server-3.4.2.jar:na]
	at  
org 
.fcrepo 
.server 
.management 
.FedoraAPIMBindingSOAPHTTPImpl 
.ingest(FedoraAPIMBindingSOAPHTTPImpl.java:83) [fcrepo- 
server-3.4.2.jar:na]
	at  
org 
.fcrepo 
.server 
.management 
.FedoraAPIMBindingSOAPHTTPSkeleton 
.ingest(FedoraAPIMBindingSOAPHTTPSkeleton.java:355) [fcrepo- 
common-3.4.2.jar:na]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [na: 
1.6.0_23]
	at  
sun 
.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java: 
57) [na:1.6.0_23]
	at  
sun 
.reflect 
.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: 
43) [na:1.6.0_23]
	at java.lang.reflect.Method.invoke(Method.java:616) [na:1.6.0_23]
	at  
org 
.apache.axis.providers.java.RPCProvider.invokeMethod(RPCProvider.java: 
397) [axis-1.3-PATCHED.jar:na]
	at  
org 
.apache 
.axis.providers.java.RPCProvider.processMessage(RPCProvider.java:186)  
[axis-1.3-PATCHED.jar:na]
	at  
org.apache.axis.providers.java.JavaProvider.invoke(JavaProvider.java: 
323) [axis-1.3-PATCHED.jar:na]
	at  
org 
.apache 
.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32)  
[axis-1.3-PATCHED.jar:na]
	at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118)  
[axis-1.3-PATCHED.jar:na]
	at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83) [axis-1.3- 
PATCHED.jar:na]
	at org.apache.axis.handlers.soap.SOAPService.invoke(SOAPService.java: 
453) [axis-1.3-PATCHED.jar:na]
	at org.apache.axis.server.AxisServer.invoke(AxisServer.java:281)  
[axis-1.3-PATCHED.jar:na]
	at org.apache.axis.transport.http.AxisServlet.doPost(AxisServlet.java: 
699) [axis-1.3-PATCHED.jar:na]
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)  
[servlet-api.jar:na]
	at  
org 
.apache 
.axis.transport.http.AxisServletBase.service(AxisServletBase.java:327)  
[axis-1.3-PATCHED.jar:na]
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)  
[servlet-api.jar:na]
	at  
org 
.apache 
.catalina 
.core 
.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java: 
290) [catalina.jar:na]
	at  
org 
.apache 
.catalina 
.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)  
[catalina.jar:na]
	at  
org 
.fcrepo 
.server.security.servletfilters.FilterSetup.doFilter(FilterSetup.java: 
235) [fcrepo-server-3.4.2.jar:na]
	at  
org 
.apache 
.catalina 
.core 
.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java: 
235) [catalina.jar:na]
	at  
org 
.apache 
.catalina 
.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)  
[catalina.jar:na]
	at  
org 
.fcrepo 
.server.security.servletfilters.FilterSetup.doFilter(FilterSetup.java: 
235) [fcrepo-server-3.4.2.jar:na]
	at  
org 
.apache 
.catalina 
.core 
.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java: 
235) [catalina.jar:na]
	at  
org 
.apache 
.catalina 
.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)  
[catalina.jar:na]
	at  
org 
.fcrepo 
.server.security.servletfilters.FilterSetup.doFilter(FilterSetup.java: 
235) [fcrepo-server-3.4.2.jar:na]
	at  
org 
.apache 
.catalina 
.core 
.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java: 
235) [catalina.jar:na]
	at  
org 
.apache 
.catalina 
.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)  
[catalina.jar:na]
	at  
org 
.fcrepo 
.server.security.servletfilters.FilterSetup.doFilter(FilterSetup.java: 
235) [fcrepo-server-3.4.2.jar:na]
	at  
org 
.apache 
.catalina 
.core 
.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java: 
235) [catalina.jar:na]
	at  
org 
.apache 
.catalina 
.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)  
[catalina.jar:na]
	at  
org 
.fcrepo 
.server.security.servletfilters.FilterSetup.doFilter(FilterSetup.java: 
235) [fcrepo-server-3.4.2.jar:na]
	at  
org 
.apache 
.catalina 
.core 
.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java: 
235) [catalina.jar:na]
	at  
org 
.apache 
.catalina 
.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)  
[catalina.jar:na]
	at  
org 
.fcrepo 
.server.security.servletfilters.FilterSetup.doFilter(FilterSetup.java: 
235) [fcrepo-server-3.4.2.jar:na]
	at  
org 
.apache 
.catalina 
.core 
.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java: 
235) [catalina.jar:na]
	at  
org 
.apache 
.catalina 
.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)  
[catalina.jar:na]
	at  
org 
.apache 
.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java: 
233) [catalina.jar:na]
	at  
org 
.apache 
.catalina.core.StandardContextValve.invoke(StandardContextValve.java: 
191) [catalina.jar:na]
	at  
org 
.apache 
.catalina 
.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)  
[catalina.jar:na]
	at  
org 
.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java: 
128) [catalina.jar:na]
	at  
org 
.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java: 
102) [catalina.jar:na]
	at  
org 
.apache 
.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java: 
109) [catalina.jar:na]
	at  
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java: 
293) [catalina.jar:na]
	at  
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java: 
849) [tomcat-coyote.jar:na]
	at org.apache.coyote.http11.Http11Protocol 
$Http11ConnectionHandler.process(Http11Protocol.java:583) [tomcat- 
coyote.jar:na]
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java: 
454) [tomcat-coyote.jar:na]
	at java.lang.Thread.run(Thread.java:679) [na:1.6.0_23]
Caused by: org.xml.sax.SAXException: Malformed URL:  
bitstream_613090.jpeg
	at  
org 
.fcrepo 
.server 
.storage 
.translation.FOXMLDODeserializer.startElement(FOXMLDODeserializer.java: 
453) [fcrepo-server-3.4.2.jar:na]
	at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown  
Source) [xercesImpl-2.9.1.jar:na]
	at  
org 
.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown  
Source) [xercesImpl-2.9.1.jar:na]
	at  
org 
.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown  
Source) [xercesImpl-2.9.1.jar:na]
	at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl 
$FragmentContentDispatcher.dispatch(Unknown Source)  
[xercesImpl-2.9.1.jar:na]
	at  
org 
.apache 
.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown  
Source) [xercesImpl-2.9.1.jar:na]
	at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)  
[xercesImpl-2.9.1.jar:na]
	at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)  
[xercesImpl-2.9.1.jar:na]
	at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)  
[xercesImpl-2.9.1.jar:na]
	at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)  
[xercesImpl-2.9.1.jar:na]
	at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown  
Source) [xercesImpl-2.9.1.jar:na]
	at org.apache.xerces.jaxp.SAXParserImpl.parse(Unknown Source)  
[xercesImpl-2.9.1.jar:na]
	at javax.xml.parsers.SAXParser.parse(SAXParser.java:195) [na:1.6.0_23]
	at  
org 
.fcrepo 
.server 
.storage 
.translation.FOXMLDODeserializer.deserialize(FOXMLDODeserializer.java: 
253) [fcrepo-server-3.4.2.jar:na]
	... 60 common frames omitted

I suspect that fedora SWORD is expecting a URL link to the file  
instead of a local file name. However, if that's the case, should be a  
easy fix in the code.

Thanks,
Ying
On Mar 29, 2012, at 11:22 AM, Glen Robson 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
>

13 messages has been excluded from this view by a project administrator.

Flat | Threaded

<< < 1 .. 10 11 12 13 14 .. 33 > >> (Page 12 of 33)