For several months, we have been hard at work developing an XML representation of coin hoard documentation. The data model, a derivative/relation of NUDS-XML (thus also influenced by other formats such as EAD and RDF), is still very much a draft, but one constantly growing in stability. It is, in theory, capable of meeting the requirements of various institutions. Groups of coins can be encoded by general typologies, e.g., total number of
denarii or total coins of a particular issuer or material. Groups of coins can point to nomisma ids for specific coin-types, like RRC or RIC numbers. Individual coins can also be described by precise physical measurements or attributes--counterstamps, weights, diameters--or point to URIs that represent those physical specimens online.
Let us examine the following XML snippet:
Coins and coinGrps can include any NUDS element from the descMeta--Physical, Typological, Reference Descriptions, etc. Like in NUDS, the nuds:typeDesc can point to a URI (in this case, a nomisma ID) with the semantic xlink:href attribute (very much like METS, EAD, EAC-CPF, and other XML standards).
A coin hoard may contain hundreds of distinct coin-types, but if these coin types are represented by nomisma IDs, the typological attributes do not need to be encoded directly within the hoard XML document. This not only enables the hoard documents to be fairly compact and concise, but also removes the burden of upkeep from the editors of hoard records, since the nomisma IDs are considered canonical representations of coin-type metadata.
When rendering the hoard XML document into HTML, Numishare can parse the RDF from the nomisma ID dynamically to render the following output:
The hoard contents are formatted in a table similar to what numismatists are accustomed, but rows can be expanded to see the full typological description, with links to nomisma, Wikipedia, and Pleiades. The format of this descriptive information is identical to that of physical coins and coin-types because the code is, in fact, identical. The closing date of the hoard can be established by parsing this collection of coin-type metadata even if the dates are not stored directly in the hoard record. The disadvantage of this framework, of course, is that it is more processor intensive than querying and rendering data stored directly in a database. It may take several seconds to render a large hoard document into HTML, but I think the advantages of this framework far outweigh the disadvantages.
In addition to rather simple output of descriptive metadata is a feature for quantitative analysis. This feature is very powerful, though rudimentary, having been developed in only two work days. It will grow in its sophistication over time.
Like coin-types, there is a quantitative analysis tab on the web page for a hoard record. The user can select from a handful of typological attributes to generate bar graphs. We are using
highcharts for this instead of
jQuery visualize, like other visualizations in Numishare. I have found it to be far more versatile, and we will eventually replace jQuery visualize with highcharts everywhere in Numishare.
Highcharts is capable of other chart and graph formats, different colors, and outputting a printable chart. I have only begun to explore these options.
The next major task to pursue is to output findspot points to the map on the hoard record HTML page.
