Hi Peter,

Loading the geonames data into a local index is something I am
considering.  This is what I am doing with LCSH terms in EADitor.
Locally-created subjects and LCSH terms share the same Solr index.  I
just found the Atom feed for, so I may opt the direction
of locally storing geonames data since updating the data is a

The question is which of the attributes allowable to EAD <geogname>
can be used to capture the id of the geoname (e.g. '4250542' for
Springfield, Illinois)?  What about @source: "geonames:4250542"?

The source attribute is defined as "The source of the controlled
vocabulary term contained in the element. Available in subelements of
<controlaccess>, i.e., <corpname>, <famname>, <function>, <genreform>,
<geogname>, <name>, <occupation>, <persname>, <physdesc>, <subject>,
and <title>."

Geonames is the organization responsible for creating the term.  The
examples on the EAD site use "lcsh" for subject terms.  Is there any
reason that the id of the term itself, relative to geonames' service,
cannot be captured directly within the EAD source attribute?


On Fri, May 20, 2011 at 2:56 PM, Peter Gorman <[log in to unmask]> wrote:
> Ethan,
> 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]
> (608) 265-5291
> 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,
>> for geographic names.  Each geographic place has a URI (example,
>> and an rdf representation
>> (  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:
>> <geogname>
>>   <extptr href=""/>
>> </geogname>
>> 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