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 <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
------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
sword-app-tech mailing list
sword-app-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sword-app-tech