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