 |
 |
Of course after sending that I noticed a mistake, the curl example should look like: curl -i --header "Accept: application/json" http://id.library.osu.edu/person/123 HTTP/1.1 303 See Other date: Thu, 31 Jan 2013 10:47:44 GMT server: Apache/2.2.14 (Ubuntu) location: http://id.library.osu.edu/person/123.json vary: Accept-Encoding I didn't have it redirecting to the JSON previously. //Ed On Wed, Jan 30, 2013 at 4:19 PM, Phillips, Mark <[log in to unmask]> wrote: > Thanks for the prompt Ed, > > We've had a stupid simple vocabulary app for a few years now which we use > to manage all of our controlled vocabularies [1]. These are represented in our > metadata editing application as drop-downs and type ahead values as described > in the first email in this thread. Nothing too exciting. The entire vocabulary app > is available to our systems as xml, python or json objects. When we export our > records as RDF we try and use the links for these values instead of the strings. > > We are currently working on another simple app to manage names for our system > (UNT Name App). It takes into account some of the use cases described in this thread such as > disambiguation, variant names, and the all important linking to other vocabularies > of which VIAF, LC, and Wikipedia are the primary expected targets. Once populated > it is to be integrated into the metadata editing system to provide auto-complete > functions to the various name fields in our repository. > > As far as technology we've tried to crib off the Chronicling America site as much > as possible and follow the pattern of using the suggestions extension of OpenSearch [2] > to provide the API. > > Mark > > > > [1] http://digital2.library.unt.edu/vocabularies/ > [2] http://www.opensearch.org/Specifications/OpenSearch/Extensions/Suggestions/1.1 > > > > ________________________________________ > From: Code for Libraries [[log in to unmask]] on behalf of Ed Summers [[log in to unmask]] > Sent: Wednesday, January 30, 2013 2:15 PM > To: [log in to unmask] > Subject: Re: [CODE4LIB] Adding authority control to IR's that don't have it built in > > On Tue, Jan 29, 2013 at 5:19 PM, Kyle Banerjee <[log in to unmask]> wrote: >> This would certainly be a possibility for other projects, but the use case >> we're immediately concerned with requires an authority file that's >> maintained by our local archives. It contains all kinds of information >> about people (degrees, nicknames, etc) as well as terminology which is not >> technically kosher but which we know people use. > > Just as an aside really, I think there's a real opportunity for > libraries and archives to make their local thesauri and name indexes > available for integration into other applications both inside and > outside their institutional walls. Wikipedia, Freebase, VIAF are > great, but their notability guidelines don't always the greatest match > for cultural heritage organizations. So seriously consider putting a > little web app around the information you have, using it for > maintaining the data, making it available programatically (API), and > linking it out to other databases (VIAF, etc) as needed. > > A briefer/pithier way of saying this is to quote Mark Matienzo [1] > > Sooner or later, everyone needs a vocabulary management app. > > :-) > > //Ed > > PS. I think Mark Phillips has done some interesting work in this area > at UNT. But I don't have anything to point you at, maybe Mark is tuned > in, and can chime in. > > [1] https://twitter.com/anarchivist/status/269654403701682176