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
Received on Wed Nov 04 2009 - 22:39:49 EST