It occurs to me that the temporary outage of VIAF illustrates one of the
most interesting trade-offs between "record-based" and "graph-based"
metadata.
On the one hand, Ross' proof-of-concept shows exactly why the sharing of
monolithic, "prose-based" bibliographic records can no longer keep up
with the wide variety of sources of information about the resources
libraries provide access to. It's a maintenance nightmare to track all
of this stuff in one record, and will eventually become impossible.
Linked data principles for interoperable metadata support combining
things from myriad places in the same way APIs and software like Umlaut
can combine disparate web-services and availability options.
On the other hand, the outage shows exactly why dynamic composites of
data from disparate sources can result in broken linkages and
temporarily incomplete views of metadata. Though this outage was short
by comparison, the insights posted by Dan Chudnov during the period
between lcsh.info going offline and id.loc.gov going live are just as
applicable here:
http://onebiglibrary.net/story/caching-and-proxying-linked-data
Perhaps providing this persistence layer will be an emerging role where
libraries can really contribute to the larger information discovery
ecosystem. Perhaps it can become, in part, the purview of libraries to
evaluate various linked-data sources, identify those that are most
useful to the information needs of our users and the discovery systems
we provide, and develop the persistence layers that help distribute
access through increased redundancy. Perhaps we could help to mitigate
the effects of single points-of-failure for the most valued resources,
such as LCSH, Dewey, distributed FOAF profiles, DBpedia, the NYTimes
recent linked-data endeavors, Thomas Reuters, VIAF, Freebase, or
whatever else we as a community collectively deem most trusted and useful.
We could become the vanguard of best practices for the selection and
consumption of linked data for use in the development of more usable and
more rich discovery environments.
Okay, back to work.
-Corey
-Corey
Ross Singer wrote:
> VIAF is back up, so you can see the creator/resource relationships again:
>
> http://lccn.heroku.com/m56000838
>
> -Ross.
>
> On Wed, Nov 4, 2009 at 11:38 PM, Corey A Harper <corey.harper_at_nyu.edu> wrote:
>> It's a damn good start, though.
>>
>> Thanks for the further info on the SRU check against viaf. I wondered why I
>> wasn't seeing anything for dcterms:creator in the representation at all, and
>> your explanation makes perfect sense. Very cool re: pulling additional URIs
>> from LC and making the foaf:made assertions on them. I'll have to check that
>> out when viaf comes back online.
>>
>> I completely agree about the perils of lacking a persistence layer. Almost
>> seems like it would make sense to cache remotely hosted data in a local
>> triplestore, though that's the tradeoff when building all this stuff
>> dynamically on-the-fly. Back to those discussions about caching and proxying
>> for when a service goes down or is taken offline.
>>
>> Thanks again for the very cool proof-of-concept, though!
>>
>> -Corey
>>
>> Ross Singer wrote:
>>> On Wed, Nov 4, 2009 at 8:36 PM, Corey Harper <corey.harper_at_nyu.edu> wrote:
>>>> This is *great*, Ross.
>>>>
>>> It's a *start*.
>>>
>>>> Ross - in the spirit of "Any and all recommendations welcome", how hard
>>>> do
>>>> you think it would be to hook these URIs into your quick proof of
>>>> concept?
>>> Well, actually, if the viaf server wasn't down, that's what you'd be
>>> seeing for dcterms:creator -- it does a SRU search against viaf and
>>> adds the URI and the foaf resource. �It then takes all of the name
>>> variants and does a SRU search against the LC catalog and makes
>>> foaf:made assertions back at all the LCCN uris from the results set.
>>>
>>> But, this is the peril of not having a persistence layer. �By doing it
>>> all dynamically, it's subject to the whims of the data providers, so
>>> when viaf.org is down, this doesn't work, or dbpedia's SPARQL endpoint
>>> times out, etc.
>>>
>>> -Ross.
>> --
>> Corey A Harper
>> Metadata Services Librarian
>> New York University Libraries
>> 20 Cooper Square, 3rd Floor
>> New York, NY 10003-7112
>> 212.998.2479
>> corey.harper_at_nyu.edu
>>
--
Corey A Harper
Metadata Services Librarian
New York University Libraries
20 Cooper Square, 3rd Floor
New York, NY 10003-7112
212.998.2479
corey.harper_at_nyu.edu
Received on Thu Nov 05 2009 - 17:05:26 EST