Yes, this was the initial mission statement. Just copy RIC's text record by record and then fill in images where available. When this was being discussed I made an argument that this was a serious error. You're basically baking in an expiration date. As soon as a new revision comes out all the records have to be re-keyed. Errors in print are repeated as are ghost entries that never existed. Meanwhile new variants are ignored. Modeling a virtual site on a paper book is boneheaded in so many ways. My comments, of course, were cheerfully ignored. Rasiel
Correct me if I am wrong, but the purpose of OCRE (and the whole nomisma.org project) is/was not to create a new "reference book", but to unifie large (museum) collections on the basis of a reference book. The RIC references are most probably the only thing that roman imperial coins have in common when described by different people in different languages and, thus, the natural choice.
Yes, I can agree with that. If one had to choose a reference RIC is the most obvious candidate for Roman coins. You're not, however, making the case for why you would implement the paper book system to the online world. Who would go looking in an online database page by page? A book has no choice. It has to list its entries sequentially because there's no other alternative. It is a limitation of the format that OCRE decided to adopt. I could see someone making the case that listing RIC's entries in sequence would be neat to have for whatever reason. Fine, you code the entries in a separate field and then that gives you the ability to sort records found in RIC's numbering. Having that extra field gives you the flexibility to key in other references with their own sorting abilities. But if you make that THE primary sorting order you're essentially painting yourself into a corner. When a new RIC edition comes out the whole scheme becomes instantly obsolete. If nothing else that reason alone makes it a design fail imo. Rasiel
You could certainly add more reference fields and allow sorting by them as well. But, as said before, OCRE is probably not aimed to be a reference website. It's simply a scheme (based on the most frequently used reference books for that time, the RIC), filled with the coins of some large (museum) collections. I am not sure about the goal, but most probably simply to gain deeper quantitative insights. If it was a reference website (like RPC online), I agree that there would be better ways. But any other way would certainly require more resources than it does now and who is gone pay for that?
I think the (valid, in my opinion) point that Rasiel is trying to make is that if someone is going through the trouble to design a site like OCRE, they should go ahead and future-proof it by building in more extensibility. That's why I think that the RPC approach is better; they too collect data from museum collections and merge them with the existing reference work, but it is also extensible and replaces the existing reference work through active curation, revisions, and additions. The last part might cost more, but setting up to allow for that possibility probably wouldn't have cost substantially more.
I am not a Roman guy, nor an OCRE fan. First let me try to do what you did in your Coryssa tutorial, find As of Nero. I click Denomination, As, +, Authority, Nero, Search Note that when I clicked to bring up the list of Authorities, it was filtered to only include those authorities that issued the As. OCRE returns 135 RIC records numbers that match. I click on RIC 533 which takes me to six records under http://numismatics.org/ocre/id/ric.1(2).ner.533 I click on the first record, which takes me to http://numismatics.org/collection/1944.100.39795 . This coin has three references cited: RIC 533, BMC 370, and WNC 591. 1944.100.39795 is the ANS ID for the exact coin. Their IDs have a format: Year donated, ".", donation ID (100; which is Newell's bequest), ".", sequence number in that donation. Internally, there shouldn't be a table with REF1, REF2, REF3 fields, or with RIC, BMC, WNC fields. The data should be relational. If you drink the "semantic web" Kool-aid there will be a relationship, Has-RIC-catalog(1944.100.39795, ric.1(2).ner.533). You could imagine a relatioship Has-ERIC2-catalog(1944.100.39795, ...). Just tell the front end that the initial query is for ERIC2 IDs and nothing else needs to be recoded. In Coryssa, if I understand, the data is broken down by ruler and denomination for Roman Imperial. The ANS' tools don't seem oriented towards a tree of results with tools to drill into it. You can think of the results, in this case RIC numbers, being the leaves of a tree. Your tools seem oriented towards helping the user navigate through the tree, down to the rulers, down to their denominations. This is helpful. The problem is that different users have different opinions for the structure of the tree. Should the top level results be grouped by emperor, or by issuing city?
Damn, your final point is a roundhouse kick to every argument I laid out. Well done. The choice to pick ruler as the trunk of the tree is in the end no more or less arbitrary than any other set of criteria. More popular doesn't make it more correct. I love it when I'm presented with a new angle so compelling that it makes me reassess even deeply held convictions. Thanks, Ed. Rasiel
