Hello,
I have my own data base and a like import the coins to numista.
In numista have one option to import the information i give in a file?
In my data base i have more than 3000 coins information.
This would be useful, however, it's very hard to accomplish technically. If the coins in your file are described differently than here in Numista, it would not be possible to identify them. For example, "United States 5 cents KM# 192 2000 D" is the same as "USA 5 cents 2000 D KM# A192"; this is obvious for a human, but not for a computer program.
Hi,
I all is possible, but that type of coins are a small percent of the total i will put / introduce, but if the import have the KM cod is half way of the objective.
Hello,
It would be quite complex to build an import tool, with no chance to have it 100% reliable.
Therefore there are no plans to add the possibility to import from a file.
Citeer: "Xavier"Hello,
It would be quite complex to build an import tool, with no chance to have it 100% reliable.
Therefore there are no plans to add the possibility to import from a file.
An import function would be very simple to implement as the record keys are externally known and the field values transparent.
The following import data:
US;310;2000;D;1;0;VF
would create a collection entry for:
one United States 2000-D $1 "Sacagawea Dollar" of condition VF, not for swap
Without data import, Numista severely narrows its target audience. An unforced error IMHO. Collectors already cataloguing their coins electronically won't be too motivated to have to manually create data copies and ensure that both data holdings remain manually synchronized.
Citeer: "bigger"
The following import data:
US;310;2000;D;1;0;VF
would create a collection entry for:
one United States 2000-D $1 "Sacagawea Dollar" of condition VF, not for swap
What does 310 mean in your example?
And what about different coins that have exactly the same mintage year, mintmark, denomination and country name?
Citeer: "bigger"
The following import data:
US;310;2000;D;1;0;VF
would create a collection entry for:
one United States 2000-D $1 "Sacagawea Dollar" of condition VF, not for swap
What does 310 mean in your example?
And what about different coins that have exactly the same mintage year, mintmark, denomination and country name?
Country (ISO 3166-1 alpha-2) = US
Krause and Mishler number = 310
Mintage year = 2000
Mint mark = D
Quantity = 1
For exchange = 0 (no)
Grade = VF
You may, however, want to account for the various catalogue reference systems and add an additional parameter to the import definition:
Reference system = K (for Krause and Mishler) or S (for Schön) or Y (for Yeoman) or C (for Kann), and so on
If Numista has a standard Excel table to import (or XML, or CSV...) with preset labels, much is possible. Though it would probably require to add link or coin page number for a better import result. It also might be OK to add some kind of a manual check of imported coins with confirmation step, so that the import doesn't go directly to the users coin list.
LP
Citeer: "mikimaus"If Numista has a standard Excel table to import (or XML, or CSV...) with preset labels, much is possible. Though it would probably require to add link or coin page number for a better import result. It also might be OK to add some kind of a manual check of imported coins with confirmation step, so that the import doesn't go directly to the users coin list.
LP
I would not go with the binary Microsoft Excel XLS Format or the Microsoft-developed Open Office XML Format but with a CSV, which is more ubiquitous in cross-plattform data exchange applications.
A data check respectively data pre-hold would probably require additions to the data model. It is also unnecessary as the imported data can be labelled as such (within an existing field) for post-import verification by the user.
What is required, however, is an output file of the records which, for some reason or the other, couldn't be recognized. I would implement strict data compliance for all data fields. The import routine would take a CSV, parse the data and create an output CSV file of the non-parsed records.
We are not talking here about a Nomisma-sized data schemata but, as Numista only tracks a handful of attributes for coin collection records, an import schemata (in addition to the export schemata) which is easily manageable in a volunteer environment.
Interesting ... But it could be very difficult when it comes to some particular coins. Take the Australian 1 cent coin for instance.
It is currently going through a process where three different Numista pages are being combined. It is not complete yet but when it is, there will be 11 different possible lines just for the 1966 coin as follows.
Canberra Mint; No blunted whiskers
Melbourne Mint; Blunted whisker on right
Melbourne Mint; Blunted whisker on right
Proof Open Year Set
Proof Sealed Year Set
UNC Carded Year Set
UNC Two Coin Green Carded Set
UNC Year Set Blue wallet
UNC Year Set; Operation Fastbuck wallet
UNC Year Set; Reserve Bank Coloured Wallets
UNC Year Set; VIP Presentation Wallet
Then there are 7 different variations on each line for Grade - G,VG, F,VF,XF,AU,UNC
Plus whether the coin is for swap or not.
So we are up to 154 different entry possibilities just for 1 year (1966), for 1 coin
Then we could have different quantities for each grade.
This is why this will be extremely difficult to implement. Some coins will be easier to deal with than this one but there are many in this type of category. I believe it could be done but Data Migration is something that needs lots of testing, re-testing and modification as it is tested.
Also when a Data Migration program is finalised it usually can not be used more than once because nothing stays the same. Changes are always being made to existing historical items and new items are being introduced. So as time goes by the Data Migration program needs to be maintained to cater for changes.
Numista is not a massive company with hordes of Technical Designers and a massive budget for testing. It is a great website for users to record their coins, swap if they want to, chat about and discuss coins.
There is no easy solution to this. I have worked with Data Migrations myself when New HR/Payroll Systems were implemented into a large company. They were "one off" conversions from Legacy Systems to a New System and even with lots of technical and business attention to the problems, many issues arise.
Regards Mike
Master Referee - See my profile for what I collect.
I see but no problem. The data superstructure is apparently more generic in that external catalogue numbers (e.g. KM) would be able to sort a collection item into the correct data space. However, the party delivering the data would always be responsible to match the Numista data model and table structure.
Can the admins please supply the table structure so that the discussion can be more specific?
In its absence, I'm deducing the general table structure from the dialog windows as follows
"Coin", e.g. 1 Cent "Lincoln Memorial Cent"
==> "Mintage", e.g. 1960-D small date, low 9, 1972 double die observe or 1980-S Proof
======> "Item", e.g. 1xVF of a 1972 double die observe
The "Mintage" table is apparently a catch-all for all differentiation such as mintage years, mints, die varieties, minting errors, minting processes (proofs, reverse proofs, ...), product types (within x wallet, part of y product set, ...) and so on.
Certain fields, which are deemed critical to properly identify the Numista base data records, must include data in the import data set. Let's name them "designated match fields" and define them as follows:
For the "Coin" table: Name of the coin
For the "Mintage" table: Year, Mint letter, Comment (either in English or French)
For the "Item" table: Grade, Quantity, For exchange
The collector delivers the following import data record for a collection item:
Name of the coin = 1 Cent "Lincoln Memorial Cent"
Year = 1960
Mint letter = D
Comment = small date, low "9"
Grade = VG
Quantify = 1
For exchange = no
The import procedure would match the import data record with the Numista base data records via the "designated match fields".
The collector delivers next the following import data record for a collection item:
Name of the coin = 1 Cent "Lincoln Memorial Cent"
Year = 1960
Mint letter = D
Comment = small date, low "9"
Grade = AU
Buying value: 5000
Private comment: Purchased from Donald J. Trump
Quantify = 1
For exchange = no
Again, a Numista collection item is successfully created.
Next, the collector delivers the following import data record for a collection item:
Name of the coin = 1 Cent "Lincoln Memorial Cent"
Year = 1960
Mint letter = D
Comment = small date, high "9"
Grade = F
Quantify = 1
For exchange = no
The data record will not be imported as it cannot be matched to existing Numista base data records.
Hello,
I confirm that the model is 3-fold, as you assumed, with a "coin", a "mintage" and an "item".
The critical aspect of an import tool would be to define the matching criteria.
For the "coin", the name would definitely not be enough, since many coins have the same title. The easiest and most accurate would be the coin ID (the number you can see on the URL of the page describing the coin type), but this is not very practical. A combination of issuer + reference number could work in most cases, but some coins don't have a reference number and the Numista catalogue is not following exactly any reference catalogue: a same KM number can cover multiple coins on Numista, or multiple KM numbers can be grouped into a single coin on Numista, not even mentioning sub-numbers.
For the "mintage", year + mint letter + comment would work in most cases, although there is no guarantee it can uniquely identify a mintage. Providing the exact comment is not very practical though, as the comments may change over the time and the user would need to check the comment on Numista for each coin in the import file. An alternative would be to use the unique ID of the mintage (which is not displayed in the current version of Numista), but not very convenient either.
The following standing data is not unique? There can be another such entry combination by for a different coin?
Coin.Name of the coin = 1 Cent "Lincoln Memorial Cent" Mintage.Year = 1960 Mintage.Mint letter = D Mintage.Comment = small date, low "9"
Whatever it is, as you note, the Mintage.Comment breaks any achievable robustness as its content does not behave in any predictable way.
I thought we might avoid having to handle primary and second keys but apparent not. Here the revised proposal with them.
As the standing data in the tables Coin and Mintage are managed by administrators, we can leave them essentially aside. What really matters is where to attach a Item record, where each user has free reign.
The foreign key of the Item table is the primary key of the Mintage table. You expose the primary keys of the Mintage table in the user interface.
The user now has two options to sync his data:
Option 1: Look up the Mintage.Primary keys, enter them in his database and generate the following export for Numista import (example with two collection items):
Item.Foreign key = 497853 Item.User reference = USKM2011960DV1AU Item.Grade = AU Item.Quantify = 1 Item.For exchange = no
From then on, data can be kept with exports and imports completely synchronized. Whether a new Item record is solely recognized by a not yet existing Item.User reference or by a combination of Item fields is a side consideration.
The user reference is not important to Numista but only to the user's database. It can be anything:
At the very minimum, since Numista has Export feature - I would really like a way to do 'Import back' in its own format.
I do need to make a very big overhaul of how my coins are listed.
That's because when I started the collection, I was entering coin amounts in a (seemingly) wrong way. For example, if I had three identical coins, of which I was going to exchange two - I entered "3 VF, 2 For Exchange". Now when I do change one of those, I have to edit 2 fields instead of one.
I would really like to fix it, but there's no way I can do it manually...
The ideal would be to have a universal transfection format as there is in genealogy with the format 'gedcom'
The difficulty is to have a unique referencing code that would replace the KM# Y# C# RIC SEAR GCV .... To recite nobody else but them.
Citeer: "Cavaler"At the very minimum, since Numista has Export feature - I would really like a way to do 'Import back' in its own format.
I second this! It sounds a relatively simple thing to implement, unless not all information is conveyed in the export file (sorry I did not fully get the discussion about the setbacks of this approach).
In particular, I would be fine with a way to merge accounts, I have two accounts because I didn't realise "Collections" is a thing...
Citeer: "brismike"So how would all the coins that don't have a KM# etc be handled? There are Australian coins that don't have one from 2014.
Mike
If somebody can import 90% of the coins to Numista, it would be not so difficult to add other 10% manually (having an excel sheet with the coins not added)
My personal list of scammers from Numista: erniemix, yvain, CassTaylor
Citeer: "Rolf"
In particular, I would be fine with a way to merge accounts, I have two accounts because I didn't realise "Collections" is a thing...
You can message Xavier about the merge, he can do it for you.
There is now a couple of SDK using the newly created Add/Change/Delete API endpoints. While it would require you to have experience using Python or JavaScript, this could be an option.
