I have been working on and off for the last month or two on a new quantitative analysis feature in Nomisma, which is available on pages for certain types of Concepts (that are associated with coin types that have been ingested into Nomisma) as well as on a new page, http://nomisma.org/research/metrical.
Much like the distribution analysis interface, the user can select multiple dataset groupings to compare for average weight or average diameter. Optionally, and like the existing features in OCRE, CRRO, and PELLA, the user can input a start date and end date and an interval of 5 or 10 years in order to visualize the change in average weights over time. The parameters established in the web form are used to query a web service, which interacts with Nomisma's SPARQL endpoint and serializes the response into JSON for visualization.
What separates this interface from the feature that is built into Numishare projects (like OCRE) is that the weights are drawn from all relevant coins, regardless of an explicit connection to a coin type defined by a URI published by OCRE or similar project. This means that coins from Antike Fundmuenzen Europa or other finds databases that do not have positively identifiable RIC numbers can be queried alongside those that do, as long as those relatively uncertain coins still have some certain attributes, such as authority or denomination. Moreover, these interfaces allow the querying across related, but separate datasets--e.g., to evaluate the change in average weight of denarii from 100 B.C. to A.D. 100, even though the denarius coin types are split between OCRE and CRRO starting about 27 B.C.
The raw data can be downloaded as CSV for further analysis, visualization, or publication, and the chart for the metrical analysis page can be reproduced easily by bookmarking the resulting URL.
First, we do encounter coins that are either cataloged with the wrong RIC number or the automated matching script erroneously interprets a reference into the wrong RIC number, so the weights of these coins may have an effect on the overall average for a query. I think, in most cases, the margin of error is quite small.
The charts are visualized with a d3.js plugin called d3plus. There's an error in the handling of BC dates (according to the ISO spec), and so (in interval queries), the dates are converted to an integer value. So -100 is 100 B.C. and 200 is A.D. 200. As a result, the d3plus line graph cannot be set as a timeline, and therefore date ranges that do not contain weight data are removed from the chart. It is important to be able to visualize gaps in weights, as these gaps may illustrate periods where coin types conforming to a query were not issued (for example, there is no weight data for aurei from 70-50 B.C.).
One last thing to note is that I have not been able to manually override the x-axis labels, so -100 actually means 100 B.C. to 96 B.C. when the interval is set to five years (not just 100 B.C.). The human readable date range is still available when hovering the mouse over a point in the chart and in the CSV download.
Much like the distribution analysis interface, the user can select multiple dataset groupings to compare for average weight or average diameter. Optionally, and like the existing features in OCRE, CRRO, and PELLA, the user can input a start date and end date and an interval of 5 or 10 years in order to visualize the change in average weights over time. The parameters established in the web form are used to query a web service, which interacts with Nomisma's SPARQL endpoint and serializes the response into JSON for visualization.
Average weight of denarius (red), aureus (yellow), and antoninianus (blue) from 100 BC to AD 300. See for yourself. |
What separates this interface from the feature that is built into Numishare projects (like OCRE) is that the weights are drawn from all relevant coins, regardless of an explicit connection to a coin type defined by a URI published by OCRE or similar project. This means that coins from Antike Fundmuenzen Europa or other finds databases that do not have positively identifiable RIC numbers can be queried alongside those that do, as long as those relatively uncertain coins still have some certain attributes, such as authority or denomination. Moreover, these interfaces allow the querying across related, but separate datasets--e.g., to evaluate the change in average weight of denarii from 100 B.C. to A.D. 100, even though the denarius coin types are split between OCRE and CRRO starting about 27 B.C.
The raw data can be downloaded as CSV for further analysis, visualization, or publication, and the chart for the metrical analysis page can be reproduced easily by bookmarking the resulting URL.
Weight of Augustan denarii from Rome compared to Lugdunum |
Known Limitations
The metrical analysis feature is still a working proof of concept that will be refined and enhanced over time.First, we do encounter coins that are either cataloged with the wrong RIC number or the automated matching script erroneously interprets a reference into the wrong RIC number, so the weights of these coins may have an effect on the overall average for a query. I think, in most cases, the margin of error is quite small.
The charts are visualized with a d3.js plugin called d3plus. There's an error in the handling of BC dates (according to the ISO spec), and so (in interval queries), the dates are converted to an integer value. So -100 is 100 B.C. and 200 is A.D. 200. As a result, the d3plus line graph cannot be set as a timeline, and therefore date ranges that do not contain weight data are removed from the chart. It is important to be able to visualize gaps in weights, as these gaps may illustrate periods where coin types conforming to a query were not issued (for example, there is no weight data for aurei from 70-50 B.C.).
One last thing to note is that I have not been able to manually override the x-axis labels, so -100 actually means 100 B.C. to 96 B.C. when the interval is set to five years (not just 100 B.C.). The human readable date range is still available when hovering the mouse over a point in the chart and in the CSV download.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.