Numista numbers

[FosseWay]

Not sure if this is the right place for this...

I've recently noticed that Numista has started adding "N#" numbers to all its catalogued coins, banknotes and tokens. According to the Numista thread discussing this innovation, this happened in May, so I've evidently been living under a stone since then, having only noticed very recently 

Anyway, it's a big thumbs-up from me, both in terms of the mere fact of its existence and in terms of the way it has been implemented (a simple serial number based on the order in which the items were added to the database, with no attempt to encode information about them).

I think all catalogues should have some form of numbering system. Some do not have this - you have to refer to, say, the page on which the item occurs, or for a website, give a URL. It doesn't matter how incomplete your catalogue is, or how comprehensive other catalogues are: you need some way of pointing to a given coin in *your* system. With a project the size and scope of Numista, there are always going to be objects that have never previously been described, and you need to be able to refer to these, but you also need some form of internal reference over and above the large number of specific references to individual catalogues.

And, as I say, I think the simple serial number approach is absolutely the best way to go, especially given that Numista is an online resource, not a printed product with all the entries in a given order that, once printed, is set in stone. Other catalogues stumble when they consider this issue. Some desire so much to keep to a given order that they regularly renumber entries - the Menzel catalogue of German-language tokens is a prime example, where the issuers are listed in alphabetical order and you have to cite the edition year as well as catalogue number for the reference to make any sense.

Others devise a complicated scheme of codes for country, issue, denomination or whatever. They are successful to varying degrees in leaving enough room for development, and this is easier when cataloguing an established series (such as Coincraft's numbering of UK/predecessor coins), but they all fall down eventually in that the code becomes very complicated and is not immediately decipherable without referring to a list of abbreviations. Inevitably the codes become long, with elements separated by dashes and slashes. Even when Numista ticks over to its millionth entry, the number will still just be 7 digits.

Others do something in between: KM, Pick, Seaby/Spink for UK coins all do this. In principle, KM numbers rise by the date of the coin. Spink numbers rise by denomination within a series, where the series is defined by something that boils down to date (e.g. monarch's reign). These numbers may help to place your coin in time, but only if you have an idea in advance of the possible range of numbers for the catalogue or country you're looking at. I'm familiar with Spink so I know that a number in the 39xx range is going to be Victorian copper, but without that knowledge, it's basically just a serial number. The KM numbering for UK coins reached 4 figures well into the decimal (post-1971) era, whereas for Austria it was already well into the 2000s when the coinage reform of 1892 took place. Again, without knowing those quirks, the number confers no extra information than simply being a unique identifier for a particular issue. And in both cases, extra issues have had to be added from time to time as varieties are discovered, leading to ugly numbers with suffix letters (Spink) or numbers that are out of order (KM) or both, or periodic renumberings (both catalogues).

Reading the thread I linked to above, there seems to have been discussion along similar lines among the coordinators at Numista. I'm very happy that the pure serial number approach carried the day 

[Figleaf]

I have sympathy for your approach, but I also see a major disadvantage. Like it or not, one of the major functions of coin catalogues is a checklist of what is and what is not in your collection. This is clearest in the Yeoman and Craig catalogues, ordered by series and types. That sort of listing gives immediate insight if your interest should go beyond being "complete".

US coins being largely impossible to arrange in series, KM chose to apply the US method of listing by denomination. Insight went overboard. Befuddled with their own approach, KM started listing countries by period, except when they didn't. This way, they achieved the worst of two worlds: no insight AND impossible to retrieve easily.

All that is passed and ancient history. Catalogues are online now. A search engine is enough to locate any type available with lightning speed. Or not. Zeno gives a unique number to each data base entry. Fine for DB managers, but hell for the uninitiated. Its overall classification structure is so detailed you have to know the answer before you can ask the question. Its search engine works fine, but is highly sensitive to spelling issues. Muhammed? Mohammed? Muhammad? Mahmud? Mahmut? All different guys as far as Zeno is concerned and that's before you consider other languages than English.

To get an insightful listing, you must make it yourself. To do that, you need a key to sort. That used to be the catalogue number. If you make the catalogue number a function of a non-relevant datum, time of entry in the data base, it can't be used for sorting.

My solution is typically civil servant. Do both. Assign a catalogue number that can serve as a point of reference for data base geeks, dealers, traders and the "complete" crowd and a vector-based number that serves as a sort key.

Peter

[FosseWay]

I don't really understand why you need to sort, though.

I have one Excel sheet per country/territory/entity I have coins or tokens from. Within these, I simply list the items I possess in a logical order. I tend to divide countries into segments depending on things like becoming independent, revaluing their currency, changing from £sd to decimal, joining the euro or whatever, and then within those, I list them in denomination and then date order. I can't really conceive of any reason why I'd want to sort them in any other way.

On the other hand, I do need a 1:1 correspondence between a coin in a holder, an entry in the Excel list, and a scanned image. If each carries the same information, job done. And, for my brain at least, the easiest way of creating such a unique reference, simply using normal arabic numbers in base 10 seems the obvious solution.

It's also important to distinguish between "sorting" and "searching". In a printed book, you have to sort your entries logically in order to allow your readers to search effectively. In an Excel document or an online catalogue like Numista, you don't need to do this. The information can be stored any which way, providing your search function is fit for purpose. In the context of Numista, you can generally get where you want to get by choosing country and then entering denomination and date in plain text. No codes or numbers required.

Finally, Numista is quite good for providing references to specialist local catalogues. But if I don't have a copy of the particular catalogue specified, it doesn't really matter how much information is encoded in that reference - it's just letters and numbers to me. The value lies in having a reference at all - just a 1:1 link between a coin and its entry.

[Globetrotter]

Numista has its own number, but can have up to 10 other reference numbers, so you can search according to your preferred catalog, so you don't have to use the numista#, if you don't like it. Personally, I don't use it, since it's just a sequential number, not meaning anything.

[FosseWay]

Yes - I generally search in Numista using the KM number for coins, because that's what I've got in my records and in my experience, I'm more likely to find what I want that way. Sometimes I find I get zero hits searching on a denomination name because it's spelled differently in Numista from how I spell it. 

But KM numbers are just a number as well, and moreover non-unique ones. All KM entities have a #1, for example. I stand by my earlier comment that the most important thing is to link one coin type to one number and not to try to encode a mass of other information in the identifier - you get all that other information by clicking on the link. But each to their own

[andyg]

The KM numbers on Numista seem rather up to date (2023 in some cases) - just wondering if anyone knew how this is possible?

[Globetrotter]

numismaster.com is still active!

[bgriff99]

Zeno gives a unique number to each data base entry. Fine for DB managers, but hell for the uninitiated. Its overall classification structure is so detailed you have to know the answer before you can ask the question. Its search engine works fine, but is highly sensitive to spelling issues. Muhammed? Mohammed? Muhammad? Mahmud? Mahmut? All different guys as far as Zeno is concerned and that's before you consider other languages than English.

To get an insightful listing, you must make it yourself. To do that, you need a key to sort. That used to be the catalogue number. If you make the catalogue number a function of a non-relevant datum, time of entry in the data base, it can't be used for sorting.

My solution is typically civil servant. Do both. Assign a catalogue number that can serve as a point of reference for data base geeks, dealers, traders and the "complete" crowd and a vector-based number that serves as a sort key.

Peter

Zeno is at this point for specialists. So long as its organization IS comprehensive, having to look long and hard for things has a collateral benefit of educating.  I had multiple paper catalogs for a long time, in Japanese, which eventually became my specialty areas.   All that looking at what I didn't understand, and had few examples of, paid off.  Zeno has well-organized and clear areas where NO other catalog has anything making sense.  The trick is finding them.  We do expansions slowly and deliberately, anticipating where categories will eventually become large.  I fill out new categories from my own collection, if necessary, to anchor them. But I am not a moderator. 

[Globetrotter]

Numista unfortunately started out using NON-EXISTING km#, since they would say a km300, would be enough to cover the km300.1 301.a1 301.2 301.3 etc. So if you have the proper km# in your collection file (not numista) yo might not find it in numista, since it only knows the umbrella#. That's one of the reasons why we have convinced Xavier to allow up to 10 Reference numbers per type now.

A lot of coin types still only have the NON-EXISTING umbrella#!