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
> <glen.rob...@llgc.org.uk<javascript:_e({}, 'cvml',
> 'glen.rob...@llgc.org.uk');>
> > 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
------------------------------------------------------------------------------
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
sword-app-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sword-app-tech
