It may be useful to maintain local datastores for names: geographic, personal, or biological. Those databases can hold the appropriate linked data URIs like those for geonames, viaf, or eol, but, importantly, can also serve as a local authority for names *not* found in linked data sources. You could construct keys that conform to NMTOKEN, and the local infrastructure can look up the appropriate external URIs at delivery time. I'm taking this approach for TEI texts, where an @key attribute is available on many elements.
Peter C. Gorman
Head, University of Wisconsin Digital Collections Center
[log in to unmask]
On May 20, 2011, at 1:13 PM, Ethan Gruber wrote:
> I'm currently working on improving the interaction between EADitor and
> existing controlled vocabulary services, specifically geonames.org,
> for geographic names. Each geographic place has a URI (example,
> http://sws.geonames.org/4250542/) and an rdf representation
> (http://sws.geonames.org/4250542/about.rdf). It's important to
> capture the URI of the place name, especially when indexing the
> finding aid, because it will allow the capture of geographic
> coordinates and georeferencing of items within the collection.
> I could be wrong, but I don't think a URL will validate as a NMTOKEN
> or ID, so I don't think any existing attributes for <geogname> will
> suffice. I have been contemplating using extptr, which is one of the
> few elements that can occur within geogname. Example:
> <extptr href="http://sws.geonames.org/4250542/"/>
> The name of the place, Springfield, IL, is unnecessary to capture
> literally in the finding aid. It can be extracted at processing time
> from the geonames rdf service.
> Is anyone doing anything similar to this?
> Ethan Gruber
> American Numismatic Society