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
