If you're interested using SKOS.

We are working up a system for DSpace name authority in SKOS/FOAF at Oregon
State. We have a simple django application prototype for editing the data,
and are working up a plugin for DSpace to access it over SPARQL. I'm
working on this substantially over the next week or so, and am happy to
share details over email or at Code4Lib.

Things Ed mentioned that we aren't doing yet:

  - Embedded metadata in HTML pages (we're just using djubby, but would be
interested in improving it to include RDFa
http://data.library.oregonstate.edu/person/f8d7)
  - JSON-LD (would be neat, but not a high priority for us, our data is
open and ntriples works for our current use-cases)
  - We don't have much (any?) external linking.
  - OpenSearch API. (this would be amazing to have).

Thanks for the ideas, Ed.

- Tom

On Thu, Jan 31, 2013 at 3:01 AM, Ed Summers <[log in to unmask]> wrote:

> 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
>