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