We are currently working on a project to provide an end-user interface to our Linked Data, and it will include external links: http://archiveshub.ac.uk/linkinglives/
To my mind, if you are going to create Linked Data, external links are very important, although that is graded as the 5-star approach, it seems to be where the power of Linked Data lies.
I think we'll be putting our external data into a separate Triple Store, as a means to separate out our data from other external data. We're looking at ways to record provenance and thinking about how this will work as an end-user experience. Clearly the persistence of external links is a major issue. It seems like this could be the main challenge for Linked Data in the march towards a more semantic web approach. We are considering the external data that we use, and the likely persistence of the links is an important factor in the data we select. The community will assume that sources like DBPedia and VIAF will not change their URIs - they would be very unpopular if they did. But its very early days and for many of us, we are still trying to work out how best to create out Linked Data. We are still warning that our own URIs are not yet stable - and we have, indeed, changed some of them as we work to refine our model and think about making the connections more useful. In the end, we don't even know if our service will continue to be funded, or if it will sit in the same domain long term.
Anyway, one of the interesting things about taking this approach is that it will allow us to contrast what is a much more non-domain approach to the domain-specific approach we use with our main service, storing EAD files. I'd love to hear about any other projects that are trying out Linked Data solutions.
Archives Hub Service Manager
[log in to unmask]
On 2 Mar 2012, at 23:04, Proffitt,Merrilee wrote:
> So I wonder what people think the difference is between using linked
> resources in finding aids and having systems that use open linked data?
> Isn't that the direction we all hope to move?
> Merrilee Proffitt, Senior Program Officer
> OCLC Research
> -----Original Message-----
> From: Encoded Archival Description List [mailto:[log in to unmask]] On
> Behalf Of Mark Carlson
> Sent: Friday, March 02, 2012 2:42 PM
> To: [log in to unmask]
> Subject: Re: Linking to external sources
> Links are volatile things. They're like a high maintenance relationship.
> You have to keep checking-in with them all the time to make sure
> they're still OK. When they're broken, you need to do everything in
> your power to fix them or you need to end the relationship, deciding
> it's just too much to deal with. :) Some relationships aren't fixable.
> Sometimes linked resources just decide to get up and walk out without
> even leaving you a note, leaving you only the 404 error that they
> generate. Remember, any link you put in will require on-going
> maintenance. (And remember, not maintaining them is a form of
> maintenance, just not a very good one.) We have thousands of links to
> digital content in our EAD finding aids. This content lives on another
> server. The URL that these links generate is about a million miles long
> (plus or minus are few hundred thousand miles). These are the most
> dangerous links of all. Forget the URL to your server changing, but
> what about when the parameters and switches that that URL contains
> change? Sure, you can globally change a URL string to a server, but
> these parameters and switches might be a little more tricky (especially
> when some of them become completely invalid). That is why I have our
> stylesheet manufacture the correct link to these digital resources on
> the fly, storing only the unique "pointers" in the EAD finding aid. In
> some cases, we do something called "auto-linking". Something like this
> can be used if the unique information can be gathered from elsewhere in
> the finding aid and massaged to turn it into a meaningful link. (This
> can be a time saver). I also use a local "mapping" technique for other
> local links, storing only the filename in the link itself and then
> having the stylesheet flesh out the link based on the mapping that I
> created. For instance, uw-pdf-mss might translate to
> http://www.somewhere.edu/findingaids/pdf/mss when the stylesheet parses
> the EAD file. Move the file somewhere else and just change the mapping
> in the stylesheet. Voila!
> For other external links, we just pray to the link-god-in-the-sky that
> the link won't die. Fortunately, we don't have too many of these types
> of links. And, truth be told, we try not to use them much.
> However, if we were really into external linking, I would create a
> "linkbase" which would store every external link we wanted to create.
> The EAD would then point to the linkbase. You'd run the linkbase
> through a link checker periodically to check the links. Any bad links
> could be fixed. Problem solved. Any dead links could be coded as such
> in the linkbase and when the stylesheet went to retrieve them, it would
> just NOT put in the link. It would be, essentially, an authority file of
> links. Generate a link to a resource and point an infinite number of
> things to it. (Instead of hardcoding the link in an infinite number of
> different files). We'd call it a "smart" link, or a link with an
> "attitude". You could also call it a "happy" link, since it makes the
> user and us happy at the same time. :)
> Another alternative, if you are concerned about the persistence of
> links, is to use a tool like OCLC's PURL system (purl.org). You add the
> link to purl and then you point your finding aid to the purl (i.e. the
> persistent) link. Theoretically you should never need to update the
> link in the finding aid. All the links are managed on PURL. Of course,
> this is one more thing you have to manage.
> I know this probably doesn't answer your question, but I think you just
> need to weigh the likelihood of a link remaining persistent with the
> inconvenience that NOT putting in a link might cause.
> On 3/1/2012 1:51 PM, Deena Schwimmer wrote:
>> I would like to know what others do as far as encoding links to
>> sources in your EADs. I have mostly thought about this with regards to
>> linking to other institutions' finding aids in <relatedmaterial>, but
>> this could also apply to <bibliography>, <bioghist>, and probably
>> I previously decided against encoding links I don't have control over,
>> regardless of how authoritative or stable they seem to be, so that I'm
>> not then forced to make sure they don't become broken, but with the
>> proliferation of digitized resources, I thought I'd revisit and see
>> others are doing.
>> Deena M. Schwimmer, Archivist
>> Yeshiva University Archives
>> */mail:/***500 W. 185th St. / New York, NY 10033 / */interoffice:
>> - 602
>> */email:/*[log in to unmask] <mailto:[log in to unmask]>/ */phone:/* (212)
>> 960-5451 / */fax:/* (212) 960-0066