Jenn,
I still don't think that I fully understand why you'd necessarily need to change the encoding, exactly, since Fedora would still be serving up the digital objects?
That said, you might want to contact UNC. They have two excellent ways to view the finding aid for their Thomas E. Watson collection. My guess is that the EAD is the same, but I don't know this for sure since I don't think that you can view the XML online:
http://www.lib.unc.edu/dc/watson/index.html/findingaid/ (all digital objects embedded; except for those hosted at the Internet Archive, though I'm pretty sure that that could be done, as well, if desired)
http://www.lib.unc.edu/mss/inv/w/Watson,Thomas_E.html
Maybe that'll help, since I think this is essentially what you're talking about? Also, I've only barely looked at the following website, but it should explain some of UNC's particular processes for that project: http://www.lib.unc.edu/mss/archivalmassdigitization/index.html
In any event, I hope that you'll share with the list whichever solution it is that you eventually employ.
Mark
-----Original Message-----
From: Encoded Archival Description List [mailto:[log in to unmask]] On Behalf Of Riley, Jenn
Sent: Thursday, July 29, 2010 6:28 PM
To: [log in to unmask]
Subject: Re: xlink:role usage
Hmm, in an effort to be straightforward I left out some detail in my earlier message, which seems to have had the opposite effect and led to confusion. My apologies.
Our links don't actually go to an object of a specific MIME type - they're standard PURL syntaxes that resolves to the "default" view of that object, as determined by our Fedora repository. Here's an example. Finding aid: http://purl.dlib.indiana.edu/iudl/findingaids/archives/InU-Ar-VAA2627; sample digitized object: http://purl.dlib.indiana.edu/iudl/archives/VAA2627-00009. That second PURL syntax is what goes in to the EAD, but it resolves to a page turning application, and I don't think it's really correct to use a MIME type to hint what that object is. First of all, it's several things - a webapp, HTML pages, lots of JPEGs, and second, photographs would also be JPEGs but would have a different delivery application. So I don't think a MIME type would be sufficient to do what we want.
This all works fine now that these PURLs resolve to the correct application based on information in our Fedora repository. But this is going to change, we think. The page turner application rendering that document now (which we call METS Navigator) is ready to be embedded inside XTF (where our finding aids are delivered), rather than taking the user from XTF to METS Navigator and making them go back and forth. We think this is a good change to make, but it will affect our EAD encoding practices. In this case, what we'd put in the dao/@xlink:href would be a PURL that resolves to METS file, but then we're bypassing the step we have currently where Fedora decides what the correct delivery application is. I was looking for a way to describe either a property of the object (paged, singleimage, oralhistoryaudio, musicalaudio) or a player name itself ([for us would be something like:] metsnav, imagesearch, oralhistoryplayer, variations) which XTF could use to call the correct embedded application to give users access to the content.
I also in general think putting a property of the object (rather than the player) into the EAD is a little more flexible, but was looking for information on whether this or the player indication is a better match for the semantics of xlink:role. And if xlink:role needs a URI, does that mean "paged" isn't kosher, but "http://www.dlib.indiana.edu/resourcetype/paged" would be? (BTW, the LC XLink schema defines xlink:role as a string.)
Thanks,
Jenn
> -----Original Message-----
> From: Encoded Archival Description List [mailto:[log in to unmask]]
> On Behalf Of Custer, Mark
> Sent: Thursday, July 29, 2010 4:44 PM
> To: [log in to unmask]
> Subject: Re: xlink:role usage
>
> My understanding is that if you include xlink:role, the value would
> have to be a URI, and you'd also have to choose between giving that
> element an xlink:type = simple | extended | locator | resource.
>
> And I agree that this sounds exciting. One question, though: instead
> of defining all of this within the EAD, could you instead just give the
> <dao> an xml:id, like an ark (archival resource key)? Your external
> system would still contain the information about what "player" should
> be used, and that information could be passed on that way so that it
> could be embedded within other delivery systems.
>
> Just a thought... obviously this would just ignore the issue, though
> (but, I also don't know of a single web browser that doesn't ignore
> most of the xlink specification anyway).
>
>
> Mark
>
>
>
> -----Original Message-----
> From: Encoded Archival Description List [mailto:[log in to unmask]]
> On Behalf Of Riley, Jenn
> Sent: Thursday, July 29, 2010 2:22 PM
> To: [log in to unmask]
> Subject: xlink:role usage
>
> Dear EAD folks,
>
> I'm looking for some clearer guidance than what I've been able to find
> online regarding the usage of xlink:role in EAD. In our finding aids,
> we use
> <dao> to link to digitized versions of components in our collections.
> We're
> now facing a situation where we can potentially be embedding
> players/viewers
> inside our finding aid display instead of linking out to external
> systems,
> which has got us pretty excited. But what this means for us is our
> <dao> now
> needs to be able to indicate what "player" should be used for a given
> link.
> Whether it's a paged digital object that needs a page turner to view, a
> sound recording that needs an audio player, etc.
>
> We're using the EAD2002 W3C XML Schema, and I'm thinking one of the
> xlink
> attributes on <dao> would probably be best for encoding information
> about
> what system should render a digitized archival object. Based on a
> review of
> the brief information on linking elements in the EAD Tag Library, the
> old
> Application Guidelines, and the W3C XLink specifications (which I'd
> never
> really looked at before and was sorry after I tried to), I'm thinking
> xlink:role is the most appropriate of the xlink attributes included in
> EAD.
> Do other folks agree this is the right direction to go? Or should I be
> looking at other options?
>
> If xlink:role is the appropriate place, I'm still uncertain as to
> exactly
> what the right usage should be. I see implementations and documentation
> that
> treat xlink:role as requiring a QName (basically a string but can't
> start
> with a number), in which case we could just use standardized
> terminology for
> our different display options. But I also see implementations and
> documentation which suggests these values should be full URIs. Is there
> a
> clear best practice between these two options?
>
> Would the semantics of xlink:role suggest the value be more appropriate
> as a
> property of the object ('pageturned', 'audio', etc.) or more
> appropriate as
> the name of the delivery system in which it should be rendered?
>
> I'm not finding the W3C XLink documentation to be much help to me in
> answering these questions. Does anyone know of other XLink resources
> that I
> might find more useful as I learn about this?
>
> Thanks for any thoughts you can provide,
>
> Jenn
>
> ========================
> Jenn Riley
> Metadata Librarian
> Digital Library Program
> Indiana University - Bloomington
> Wells Library W501
> (812) 856-5759
> www.dlib.indiana.edu
>
> Inquiring Librarian blog: www.inquiringlibrarian.blogspot.com
|