Currently, we offer an Atom feed and a KML API. An RDF feed is currently in the works and will be released in the coming weeks. These APIs are based on queries to the Solr search index and can be adjusted based on the user's demands.
Object KML: http://numismatics.org/search/query.kml?q=*:*
Mint KML: http://numismatics.org/search/mints.kml?q=*:*
The feeds are formulated based on the Lucene query syntax. q=*:* passes a query for all results from all fields (i.e., the entire collection of objects). For example, http://numismatics.org/search/feed/?q=department_facet:"Greek" returns the Atom feed for all coins in the Greek department with 100 results per page. This is particularly useful to those who want to subscribe to the portion of the collection that is relevant to their own interests. The practicality of this feed extends beyond casual subscriptions to updates to the database. The Atom XML contains a reference to the next page in the feed. Each object entry includes a pointer to the HTML record of the coin, as well as pointers to other representations of the data, including, importantly, the source Encoded Archival Description XML file. This allows anyone to scrape the entire ANS collection. With more than 600,000 objects, the Atom feeds creates the potential for interesting quantitative analysis.
The KML APIs works similarly--feed it a Solr query and get results back that you can look at in Google Earth or a similar geographic framework. There are two APIs. The object API (query.kml) returns at most 500 results for the query, with points representing individual objects. The mint API returns a point for each mint the query illuminates. This is the foundation for the OpenLayers map function in MANTIS. There is no limit on the number of mints returned by this API. Providing access to thousands of coins (or the entire collection!) in a single KML file would probably bring down the server.
Refer to the Lucene query syntax linked above on appropriate text to pass to the q parameter. There are a wide variety of fields, detailed below. The field name typically corresponds with numismatic ontology or internal ANS database fields.
- unitid_text (accession number)
- persname_text (any personal name: artist, portrait, issuer, etc.)
- geogname_text (geographical name, including mint, locality, region, and findspot)
- fulltext (keyword search anywhere in the record)
- weight_sint (weight)
- era_sint (century)
- dob_sint (date on object)
- unitdate_display (date of coin, in textual terms. e.g. 16 BC - AD 3)
- obv_leg_display (obverse legend)
- obv_type_display (obverse type)
- rev_leg_display (reverse legend)
- rev_type_display (reverse type)
- prevcoll_display (previous collection)
- sernum_display (serial number)
- famname_facet (Dynasty)
- format_facet (object type)
- persname_facet (Person)
The 'imagesavailable' field can return objects with images if the value is set to 'true'
- mint_geo (geographic coordinates)
- mint_kml (nomisma.org mint KML URI)
A few notes. String fields (including mint_geo and mint_kml) require exact matches (enclosed by double quotes if the string is providing access to thousands of coins (or the entire collection!) in a single KML file would probably bring down the server.more than one word), but can accommodate Solr wildcards (* and ?).
Have at it!
http://numismatics.org/search/feed/?q=department_facet:"Islamic" AND weight_sint:[4 TO 5] - All Islamic coins that weigh between 4 and 5 grams
http://numismatics.org/search/feed/?q=type_text:temple AND imagesavailable:true AND department_facet:"Greek" - Greek coins depicting temples that have been photographed