Hi. I spent several days preparing complete and detailed list of Discogs master ID (P1954) IDs for mix-n-match. I ended up with a file consisting of 2,042,316 elements and weighing 240mb. Only after that I found out that MnM has a limit of 1000 elements at a time :) . Is there any way around this limitation, or could you please help me with the upload?
User talk:Magnus Manske
Zdravím,
všiml jsem si, že pomocí bota importujete/(impotroval jste) do Wikidat jednotlivé národní názvy z položky Vernacular names na Wikispecies do položky (P1843). Tento počin je bezvadný, ale vzhledem k pravidlům a doporučením projektu Wikispecies vede k pravopisně chybnému pojmenování taxonů v některých jazycích. V mnoha jazycích jsou názvy taxonů pravopisně správně s malým písmenem na začátku názvu. Mohl bych poprosit o hromadnou opravu názvů taxonů v češtině? Všechny začínají malým písmenem.
QuickStatements können zurzeit nicht im Hintergrund ausgeführt werden, die Batches zeigen an, dass sie laufen (https://quickstatements.toolforge.org/#/batches), aber seit diesem Batch hier: https://quickstatements.toolforge.org/#/batch/85346 läuft nichts mehr.
Hallo. Das von dir vor längerer Zeit als Maintainer erstellte Skript unter https://geohack.toolforge.org/skyhack.php funktioniert nicht richtig, weshalb die Astronomielinks nicht funktionieren, Genaueres steht in der dt. Wikipedia auf https://de.wikipedia.org/wiki/Wikipedia:WikiProjekt_Vorlagen/Werkstatt#Skript_skyhack.php. Wäre sehr wichtig, wenn du hilfst. Gruß von Antonsusi
Hello @Magnus Manske, @Epìdosis, @Gerwoman and others, even if I have catalog editor rights, I cannot add P10700 to catalog 5115. To be precise, I can access Catalog Editor, add 10700 in Property field, click on Save but property is not saved. Do you know how to fix that? Thanks.
I did it without problem. Perhaps a transient error.
@Gerwoman Thanks!
https://mix-n-match.toolforge.org/#/catalog/3802 says "no Wikidata Prop" but there is such a prop: Grove Music Online ID (P8591). There are 20k matches just waiting for the prop, which can then be synced to WD.
cc @Gerwoman:
It seems that the format of the IDs is not coherent with the one used by Grove Music Online ID (P8591); e.g. https://mix-n-match.toolforge.org/#/entry/128896281 has in the main position 1002087146 (not coherent), while the coherent A2087146 is in auxiliary data. It would be necessary uploading a new catalog with the coherent IDs in the main position.
@Epìdosis:
How can we tell coherent from not coherent?
- The GMO site is despairingly slow and sometimes times out
- The regex is pretty permissive:
[AJLO]?\d{5,7} - There are some complicated mapping rules:
It seems to me both of your examples 1002087146, A2087146 would map to the same thing 1002087146
Surely 1002087146 and A2087146 both map the same thing, but only A2087146 fits the current formatter URL of the property.
I think that we can tell coherent from not coherent through the formatter URL https://doi.org/10.1093/gmo/9781561592630.article.$1:
- https://doi.org/10.1093/gmo/9781561592630.article.A2087146 works, so is coherent
- https://doi.org/10.1093/gmo/9781561592630.article.1002087146 doesn't work, so is not coherent
The regex effectively allows A2087146 but not 1002087146.
Effectively I think that:
- coherent IDs are based on https://doi.org/10.1093/gmo/9781561592630.article.$1 (e.g. https://doi.org/10.1093/gmo/9781561592630.article.A2087146) and have regex [AJLO]?\d{5,7}
- not coherent IDs are based on https://www.oxfordmusiconline.com/grovemusic/view/10.1093/gmo/9781561592630.001.0001/omo-9781561592630-e-$1 (e.g. https://www.oxfordmusiconline.com/grovemusic/view/10.1093/gmo/9781561592630.001.0001/omo-9781561592630-e-1002087146) and probably have regex \d{10}
I think there are some mappings: A->100, J->2000, L->400, O->5000 this would be easy to convert.
But in addition there are 2 different dois:
https://doi.org/10.1093/gmo/9781561592630.article (Grove Music Online)
https://doi.org/10.1093/omo/9781561592630.013 (Oxford Music Online)
What do you suggest?
I would suggest https://doi.org/10.1093/gmo/9781561592630.article (Grove Music Online).
I mean some entries are only valid with the second doi: https://doi.org/10.1093/omo/9781561592630.013.90000317764 or https://doi.org/10.1093/omo/9781561592630.013.60000200727 or https://doi.org/10.1093/omo/9781561592630.013.3000000244
Unpleasant, but I think that unfortunately these ones cannot be linked through the present property Grove Music Online ID (P8591).
Is OMO a superset if GMO? Or are the two partially overlapping?
OMO (https://www.oxfordmusiconline.com/) seems to be a superset of GMO (https://www.oxfordmusiconline.com/grovemusic/).
I've created a new catalog with doi as id. Please check if it's correct to synchronize with WD.
Looks good to me, though the OMO GMO site is again too slow/times out. Eg https://doi.org/10.1093/gmo/9781561592630.article.O907831
Looks good to me too; I think we can sync 5173 and delete 3802.
I recovered all the good matches made in 3802 through https://quickstatements.toolforge.org/#/batch/82912 and I deactivated 3802, while Gerwoman has synced 5173. I think we solved it!
I'm not aware of where one might collect all EIN, but I post processed the US IRS Exempt Organizations Business Master File Extract which could provide a catalog of a subset of the IRS Employer Identification Number (P1297) which would be current and past tax exempt organizations in the USA.
Uncompressed the csv is 372.1 MB and compressed 56.0 MB which neither uploaded through the web interface. id is the Property ID for P1297
File format of the csv for comment.
id,name,description,url,P6733
000019818,PALMER SECOND BAPTIST CHURCH - 3514,"A tax exempt Association registered in PALMER, Massachusetts - NTEE type record was empty: ",https://apps.irs.gov/app/eos/allSearch,
000029215,ST GEORGE CATHEDRAL,"A tax exempt Corporation registered in SOUTH BOSTON, Massachusetts - NTEE type record was empty: ",https://apps.irs.gov/app/eos/allSearch,
000587764,IGLESIA BETHESDA INC,"A tax exempt Corporation registered in LOWELL, Massachusetts with NTEE primary exempt activity type: Protestant",https://apps.irs.gov/app/eos/allSearch,X21
000635913,MINISTERIO APOSTOLICO JESUCRISTO ES EL SENOR INC,"A tax exempt Corporation registered in LAWRENCE, Massachusetts with NTEE primary exempt activity type: Protestant",https://apps.irs.gov/app/eos/allSearch,X21
000765634,MERCY CHAPEL INTERNATIONAL,"A tax exempt Corporation registered in MATTAPAN, Massachusetts with NTEE primary exempt activity type: Christian",https://apps.irs.gov/app/eos/allSearch,X20
000841363,AGAPE HOUSE OF PRAYER,"A tax exempt Corporation registered in MATTAPAN, Massachusetts with NTEE primary exempt activity type: Christian",https://apps.irs.gov/app/eos/allSearch,X20
000852649,BETHANY PRESBYTERIAN CHURCH,"A tax exempt Corporation registered in BROOKLINE, Massachusetts with NTEE primary exempt activity type: Christian",https://apps.irs.gov/app/eos/allSearch,X20
001028397,UNITY IN THE CITY,"A tax exempt Association registered in BROOKLINE, Massachusetts - NTEE type record was empty: ",https://apps.irs.gov/app/eos/allSearch,
001347537,RESTORATION OF HOPE CHURCH MINISTRIES,"A tax exempt Corporation registered in ROXBURY, Massachusetts with NTEE primary exempt activity type: Christian",https://apps.irs.gov/app/eos/allSearch,X20
~~~~
Please use OpenRefine to match these to US organizations. The first few records are churches and include "city, state", which should help with matching
@Vladimir Alexiev Are you suggesting OpenRefine just match on the EIN then use Quickstatements to import the rest? I'm not sure what the intersection of US organizations have an associated EIN and collaborative entity resolution of Mix'n'match would avoid importing a significant number of duplicates.
@Wolfgang8741: I'm suggesting using OR to match these churches to existing WD items by name. BEfore that matching the State and City, and using these fields while matching the main field (name).
This catalog as imported does not have a good chance for "collaborative entity resolution" because City and State are not split out as separate fields, and because MnM cannot do subsidiary reconciliation steps like OR can.
In reasonator a couple of things are not translating and staying in English, the date names and the description of the links in the external link box
The discussion on P2190 suggests moving to numeric format for C-Span Person IDs from the string format, currently this uses the string IDs and will add unwanted strings to Wikidata that are not reliable for links as redirects are not being added, but a query to the URL may return the numeric ID in the response URL if the string still correctly resolves. - Property talk:P2190. The templates have been notified, numeric pairs uploaded to Wikidata, and bot request to root out the string IDs in EN Wiki. I tried to deactivate this catalog to prevent further string inserts, but the save doesn't seem to take effect. ~~~~
A catalog created by Magnus Manske https://mix-n-match.toolforge.org/#/catalog/817 either needs to be retired or the items URLs updated to use the format now used by the Smithsonian's website. All links return 404. Also works have a Linked Open Data URL of the format https://edan.si.edu/saam/id/object/1979.150 which is a different ID than used in the urls that break. Possibly the Property would need discussion too: Current link examples lead to https://americanart.si.edu/artwork/portrait-girl-21713 while the corresponding linked open data focuses on https://edan.si.edu/saam/id/object/1967.6.13 as highlighted https://americanart.si.edu/about/lod