Linking to external digital objects

[Creighton Barrett]

Hi David,

Thanks very much for your response.  I suppose what I meant was digital object linking, so this is quite helpful. 

I linked to a remote digital object using the "Link to digital object field," but it does not look like a local reference representation and thumbnail representation was created.  We are testing with handles generated by our DSpace repository (e.g., http://hdl.handle.net/10222/14541).  I can add the URI, but Atom doesn't seem to pick up the mime-type (mime-type is unknown).  Would that prevent the representations from being created?

Also, the URL to the reference representation is a dead link.  The handle is appended to the base URL of the Atom installation, and interestingly, the second part of the handle is duplicated:

http://URL/atom/http://hdl.handle.net/10222/1454114541

Any ideas?

As far as importing digital objects via linked URI, how are the hierarchical relationships maintained?  The METS profile you linked to supports Dublin Core, but can it also work with MODS descriptive data? 

We would really like to import the URIs with the EAD.  We have the URIs embedded in <dao> elements, but those don't import.  And when I export the XML from Atom after I manually add a URI, it doesn't seem to include the digital object information.  We just hired a new developer (yay!) who will be taking a look at all of this, so I would be interested to hear what you think the best course of action might be.  It seems like the options are:

a) Import EAD and then import digital objects via linked URI in a METS profile
b) Configure the EAD import to support <dao> links

Your help is much appreciated. 

Best regards,

Creighton

On 26 March 2012 21:21, David Juhasz <da...@artefactual.com> wrote:

Hi Creighton,

We haven't done any integration with ICA-AtoM and Fedora, dSpace or any other external repository, but I can respond to your questions about digital object linking.

ICA-AtoM does allow linking to external digital objects via URI.  You can link a remote digital object via the web UI, by following the steps for http://ica-atom.org/doc/Upload_digital_objects and using the "Link to an external digital object" field (see attached screenshot).  A local reference representation (scaled to fit the ICA-AtoM archival description template) and a thumbnail representation of the remote digital object will be created and stored on the ICA-AtoM server, but the "master" representation exists only as a link to the original resource.

At the code level we've had some success, at a purely experimental level, with importing digital objects via linked URI or base64 embedding in a *METS* import profile.  You can see the import  configuration for the METS profile here (lines 108 - 115):
http://code.google.com/p/qubit-toolkit/source/browse/trunk/apps/qubit/modules/object/config/import/mets.yml

The code above calls the "importFromUri()" method in the Digital Object class:
http://code.google.com/p/qubit-toolkit/source/browse/trunk/lib/model/QubitDigitalObject.php#510


Hope that helps!

David

--
David Juhasz,
Software Engineer

Artefactual Systems Inc.
www.artefactual.com

--
You received this message because you are subscribed to the Google Groups "ICA-AtoM Users" group.
To post to this group, send email to ica-atom-users@googlegroups.com.
To unsubscribe from this group, send email to ica-atom-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ica-atom-users?hl=en.

[David Juhasz]

Hi Creighton,

Please see my responses below. :)

On 12-03-30 09:23 AM, Creighton Barrett wrote:
> Hi David,
>
> Thanks very much for your response. I suppose what I meant was
> digital object linking, so this is quite helpful.
>
> I linked to a remote digital object using the "Link to digital object
> field," but it does not look like a local reference representation and
> thumbnail representation was created. We are testing with handles
> generated by our DSpace repository (e.g.,
> http://hdl.handle.net/10222/14541). I can add the URI, but Atom
> doesn't seem to pick up the mime-type (mime-type is unknown). Would
> that prevent the representations from being created?
>
> Also, the URL to the reference representation is a dead link. The
> handle is appended to the base URL of the Atom installation, and
> interestingly, the second part of the handle is duplicated:
>
> http://URL/atom/http://hdl.handle.net/10222/1454114541
>
> Any ideas?

I tried the <http://hdl.handle.net/10222/14541> link and it looks like
it's redirecting to an archival description at
<http://dalspace.library.dal.ca//handle/10222/14541>. For digital
object linking to work in ICA-AtoM, you need to link to the actual
digital object "file" (PDF, image, video, etc.), in this case I think
you want to use:

http://dalspace.library.dal.ca/bitstream/handle/10222/14541/New%20Plymouth%20Land%20Grant%20%28MS-6-2%29.pdf?sequence=1

(This link was in the "Files" section of the description you linked)

>
> As far as importing digital objects via linked URI, how are the
> hierarchical relationships maintained? The METS profile you linked to
> supports Dublin Core, but can it also work with MODS descriptive data?

There's no reason that this couldn't be made to work with MODS; however,
please be aware that ICA-AtoM doesn't currently support MODS import or
export.

>
> We would really like to import the URIs with the EAD. We have the
> URIs embedded in <dao> elements, but those don't import. And when I
> export the XML from Atom after I manually add a URI, it doesn't seem
> to include the digital object information. We just hired a new
> developer (yay!) who will be taking a look at all of this, so I would
> be interested to hear what you think the best course of action might
> be. It seems like the options are:
>
> a) Import EAD and then import digital objects via linked URI in a METS
> profile
> b) Configure the EAD import to support <dao> links
>
> Your help is much appreciated.
>

Great news about your developer! The code we are using for the METS
import template should work equally well for a MODS/METS profile or EAD
via the <dao> tag. I would recommend implementing the EAD <dao> tag as
the fastest and easiest way to get the functionality you need. The EAD
import / export profile is (almost) fully implemented in ICA-AtoM right
now, whereas a MODS import / export profile would need to be developed
from scratch. Also, this avoids having to do some sort of hybrid
EAD/METS import.

We'd love to integrate digital object import via EAD or METS/MODS into
ICA-AtoM, so we'll provide any help we can.

There is more documentation for the ICA-AtoM XML import/export library here:
http://www.qubit-toolkit.org/wiki/index.php?title=XML_import/export

More information about developing for Qubit Toolkit, the framework that
powers ICA-AtoM and DCB, can be found here:
http://www.qubit-toolkit.org/wiki/index.php?title=Development

We are also happy to answer questions for you developer via the Qubit
Toolkit Developers forum:
https://groups.google.com/forum/?fromgroups#!forum/qubit-dev

Regards,
David Juhasz

[Creighton Barrett]

David, thanks very much for your investigations and thorough response! 

I'm not at all fixed on MODS, but I wanted to ask about it because the Toolkit exports unqualifed Dublin Core in METS, but the MODS seems to be well-formed.  But I am not all that familiar with MODS/METS and that might not even be an issue! 
 
We will need to investigate this a bit.   Using the direct link to the "file" seems to defeat the purpose of having handles, but I agree that EAD <dao> is the way to go, for all the good reasons you've mentioned.  I am just wary of encoding non-stable URLs.  I guess we will need to decide what the main issue is - is it just importing the links to our repository or having the digital objects actually import into ICA-Atom so the representation copies can be created.  I think we'd be fine with just having the <dao> links import, but that would mean users of our instance of ICA-Atom wouldn't be able to use the digital object features (e.g., browse, filter, etc.) and our customizations might not meet the needs of other implementers who want to actually import digital objects via EAD. 

Curious - would the digital object linking work if we had the handle redirect to the actual object as opposed to the descriptive record?  Or does it *have* to be a direct link?  I think our DSpace is configured to redirect to the descriptive record so information can be provided about the file(s).  The descriptive records can also have more than one digital object, which is nice.  But I'm wondering if some of our local issues couldn't be resolved by reconfiguring DSpace...

Thanks again, David,

Creighton

[David Juhasz]

Hi Creighton,

Sorry for the tardiness of my reply, I've been very busy with the recent City of Vancouver ICA-AtoM launch (http://www.vancouverarchives.ca/2012/04/our-new-online-search/). :)

Please see my replies below.

On 12-04-03 10:42 AM, Creighton Barrett wrote:

We will need to investigate this a bit.   Using the direct link to the "file" seems to defeat the purpose of having handles, but I agree that EAD <dao> is the way to go, for all the good reasons you've mentioned.  I am just wary of encoding non-stable URLs.  I guess we will need to decide what the main issue is - is it just importing the links to our repository or having the digital objects actually import into ICA-Atom so the representation copies can be created.  I think we'd be fine with just having the <dao> links import, but that would mean users of our instance of ICA-Atom wouldn't be able to use the digital object features (e.g., browse, filter, etc.) and our customizations might not meet the needs of other implementers who want to actually import digital objects via EAD. 

The advantage to METS is that it allow embedding the digital object directly in the XML document as a base64 encoded bitstream via the <binData> element.  This embedding functionaity is why we chose METS for testing the AtoM digital object import functionality.  As far as I know, EAD doesn't have any provision for directly embedding a digital object within a descriptive record.

To be clear digital objects linked via the EAD <dao> element will be visible in the ICA-AtoM browse and search interfaces, and a reference and thumbnail representation will be created and stored on the ICA-AtoM filesystem (i.e. not on the remote server). However, you are correct that the original digital object is not stored locally, so non-stable URLs at the source are a real problem for long term access.

Curious - would the digital object linking work if we had the handle redirect to the actual object as opposed to the descriptive record?  Or does it *have* to be a direct link?  I think our DSpace is configured to redirect to the descriptive record so information can be provided about the file(s).  The descriptive records can also have more than one digital object, which is nice.  But I'm wondering if some of our local issues couldn't be resolved by reconfiguring DSpace...

I'm not sure how ICA-AtoM would handle a linking to a digital object via redirected URL, but you could experiment via the "link digital object - remote URL" web interface - the import mechanism should work the exact same way.  The remote URL definitely won't work if the redirect terminates at a descriptive page, the final destination must be the bitstream of the digital object, without any HTML or XML wrappers.


Regards,
David

[Creighton Barrett]

Thank you David, for helping to clarify all of this.  The City of Vancouver site is quite impressive!  Congratulations all around. 

Directly embedding the bitstream wont be an issue for us, as we're primarily concerned with importing links to external objects.  We will not be using the ICA-Atom storage (except for the copies), but we definitely want those thumbnails and reference copies, so the termination point of the URL will be an issue.  Getting <dao> to import will be the first step, but our <dao> information includes persistent URLs that terminate at a descriptive page, so we will need to figure something out.  I have no idea what that will be, or if it will even be possible, but I'm happy to at least understand the issue now! 

Thanks again David,

Creighton

--

You received this message because you are subscribed to the Google Groups "ICA-AtoM Users" group.

To post to this group, send email to ica-ato...@googlegroups.com.
To unsubscribe from this group, send email to ica-atom-user...@googlegroups.com.