User talk:Gymel

Welcome to Wikidata, Gymel!

Wikidata is a free knowledge base that you can edit! It can be read and edited by humans and machines alike and you can go to any item page now and add to this ever-growing database!

Need some help getting started? Here are some pages you can familiarize yourself with:

Introduction – An introduction to the project.
Wikidata tours – Interactive tutorials to show you how Wikidata works.
Community portal – The portal for community members.
User options – including the 'Babel' extension, to set your language preferences.
Contents – The main help page for editing and using the site.
Project chat – Discussions about the project.
Tools – A collection of user-developed tools to allow for easier completion of some tasks.

Please remember to sign your messages on talk pages by typing four tildes (~~~~); this will automatically insert your username and the date.

If you have any questions, don't hesitate to ask on Project chat. If you want to try out editing, you can use the sandbox to try. Once again, welcome, and I hope you quickly feel comfortable here, and become an active editor for Wikidata.

Best regards!

--Ricordi samoa 15:06, 7 April 2013 (UTC)[reply]

Property:P428 (botanist author abbreviation)

Hi,

The above property is now available and can be used on items. I noticed you participated in its discussion. -- Docu at 18:04, 15 April 2013 (UTC)[reply]

Items merge

Hi, thanks for you work: [1], [2]. But you forget nominate empty item to WD:RFD. There is greet tool merge.js, that makes items merge process very simple and prevents many errors. Please see WD:Merge for details. — Ivan A. Krestinin (talk) 18:23, 7 November 2013 (UTC)[reply]

Yep sorry: I'm very sure I clicked on "Request deletion" but something must have gone wrong. -- Gymel (talk) 19:00, 7 November 2013 (UTC)[reply]

Property with comment

I don't know much about Wikidata but it appears from en:Wikipedia:Village pump (technical)#The SELIBR id is not valid that [3] was invalid. It has been reverted. PrimeHunter (talk) 11:22, 30 December 2013 (UTC)[reply]

Thanks for the notice. I commented the slip at en:Wikipedia:Village pump (technical)#The SELIBR id is not valid. -- Gymel (talk) 11:45, 30 December 2013 (UTC)[reply]

Straßenschlüssel

Ich weiß nicht so richtig, wo ich diese Anfrage hier stellen soll (idealerweise auf einer mit de:FZW vergleichbaren Seite). Manche Städte führen ein Straßenkataster, in dem jeder Straße ein Straßenschlüssel zugewiesen ist (Beispiel). Ist diese Eigenschaft schon durch irgendein property abgedeckt, wenn nicht wieder catalog code in Frage kommt? Gruß--Leit (talk) 21:22, 26 January 2014 (UTC)[reply]

Ich bin mir recht sicher, dass es das nicht gibt, auch nicht als Qualifier zu located on street (P669). Ich habe neulich eine Frage in Wikidata:Forum gestellt, das Ergebnis hat mich nicht recht befriedigt, aber einen besseren Ort für solche Diskussionen gibt es m.W. nicht. Apropos "für solche": Da hast Du neben der Denkmallistennummer also noch ein Beispiel für eine "amtliche" Identifikationsnummer auf unterster administrativer Ebene gefunden... -- Gymel (talk) 23:02, 26 January 2014 (UTC)[reply]

Danke. Ja, nach dieser Seite hatte ich gesucht (gibts ja auf Commons unter diesem Namen auch). Ich geh dann mal dort fragen, ansonsten müsste ich mal an mein erstes "property proposal" wagen.--Leit (talk) 23:07, 26 January 2014 (UTC) Nachdem im Forum nichts kam, nun auf Property proposal vorgeschlagen. Ich hoffe sehr, das Formular halbwegs richtig ausgefüllt zu haben.--Leit (talk) 17:20, 29 January 2014 (UTC)[reply]

naturalist

Hi! Have you noticed en:search: naturalist. There are a lot of garbage aliases around here (sometimes at the wrong place) but I think it makes sencse to keep the historical "aliases". naturalist is used both in pipes and in en.Wikipedia article text. Regards לערי ריינהארט (talk) 19:04, 28 April 2014 (UTC)[reply]

Nein: Siehe en:Naturalist (disambiguation). Das Wort steht also (ähnlich wie im Deutschen und im Gegensatz zu den romanischen Sprachen) niemals für Naturwissenschaftler, höchstens teilweie für Naturkundler, Naturforscher, Naturgeschichtler und außerdem für Naturschützer bzw. für Vertreter des de:Naturalismus (Philosophie). -- Gymel (talk) 19:37, 28 April 2014 (UTC)[reply]

Danke! Bitte bei vorhandenen WD-Seiten (Berufe bzw. Personen) hinzufügen. לערי ריינהארט (talk) 12:34, 29 April 2014 (UTC)[reply]

Property proposal for Place of origin

Hi Gymel,

At Wikidata:Property_proposal/Person#Place_of_origin_.28Switzerland.29, I proposed a property for "place of origin". As you contribute in related fields, I thought you might find it interesting. ----- Jura 08:23, 10 May 2014 (UTC)[reply]

TLS

Hi Gymel,

You might be interested in Wikidata:Property_proposal/References#TLS. Despite the wikilook of the site, it's a static reference from a 2005 print work. --- Jura 17:57, 28 May 2014 (UTC)[reply]

consecrator (P1598)

consecrator (P1598) is ready. Tobias1984 (talk) 17:53, 3 November 2014 (UTC)[reply]

BBF ID (P1650)

BBF ID (P1650) ist jetzt bereit. --Tobias1984 (talk) 11:53, 21 December 2014 (UTC)[reply]

Dubletten sammeln?

Hi Thomas, wollen wir wirklich auf Wikidata veraltete Normdaten sammeln? Auf de:Musée des Confluences ist neben der GND (Ex-GKD) bereits die dublette SWD erfasst. Ich denke es reicht, wenn wir solche Fälle auf deWP bearbeiten und würde mir gerne die doppelte Arbeit sparen. Es gibt zwar in Wikidata die Möglichkeit, Angaben als bevorzug zu markieren, aber dieses Wissen an die Vorlagen weiterzureichen, ist kompliziert. Daher zeigt en:Musée des Confluences die veraltete SWD, statt der aktuellen GND an. Fröhliches Schaffen --Kolja21 (talk) 14:07, 25 December 2014 (UTC)[reply]

Hallo @Kolja21:, [a) für http://beacon.findbuch.de/seemore/gnd-aks werte ich sowohl Doppeleinträge in Wikidata als auch in de:WP aus ] b) würde ich das umgekehrte präferieren: Sobald die Einträge in der GND zusammengeführt werden, eliminiert KrBot zeitnah den nun nicht nur inhaltlich sondern auch technisch dubletten P227-Eintrag - da haben wir also nichts mehr mit zu tun; umgekehrt sind die "veralteten" Parameter GKD und SWD im Normdaten-Template der de:WP wirklich welche, die wir zügig abbauen sollten und irgendeine Form der "Wiedervorlage" (oder auch nur einfache Selektion - oder gibt Catscan3 eine gezielte Möglichkeit, Vorhandensein einzelner Parameter abzufragen?) haben wir abgesehen von den Offline-Wartungslisten eher nicht. -- Gymel (talk) 19:22, 25 December 2014 (UTC)[reply]

Hm, bleibt das Problem mit jenen Normdatenvorlagen, die auf Wikidata zugreifen. Zum Glück haben wir diese Sorgen in deWP nicht, aber bei den anderen Sprachversionen ist es unschön, wenn ausgerechnet die veraltete GND angezeigt wird. Grüße --Kolja21 (talk) 21:05, 25 December 2014 (UTC)[reply]

Weil in Wikidata mehrere Nummern eingetragen werden können, verlagert es das Auswahlproblem doch eigentlich aus den Köpfen der Eintragenden heraus auf Wikidata bzw. die Abgreifenden: Das sehe ich als Vorteil. Und ist es nicht ein Kristallkugelproblem: Mit unserem arkanen Wissen (weil die Nummern aus zwei verschiedenen Vorgängerdateien stammen ist es keine beliebige Dublette sondern eine mit quasi eingebauter Zusammenlegungsstrategie) können wir zwar beurteilen, dass in diesem Fall die Ex-GKD-Nummer längerfristig überleben wird, allerdings können wir damit immer noch nicht abschätzen, ob wir die Zusammenführung in dem konkreten Fall noch erleben werden noch bei welcher der beiden Nummern bis dahin "interessanterer" Content anfallen wird. Und was den eigentlichen Normsatz angeht ist die "veraltete" SWD-Version derzeit sogar detaillierter... -- Gymel (talk) 21:37, 25 December 2014 (UTC)[reply]

Es gibt sogenannte Gewinnerdatensätze, insofern wissen wir, dass bei Körperschaften die GKD bevorzugt wird, und was unsere Lebenserwartung angeht, drücke ich uns beiden einfach mal die Daumen ;) Ich habe bei dem Werk Wohl dem, der sich auf seinen Gott, BWV 139 (Q24245) als Datenherkunft SWD bzw. DMA eingetragen, damit man sich auf die Dubletten einen Reim machen kann. Ist das ok? --Kolja21 (talk) 10:27, 26 December 2014 (UTC)[reply]

Die Bachkantaten scheinen unsere neue Baustelle zu sein: Ich sehe in der GND einerseits Ansetzungen für die einzelnen Arien (typischerweise scheint die jeweils erste Arie die Namensstifterin für die Kantate zu sein ...) sowie einen Satz mit 3er-Nummer als "Umsetzung RAK-Musik vor 2003" und einen Satz mit SWD-typischer Nummer als "Umsetzung RAK-Musik nach 2003": Da hat man also in Berlin oder Leipzig 2003 oder 2009 (als die DMA-EST-Datei nach aussen unsichtbar in das ILTIS-System migrierte) oder 2012 (als sie EST's sichtbar und Teil der GND wurden) oder seitdem (als die Offline-Läufe zur Zusammenfassung betrieben wurden) die Hausaufgaben nicht gemacht. Die 4er- oder 7er-Nummern sind also aus mehreren Gründen den 3er-Nummern vorzuziehen (damit sind in der DNB aber viel mehr Werke verknüpft), der parallele Anachronismus "SWD" und "DMA" als Herkunftsangabe drückt das m.E. nicht gut aus sondern verleitet höchstens dazu, in der "GND" nachzusehen wie es "richtig" sein mag... Auch hier denke ich können wir nicht mehr tun als in Wikidata beide einzutragen (meinetwegen mit Vorzugskennung bei der "SWD"-Nummer) und in de:WP die SWD-Nummer als "GND" einzutragen (auch bzw. gerade weil wir umgekehrt beide Nummern eintragen könnten - 3er-Nummer als "GND" und 4/7er-Nummer zusätzlich als "SWD" - aber nicht wirklich wollen). -- Gymel (talk) 11:12, 26 December 2014 (UTC)[reply]

Habe mich schlau gemacht. Für Werke der Musik gilt: "Gewinner-Datensatz ist der des DMA."[4] --Kolja21 (talk) 19:36, 26 December 2014 (UTC)[reply]

Ensemble/Band

Regarding this revert: there's some problem with musical group (Q215380), may be with labelling in different languages. May be the orchestra is not a en:band/de:Band, but imho it is a fr:Groupe musical/ru:Музыкальный ансамбль. I understand that this is not the same as rock band (Q5741069), but then I don't feel the difference from musical ensemble (Q2088357). What do you think? --Infovarius (talk) 12:22, 13 February 2015 (UTC)[reply]

It is extremely complicated and a mess. The only thing we know for sure is

⟨ musical group (Q215380)  

 ⟩ subclass of (P279) ⟨ musical ensemble (Q2088357)  

 ⟩

. Not so clear: is musical ensemble (Q2088357) really meant to be a "small" group in all languages (and all genres: "ensemble" is a common term for performers of Early Music). Some articles seem to indicate that an ensemble constits of soloists only, fr:Ensemble stresses the continuity of collaboration. Several sitelinks are "Bands" or "Groups": es:Banda de musica or sq:Grup muzikor. [:en:Band (music)]] is a redirect to en:Muiscal ensemble (but english knows about brass bands, marching bands and other types of large formations called "band")! As for musical group (Q215380) we see "Formation" (ro), "Group" (oc, fr, it), "ensemble" (ms, an error?), "rock band" (nah, clearly an error?)... German, English, Italian, Portugese (and probably more) alias "Musical Group" with "(Musical) band".

I think, there exists no definition at all for musical group (Q215380) on Wikidata, but speaking for German, there is a strong distinction between "Popular Music" (entertaining music) and "Earnest Music" and it is absolutely a no-go to denote performers of classical music as kind of "band" or "group" (or Kapelle, Combo and other terms not even represented in Wikidata)... In German there is also the technical term "Klangkörper" as the general term (including organs, choirs, orchestras, soloists) for the sum of all sound-producing (my impression: without the conductor, i.e. the conductor controls this Klangkörper). From that background I tend to use the more general musical ensemble (Q2088357) especially for everything connected with Classical music, but also for "Grupo musicales" from countries where I suspect that there is no strong disctinction between "popular", "folklore", or "traditional", "classical" music and other genres. This means reserving musical group (Q215380) to Pop, Rock, Jazz, and the like (side problem: Musical projects of one or several artists). An example: There are many japanese Girl Groups with english names where I boldly assume they perform some kind of western-style pop/rock/whatever and therefore assign musical group (Q215380) but I have no clue about how traditional japanese music can be structured or is viewed upon and therefore I would stick to the general term for performers of those genres. -- Gymel (talk) 13:12, 13 February 2015 (UTC)[reply]

In Russian, ru:Музыкальный ансамбль usually denotes not very big (<12 members) and frequently purely instrumental group of musicians. It is opposed to choir (Q131186) and orchestra (Q42998). --Infovarius (talk) 20:22, 21 February 2015 (UTC)[reply]

ru:Музыкальный ансамбль corresponds to musical group (Q215380) "band" (as unadapted loanword (Q493000) in non-english languages), whereas en:Band (music) redirects to something ("musical ensemble" as main article of en:Category:Musical group) corresponding to musical ensemble (Q2088357), i.e. ru:Музыкальный коллектив. Thus

⟨ musical group (Q215380)  

 ⟩ subclass of (P279) ⟨ musical ensemble (Q2088357)  

 ⟩

seems to be valid also in russian? -- Gymel (talk) 23:41, 21 February 2015 (UTC)[reply]

Yes, I see musical ensemble (Q2088357) as the most general term for group of people performing music (Klangkörper, if you wish) - that's how Russian label means. And accoring to statements it is. --Infovarius (talk) 08:24, 19 May 2015 (UTC)[reply]

Property talk:P106

Hi, I don't want to create an edit war, so I ask you what is wrong on having {{Constraint:Value type|class=person (Q215627)|relation=subclass}} (constraint for both possible relations). I was working on this scheme quite a bit in last days and it makes sense to me (eg. politician (Q82955) subclass of (P279) person (Q215627) and politician (Q82955) instance of (P31) profession (Q28640)). Matěj Suchánek (talk) 13:19, 10 March 2015 (UTC)[reply]

I never looked at this that way: The value type for P106 is constrained to occupation (Q13516667) ("any activity ...") and it never came to my mind that

⟨ occupation (Q13516667)  

 ⟩ subclass of (P279) ⟨ person (Q215627)  

 ⟩

(if a property pertains to all instances of a class it can be stated as a property of that class?) or at least those activities which are values of P106 are a subclass(es) of persons! In turn, since the item type is also restricted to person (Q215627), occupation (P106) is a relation assigning persons to certain classes of persons. This makes sense at the first hand, but I think it is slightly circular: When the item type of some property is constrained to a certain class, then the set of all individuals mapped by this property to a certain value define a subclass of the class (e.g. the existence of the item constraint implies that the set of all

⟨ x ⟩ occupation (P106) ⟨ astronaut (Q11631)  

 ⟩

is a subclass of person (Q215627) or the set of all people with blonde hair color is a subclass of all people). For popular sets we indeed have names, namely astronauts for persons of profession astronaut, or blondes for persons with fair hair color. And not very surprisingly the names do not differ very much.

For the values Y of P106 we have the constraint

⟨ Y ⟩ instance of (P31) ⟨ profession (Q28640)  

 ⟩

i.e. we consider them instances of some concept. Now you are proposing that these instances should be equated with the induced domain subclass of that property discussed in the preceding paragraph and therefore also the subclass relation to person (Q215627) must be satisfied.

With that it will be legitimate to say

⟨ George Washington (Q23)  

 ⟩ instance of (P31) ⟨ politician (Q82955)  

 ⟩

(why not) and it will become complicated to confine the relations between persons and their occupations to P106 (any target item of properties mostly concerning persons may be turned into a subclass of persons thus we are sliding into specific subclasses avoiding specific properties, "is a" or "member of" implies all...). On the other hand I do not see any advantage of that approach, for any property there is a relation between single target values and the subclass of domain values the inverse property "spans" for this value, e.g. "blondes" or "blue-eyeds". Constraining the target to subclasses of the domain class is perhaps a tiny bit more than just constraining the item class: Target items will by that constraint be exclusively reserved for that property (or similar ones), e.g. "authors" must be persons (not corporations or groups of persons or ...).

All this said, this still might be an appropriate thing to do for "human activities" like the targets of P106... Therefore I undid my revert on the property page -- Gymel (talk) 15:33, 10 March 2015 (UTC)[reply]

STOP

I thought this items should be used with Property:P39, so it should all be bind with this generalisation. If not, how do you revert mass edit? Thannks. --Милан Јелисавчић (talk) 15:24, 17 April 2015 (UTC)[reply]

"List of something" is subclass of "set of something" and "list". But since a list may be made of paper and the ambassadors may be of flesh - thus the "subclass" property of inheritance does not extend from items to lists or sets of these items. However I do not see any obvious constraind violation (putting constraints on P279 would be very silly) so if unsure feel free to ask at the chat wether lists of ambassadors can be described as subclasses of ambassador.

See Q15431023 for how I would describe the situation (envoy (Q11051391) the term taken from the de:label, unfortunately I have no clue wether it is sub- or superclass to the ambassador (Q121998) you inserted but I know it is the apropriate term for this item...).

If you use autolist2 you perhaps can re-select your edits (intersected with claim[31:13406463]), and remove -P279:Q121998. Or simply select "claim[31:13406463] and claim[279:121998]". Unfortunately it seems that the "controls" of autolist2 do not allow the setting of qualifiers. One would be able to perform that with the QuickStatements tool, e.g.

 Q15431023 "TAB" P31 "TAB" Q13406463 "TAB" P642 "TAB" Q121998

but for that you need an externally prepared document (can't enter the "TAB" in the browser) and the list of Q-Numbers for the items involved). -- Gymel (talk) 16:15, 17 April 2015 (UTC)[reply]

Linné

Diese „Ergänzung” ergibt für mich keinen Sinn. --Succu (talk) 21:34, 29 April 2015 (UTC)[reply]

Siehe meine Erläuterung eins drunter. Dahingegen übrigens Dein Edit von vor zwei Jahren höchst fragwürdig ;-) -- Gymel (talk) 00:43, 30 April 2015 (UTC)[reply]

Quellen für GND

Hallo Gymel, ich verstehe nicht ganz, was die Quellenangabe für die GND-Nummern bewirken sollen. Die GND-Nummer ist ja selber sowas wie eine Quellenangabe. Auch sowas wie Angabe der Wikipedia, von der die GND-Nummer übernommen wurde (Datenherkunft) ist eigentlich nicht nötig. Help:Belege bringt sogar explizit das Beispiel GND für Angaben, die keine Quellen benötigen, ebenso Objekte, die keine Quellen benötigen--Giftzwerg 88 (talk) 23:02, 29 April 2015 (UTC)[reply]

Quellenangaben für Normdaten sind m.E. zwar leicht anders zu verstehen als "normale", jedoch recht wichtig: Wir finden eigentlich nie eine externe Aussage "Das Wikidata-Item Q ist so und so", sondern immer nur "Person X ist so und so" und die Identifikation von Person X mit Item Q nehmen wir dabei implizit vor (und unterscheiden dabei nicht einmal, ob das anhand der in dem Moment anhand der im Wikidata-Item vorhandenen anderen Properties erfolgt oder aufgrund von Zusatzinformationen aus einem verbundenen Wikipedia-Artikel). "Normdaten-Properties" bestehen dabei aber nur in dieser Identifikation, insofern ist mein Normalfall bei individueller und intellektueller Vergabe ebenfalls, keine Quelle anzugeben.

Nehme ich die Identifikation aber gar nicht selber vor, ist das m.E. schwächer zu bewerten und sollte dokumentiert werden. Insbesondere bei maschineller Übernahme hat sich dafür imported from Wikimedia project (P143) eingebürgert, z.B. wenn Bots aus einer Wikipedia-Sprachversion den Wert importieren: Dann weiss man, woher ein falscher Wert stammt und kann den dann auch dort korrigieren, andernfalls käme er immer wieder. Im vorliegenden Fall habe ich GND-Nummern ergänzt (oder falls bereits vorhanden "bekräftigt"), die aus einem Mapping [5] stammen, das die Historical Commission of the Bavarian Academy of Sciences (Q1419226) zwischen GND und ODNB vorgenommen hat: Da die ODNB als Oxford Dictionary of National Biography ID (P1415) nach Mix'n'Match hier nahezu vollständig nachgewiesen ist, ist das ein "schicker" Weg, GND-Nummern in Wikidata zu ergänzen. Die Methode der Zuordnung kann ich nun zwar nicht als Quellenangabe dokumentieren, aber immerhin den Urheber des Ausgangsmatchings, damit die Qualität zumindest teilweise eingeschätzt werden kann. -- Gymel (talk) 00:21, 30 April 2015 (UTC)[reply]

+1. Dass die Quellenangabe wichtig ist, sieht man im Umgekehrschluss daran, wie viele fehlerhafte Einträge es gibt. Vor allem durch die Übernahme aus VIAF, wo auch nicht individualisierte Datensätze (Tn) enthalten sind und GND-Nummern, die einen Bindestrich enthalten, falsch wiedergegeben werden. --Kolja21 (talk) 00:30, 30 April 2015 (UTC)[reply]

Jean de Saive

Would you like to explain these two edits?

There are some sites (eg [6]) that say the two were different (d. 1611; d. 1624), and some (eg [7], [8], [9], [10]) that have them as the same (d. 1624). Isn't that exactly where said to be the same as (P460) should be used? Jheald (talk) 15:19, 30 April 2015 (UTC)[reply]

Well, first of all I have to admit that I was inititally completely put off the track by the label of de:Jean-Baptiste le Saive der Ältere which actually is about the (date-wise) younger of the two. And since de:WP has articles about both of them thematising the father/son relation, I did not think of duplicates and removed the (unfortunately also unsourced) said-to-be-the-same statements (and also suggested a change of lemma at de:Discussion:Jean-Baptiste le Saive der Ältere).

Then also RDK does not only know about https://rkd.nl/explore/artists/69323 you cited above, but about a second, https://rkd.nl/explore/artists/301737 (1597-1641). Neither VIAF nor Wikidata seem to know about this.

Originally I thought ULAN would be simply conflating two obviously distinct persons (they attribute him "the vieux" but unfortunately have nothing about "le jeune"), but in the light of the second RDK listing it could equally be possible that de:Jean-Baptiste le Saive der Ältere has deeper problems, i.e. is in so many respects the same person as de:Jean le Saive that it should not be considered to be concerned with "le jeune". But that would be the matter of a redundancy cleanup.

I now still think that we are dealing with two persons, no less and also not more, and Jean Baptiste de Saive I (Q985100) definitely represents the elder and Jan Baptiste le Saive II (Q1226250) should represent the younger, even if that means taking de:Jean-Baptiste le Saive der Ältere out of the situation momentarily and transferring additional birth and dead dates from one to the other, providing the younger one with the dates from RDK artists. What do you think? -- Gymel (talk) 16:18, 30 April 2015 (UTC)[reply]

I'm not sure what the best answer is. On a Belgian site I found this [11] printed genealogy page, which shows Jean-Baptiste le Saive (d. 1624; m. Marie Wyaerts 1603), which corresponds with the details given at de:Jean-Baptiste le Saive der Ältere. According to the book page, their fifth child was Jean Le Saive, le jeune, history and animal painter. Le Saive le jeune is presumably the painter to whom fr:Oswald Onghers began his apprenticeship in 1641. So that seems to explain "der Ältere" in the de-wiki title for Jan Baptiste le Saive II (Q1226250) and also the "(I)" in the English wikidata label.

But that leaves the question of when this man was born and who his father was. The old book page gives his father as "N Le Saive, of Namur", and of course RDK above give his date of birth as c. 1540 (or c.1530-1550).

But if that is correct, is it really likely that he married at age between 53 and 73, and lived to age 74 to 94 ?

The dates of 1571-1624 seem a lot more credible; plus fr:Jean le Saive which has the dates 1540-1611 (not 1540-1624) seems reasonably well researched.

So on balance, if it correct that there was a Jean le Saive who was born ca 1540, then I don't belive that it was Jan Baptiste le Saive II (Q1226250), despite what RKD etc say, and it does seem more likely that the man born in ca 1540 was a different Jean, viz Jean Baptiste de Saive I (Q985100).

One would need to investigate more of the sources cited to go further. Without doing that further research, I felt my only option, when I originally found this puzzle doing a mix'n'match search for Jean le Saive, was to leave two separate items Jean Baptiste de Saive I (Q985100) and Jan Baptiste le Saive II (Q1226250) as that was what seemed to me probably the most likely, but to include a said to be the same as (P460) because there are so many sources that do give the whole span of 1540-1624 to one man.

It's possible that the single 1540-1624 span was old scholarship, that has now been reviewed and split between two different people by more recent scholarship, but without further research that can really be no more that my working speculation. So that's why I left the items as I did, but you're right that the said to be the same as (P460) would have been better had given sources for it (and perhaps marked it deprecated?). Jheald (talk) 20:40, 30 April 2015 (UTC)[reply]

I wouldn't think so: Both RDK articles give the following three works for reference:

Wurzbach: Niederländisches Künstler-Lexikon auf Grund archivalischer Forschungen bearbeitet . Vol. 2. Vienna, 1910
Thieme/Becker: Allgemeines Lexikon der bildenden Künstler : von der Antike bis zur Gegenwart. Vol. 29. Leipzig, 1935
Willigen/Meijer: A dictionary of Dutch and Flemish still-life painters working in oils : 1525-1725. Leiden, 2003

Now I finally found Jan Baptist Saive the Younger (Q1668930) which definitely is the younger one from RKD, based on de:Jean-Baptiste le Saive der Jüngere (just with a moderately different birth year, and even older main source than Wurzbach). [12]

His father is referred to as either Jean-Baptiste (I) or Jean (II). He lived from 1571-1624 according to [13]

The grandfather is Jean le Vieux (definitively without Baptiste). Born 1540 perhaps in Saive (Q2454115), he was registered in 1562 in Namour, travelling a lot and died in Namor in 1611. According to [14]: La vie de l'artiste ainsi que son œuvre ont longtemps été confondus avec ceux de son fils Jean II (parfois aussi appelé Jean-Baptiste), notamment par les historiens A. Siret, A. Bequet et E. Neeffs.

Thus actually the two older of the three had been said to be the same but the question remains by whom: Neeffs (1870ies) is blamed by the literature. ULAN combines them, that's for sure. About the sources given at RDKartists I can't tell, just that RDK notes four periods of activity from those the first and the last cannot fit into the lifespans of the two persons in the Dictionnaire des peintres belges. Thus RDKartists is currenctly stating equality, too. I reintroduced your said to be the same as (P460) but I see clearer now what my problem is with that: They don't explicitly state identity, they just don't notice the difference! So I did not state RKDartists and ULAN as "references" for the statement, just the belgian source as disputing that. I'd very much rather like to see a property "confused with" and qualifiers which would state by whom...

Assuming the belgian painters source is reliable, everything should be settled now (actually the three articles at de:WP are mostly a quite close translation of the french text...) -- Gymel (talk) 23:09, 30 April 2015 (UTC)[reply]

Nice work. Thank you. Jheald (talk) 23:41, 30 April 2015 (UTC)[reply]

Historische Kommission als Quelle für GND

Hallo Thomas, was sollen wir mit GNDs machen, die bei der Historischen Kommission bei der Bayerischen Akademie der Wissenschaften falsch eingetragen sind? Beispiel: George Macleay (Q5542036) (1809–1891) ≠ Alexander Macleay (Q2833165), GND 134107675. Einfach löschen oder in einer Liste sammeln? --Kolja21 (talk) 10:00, 1 May 2015 (UTC)[reply]

Es sind etwa 180 unique value constraint violations hinzugekommen, die arbeite ich nun ab: Nach knapp 10 Fällen ist mein Eindruck (dass das nicht besonders fix zu machen ist, und) dass da ein ODNB-Problem existiert: Eigentlich alle Fälle betreffen identische Artikel, die unter zwei Nummern zugänglich sind, manchmal mit abweichendem Lemma, meist aber sogar mit identischem. D.h. Mix'n'match hat wohl gesehen, dass ein Item nicht infrage kommt, da bereits eine OGND-Nummer hinterlegt ist, daher wurde ein neues Item ohne Language Link angelegt, durch die GND-Zuordnung fällt das nun als Dublette auf und kann gemergt werden. Ich erwarte nun, dass durch meine Bearbeitugnen letztendlich die unique-Value-violations bei Oxford Dictionary of National Biography ID (P1415) um etwa 150 ansteigen werden...

Bei abweichendem Lemma ist es u.U. eine Sammelbiographie, da ist mir aber nicht klar, was davon zu halten ist: Es gab etwa Mary Burchell (Q327958), dazu gehören (verschiedene Indexeintraege, identischer Artikel unter beiden Nummern) ODNB Ida Cook und ODNB Louise Cook, ihre Schwester: Die wird im Artikel tatsächlich auch behandelt, es gibt aber nicht einmal ein detailliertes Geburtsdatum. Ich habe dennoch das neu angelegte Louise Cook (Q18762031) von Ida auf Louise umgearbeitet, beide ODNB-Nummern betreffen aber strenggenommen beide Personen. Ein analoger Fall dürften Edward Montagu, 2nd Earl of Manchester (Q2702018) und Robert Montagu, 3rd Earl of Manchester (Q7347752) mit jeweils den ODNB-Nummern 101019009 und 101019032 sein: Robert (3. Earl) kommt im Artikel zu Edward (2. Earl) breit genug vor, um einen Verweis zu rechtfertigen. Die Formatierung im Index (Robert mit Lebensdaten von Edward, analoges oben auch bei Ida und Louise) ist aber nicht so, dass ich nun so weit gehen würde zu behaupten, dass die eine Nummer für Robert und die andere für Edward steht... Evtl. kann @Zeromat: etwas zu ODNB-Dubletten sagen? -- Gymel (talk) 17:11, 1 May 2015 (UTC)[reply]

Doch kann man wohl: Robert 101019032 wird zu einem bestimmten Absatz in der Biographie von Edward aufgelöst. -- Gymel (talk) 17:27, 1 May 2015 (UTC)[reply]

Hier die Auswertung der ersten 10 Fälle:

1 GND-Satz, der evtl. zwei Personen meint (habe ich auf PND/F gemeldet).
1 Dublette in Wikidata (Schrottiges Lemma in de:WP, habe dort verschoben und nachgearbeitet, in Wikdata gemergt)
1 Kryptobiographie in ODNB, Wikdata-Items zu beiden waren bereits vorhanden, konnte einfach bereinigt werden
7 Kryptobiographien in ODNB, Wikidata-Item zu einem war durch Mix'n'Match erzeugt worden, trug dann Lebensdaten zur anderen Person: Vermutlich ist es dann am effektivsten, in Wikidata zu mergen (da dann zu schauen, welche ODNB-Nummer und GND-Nummer zu wem gehören) und dann ein neues Item für die Krypto-Person anzulegen: ODNB-Nummer, Geburtsjahr, Sterbedatum- und Ort, Tätigkeit und familiäre Beziehung lassen sich da immer entnehmen.

Fazit: Weder Mix'n'Match noch die HiKo hatten die Kryptobiographien der ODNB auf dem Schirm, d.h. anhand Namen der Kryptoperson plus Lebensdaten der Haupt-Person wurde versucht, irgendwelche Schlüsse zu ziehen. Bei Mix'n'Match hat das zur Neuanlage in sich widersprüchlicher Items geführt, bei der HiKo zu Brutalo-GND-Zuordnungen zur Hauptperson: Immerhin ist das der Grund, warum es uns nun auffällt, insofern also sogar positiv zu sehen... -- Gymel (talk) 18:15, 1 May 2015 (UTC)[reply]

So ganz blicke ich noch nicht durch ;) ODNB steht Oxford: ok, aber was haben die Bayern damit zu tun und kann ich jetzt die im oben genannten Beispiel falsche GND einfach löschen oder brauchen wir sie zu Wartungszwecken? Auf jeden Fall schon mal Danke für deine Mühe! --Kolja21 (talk) 23:26, 1 May 2015 (UTC)[reply]

Ach so: Ich hatte deren BEACON-Datei genutzt. Und zwar, - weil (O)DNB/OBIN wg. Mix'n'Match in Wikidata schon sehr umfangreich eingetragen ist - einmal andersherum: Also aufgrund von OBIN/ODNB-Übereinstimmungen bei etwa 9.500 Items die GND-Nummer ergänzt bzw. immerhin "die Bayern" als Quelle (etwa 50/50).

Ich arbeite mich jetzt durch die 180 neu hinzugekommenen "unique-value" violations durch, es wäre gut, wenn die erhalten bleiben könnten, denn darunter sind auch Fälle, wo Mix'n'Match Items mit richtigem Namen und falschen Lebensdaten generiert hat, also veritable Zombies. Die in den "single-value" violations dazugekommenen Fälle dürften hingegen eher harmlos sein - da gab es hier schon ein recht reiches Item und eine falsche GND-Nummer wurde ergänzt. Dein Macleay-Fall ist analog gelagert (beide Q-Nummern unter 18.000.000, also kein anhand ODNB neu erzeugtes dabei), Normdaten waren ansonsten auch schon eingetragen, für den einen gibt es aber keinen GND-Nachweis. -- Gymel (talk) 00:00, 2 May 2015 (UTC)[reply]

Super, klingt vielversprechend. Vor allem freut mich, dass sich die Arbeit mit Wikidata mittlerweile lohnt. Gruß --Kolja21 (talk) 11:29, 2 May 2015 (UTC)[reply]

@Kolja21, Zeromat: Ich bin jetzt mit den 180 durch (Freitag früh müsste der Constraint Report auf 1 runter sein), eine furchtbare Arbeit war das (lästiges Geklicke fürs Nachtragen der immer gleichen Referenz, die ganzen Verwandschaftsbeziehungen und die dussligen Geburts- und Sterbeorte, die ich in en:WP nachrecherchieren musste, keine Chance mit der Suchfunktion auf Wikdiata), wenn ich in einer Stunde 10 schaffte, war es schnell... Ich habe bei User talk:Magnus Manske#Mix'n'match für Oxford DNB einmal nachgefragt wie es sein kann, dass ein gewisser Anteil der HiKo-GND-Nummern (ca. 3%) mangels ODNB-Nummer in Wikidata bei der Aktion überhaupt nicht zugeordnet werden konnte, denn so wie ich die Vorgehensweise verstanden habe, müsste das ODNB hier eigentlich vollständig sein. -- Gymel (talk) 20:05, 6 May 2015 (UTC)[reply]

Qualifikatoren für P227 (GND)

Gleich die nächste Frage. Was hälst du als Qualifikator für akzeptierte GND-Dubletten sinnvoll:

Herman Pijfers (Q2674968)
- GND 119077809 (Pijfers, Herman)
- GND 104501162 (Aardenburg, A. van )
  - subject named as (P1810): A. van Aardenburg
Cupid (Q5011)
- GND 11850262X (Amor)
  - title (P1476): "Amor (Deutsch)"
- GND 118677500 (Cupido)
  - title (P1476): "Cupido (Deutsch)"

Eignet sich "genannt als" als einheitlicher Qualifikator? Er würde uns den nervigen Sprachzusatz bei "Titel" ersparen. --Kolja21 (talk) 12:01, 2 May 2015 (UTC)[reply]

PS: Sehe gerade, dass die Eigenschaft P1810 erst seit 9. April zur Verfügung steht und der Zusatz von dir stammt. Gute Idee! Für Werke wie The Threepenny Opera (Q212495) benötigen wir allerdings weiterhin P1476. Können wir beide Qualifikatoren als zulässig markieren? Ein Fehler liegt ja nicht vor, und wenn wir später geeignetere Qualifikatoren finden sollten, können wir die Entscheidung jederzeit rückgängig machen. Gruß --Kolja21 (talk) 12:16, 2 May 2015 (UTC)[reply]

Ich weiss es selber nicht, daher trage ich halt alles mögliche ein, ohne Anspruch auf Konsistenz, und vertraue darauf, dass das "Unübliche" im Constraint-Report nicht zu schnell abgenickt wird, so dass da ein kleiner Überblick über das vielleicht denkbare und mögliche entsteht.

Die Diskussion vor der Erzeugung von subject named as (P1810), Wikidata:Property proposal/Archive/30#P1810, verstehe ich so, dass es ursprünglich vielleicht um die Namensform in einem Film-Abspann ging und jetzt allgemein um Namensformen anhand Vorlage, also gewiss für eine Author-Property. Nutzung als Qualifier für Normdaten-Verzweigungen streckt das aber vermutlich um noch ein Stück.

Weil mit RDA nun generell die Erzeugung zusätzlicher Normsätze für Pseudonyme an Dynamik gewinnt (ich glaube dass sich im Vergleich zu AACR2 eigentlich wenig ändert, und D-A-CH übers Ziel hinausschiesst, in ein paar Jahren pendelt sich das vielleicht ein, jetzt ist es aber bereits zu beobachten), werden wir häufiger damit zu tun haben. Generell ist da noch nicht klar, ob Pseudonyme und wirklicher Name "Aspekte" des Items sind, oder sogar "betroffene Teile", oder ob wir eine Typologie mit zu pseudonym (P742) vergleichbaren Sachverhalten aufbauen. Aber bei P742 ist mir auch nicht klar, ob man Normdaten-Properties damit qualifizieren sollte, oder umgekehrt P742-Properties mit Normdaten-Nummern als Qualifier versehen. Und was man dann macht, wenn man dann doch einmal eigene Items hat und fuer Pseudonym/Wirklicher Name eigentlich keinen String als Value-Typ benötigt sondern Item (vermutlich said to be the same as (P460) nehmen und mit P742 qualifizieren?). -- Gymel (talk) 13:02, 2 May 2015 (UTC)[reply]

Um das "zu schnell abgenickt" musst du dir keine Sorgen machen. Die Statistik erfasst alle Qualifikatoren, nur listet sie zzt. jeden Eintrag der Qualifikatoren "Titel" und "genannt als" einzeln als Fehler auf. Daher bin ich für "Abnicken unter Vorbehalt". --Kolja21 (talk) 22:26, 2 May 2015 (UTC)[reply]

Q7379767 Rundell and Bridge

Dear Gymel: I see that you have just removed the authority controls I added to this page on the grounds that the page is not that of Philip Rundell. But the point is that on Wikipedia (at least in English) this is the main page for Philip Rundell, who was in partnership with John Bridge. Rundell has a range of authority controls in library systems around the world, but Bridge does not seem to do so. To my mind displaying the references for Philip Rundell is helpful to users. Perhaps there is a way to make it clear that the authority controls that pertain to Rundell are marked as such. In conclusion, it seems a shame not to give apposite information about Rundell, albeit but one half of the partnership of Rundell and Bridge who together served four generations of Hanoverian monarchs as the royal goldsmiths.Sedicesimo (talk) 07:06, 27 May 2015 (UTC)[reply]

Hi Sedicesimo, I just skimmed the articles and had the impression that the business sometimes firmed as "Rundell, Bridge and Rundell", so there might a bunch of different Rundells be involved and noteworthy. So, please use whatever information you have to create new Wikidata items for the persons that deserve it. Unfortunately this will not help the article en:Rundell and Bridge with respect to Philip Rundell, but since there are authority control numbers for the firm (I just added them in wikidata, don't know why I forgot to add them at the first instance) and the firm is different from its founders, there is currently no way to aggregate information from different items within the view of a given wikipedia article. -- Gymel (talk) 07:16, 27 May 2015 (UTC)[reply]

Thank you Gymel: What you suggest and have done seem to be the best solutions under the circumstances. A Wikidata page for Philip Rundell is a good idea. There could even be a link from the Wikipedia en:Rundell and Bridge page. Sedicesimo (talk) 20:37, 28 May 2015 (UTC)[reply]

Actually, a Wikidata item Philip Rundell (Q18783895) had already been created in January to give the reference to his Oxford Dictionary of National Biography a home. I only had to add some authority control data and establish the "founded by" link from Rundell and Bridge (Q7379767). Unfortunately I can't think of a suitable property for the opposite direction, neither "part of", nor "employer" or "affiliation" seem appropriate for the founder of a business... -- Gymel (talk) 20:47, 28 May 2015 (UTC)[reply]

Have added a link from the en:Rundell and Bridge page to the updated Wikidata item Philip Rundell (Q18783895). Such an arrangement would work well, I think, for other key individuals whose only presence in Wikipedia is the organization they work(ed) for.Sedicesimo (talk) 07:38, 29 May 2015 (UTC)[reply]

GND removal

Hello, why you remove GND 4510866-3 from Neue Gedichte (Q15670114)? -- Sergey kudryavtsev (talk) 04:02, 4 June 2015 (UTC)[reply]

Hi Sergey, Neue Gedichte (Q15670114) is an instance of an edition version, edition or translation (Q3331189) and as such rather the opposite of a work work (Q386724). For editions the Google Book Identifiers make much sense, also ISBN, publisher &c and library identifiers like DNB editions http://d-nb.info/997024216 . But "Authority control" like GND identifiers deals exclusively with works, never with editions. Now a certain collection of poems first published in 1844 has aspects of an edition and of a work (the exact same choice of poems has probably been published many more times, also in translations to different languages and so on). But since the wikidata item is exclusively connected with wikisource entries with transcripts of the "original" 1844 edition, the Wikidata item is probably best characterized as an edition. It could be related via property edition of (P629) to an Wikidata item reserved for the collection as a work: This in turn would have GND identifiers but no GBS and "GND editions" properties. -- Gymel (talk) 10:26, 4 June 2015 (UTC)[reply]

Ok, i undestand. Neue Gedichte (Q15670114) is a "book", 4510866-3 is abstract "work". Which instance of (P31) should have Heine's work "Neue Gedichte"? This is not cycle of poems (Q1497584) definitely. May be poetry collection (Q8229494)? -- 11:05, 4 June 2015 (UTC)

Actually, there are many items marked as instances of "book" book (Q571). For me this is something which has not yet (and perhaps never since there is no need) been split into one work and one ore more editions. books indeed could carry GND ID (P227) and DNB edition ID (P1292) simultaneously, or Library of Congress authority ID (P244) and Library of Congress Control Number (LCCN) (bibliographic) (P1144), although the constraint reports absolutely don't like that.

poetry collection (Q8229494) seems to be perfect for "Neue Gedichte" as a work, via subclass relations this is a group of works and - a bit surprising because not true in the general case but correct here - group of works is a subclass of work work (Q386724) (well, not quite sure what is really intended by "group of works" but a collection as the result of an intellectual activity is generally considered a work in itself). -- Gymel (talk) 11:42, 4 June 2015 (UTC)[reply]

Property documentation

Hi Thomas, kannst du mal einen Blick auf Property talk:P1896#Usage? werfen? Es geht um das Feld "Quelle" in der property documentation. Gruß --Kolja21 (talk) 13:27, 7 June 2015 (UTC)[reply]

GND removal 2

Hello, why you remove GND in Valerian Iakovlevitch Ivtchenko (Q4410351)? This is a same person. -- Sergey kudryavtsev (talk) 08:38, 15 June 2015 (UTC)[reply]

Hi Sergey, GND 157773388 does not stand for a person, but for any possible person with that name. (The Label is "Name:" in the GND display, not "Person: ". Or in the VIAF displays it is marked as "undifferentiated" in small print). Since the constraint is not easily enforcable GND ID (P227) "only" pleas for not entering such numbers (there called "type n"), see also the discussoins on Property talk:P227. -- Gymel (talk) 08:44, 15 June 2015 (UTC)[reply]

Ok, unfortunately, the Russian description of P227 doesn't contains warning "(please don't use type n = name, disambiguation)". I translate it for clarification. -- Sergey kudryavtsev (talk) 09:06, 15 June 2015 (UTC)[reply]

Thank you very much (Yesterday I removed about 3.000 P227-values for Type-n records: That means much less than 1% of the instances of P227 had that issue. I had anticipated much more...) -- Gymel (talk) 09:18, 15 June 2015 (UTC)[reply]

Deutsche Biographie

Hallo Thomas, keine Sorge, ich will dich nicht weiter von einer Eigenschaft für die Deutsche Biographie überzeugen. Den Antrag habe ich zurückgezogen, komme aber noch nicht ganz von dem Thema weg. Ich habe die von dir eingetragene dublette GND bei Anne, Princess Royal and Princess of Orange (Q239487) gelöscht und festgestellt, dass sich der Fehler auch in der DB widerspiegel:

Oranje-Nassau, Anna van
Anne <Oranje, Prinses> (GND: Weiterleitung)

Hast du eine Liste deines Datenabgleichs mit der Historischen Kommission, aus der die Dubletten hervorgehen? Und lohnt es sich, die NDB/DB auf die nötigen Korrekturen hinzuweisen oder ist die Redaktion selbst technisch fit genug, um die Fehler zu finden und zu bereinigen? --Kolja21 (talk) 14:19, 17 June 2015 (UTC)[reply]

Am 7. Mai von mir eingetragen und anscheinend am 20. Mai schon bearbeitet - da scheinen sie an der BSB eher einen zeitnahen Workflow zu beherzigen als die großen Monatshappen abzuarbeiten... Also: @Zeromat: müsste von Berufs wegen Antwort geben können (ich selber habe nie einen Datenabgleich vorgenommen, sondern er hatte mir seinen GND/ODNB-Abgleich gezeigt und ich habe ihn mir geschnappt und hier verwurstet). Ich spekuliere mal so:

Die Hiko hat einen "kurzen Draht" zur GND-Redaktion in der BSB, und weil die in der Hierarchie der GND-Redaktionen maximal weit oben angesiedelt ist, ist alles an die BSB outgesourct, d.h. die Hiko schreibt nie selbst in der GND herum (ist nicht selbst GND-Teilnehmer) (Die Alternative wäre wohl, dass sie 90% der Dinge, die sie in der GND tun möchten, nicht dürfen und an die BSB als übergeordnete Redaktion weiterleiten müssten. Gleicher Workflow im Prinzip, nur dass sie dann zwingend die Mailbox-Datenfelder in den GND-Sätzen zur Abwicklung nutzen müssten).
Gerade im aktuellen Projekt (auch die BSB ist Partner und beherbergt die zusätzlichen bzw. fürs Projekt ausgeliehenen Kräfte für die Arbeiten an der GND) werden haufenweise Zusammenführungen von Datensätzen veranlasst, wir können also sicher davon ausgehen, dass das Konzept der "Umlenkungen" dort bekannt ist.
Ich würde aber nicht davon ausgehen, dass Umlenkungen dort automatisiert und zeitnah (also etwa per Harvesting und jeweils zu den wöchentlichen Konsolidierungsläufen in ILTIS) nachvollzogen werden. Bzw. wenn, dann nur für für die im Rahmen der Projekte veranlassten, die damit befassten Mitarbeiter in der BSB haben ja auch Zugriff auf das/die Redaktionssystem(e) der HiKo und müssen da allein aus Workflow-Gründen sofort hinterlegen, dass sie etwas geregelt haben und was das war.
(Die DNB stellt im Februar, Juni und Oktober jeweils Gesamtabzüge bereit, begleitend jeweils eine Datei aller seit dem letzten Abzug umgelenkten Sätze mit den jeweiligen Zielnummern, sowie aller Löschungen. Das kann man sich natürlich auch aus dem Gesamtabzug herausgrabbeln, die Verlierernummern sind da auf ewig vermerkt und was nicht mehr drin ist, wird wohl gelöscht worden sein)
Die Nutzung von GND-basierenden URLs als Permalinks für ein biographisches Angebot ist ganz allgemein eine gewisse Zwickmühle: Man hat eine GND-Nummer zur Konstruktion eines Permalinks für den Artikel benutzt, die es nun dank Umlenkung gar nicht mehr gibt. Einerseits muss man den einmal veröffentlichten Permalink "ewig" unterstützen, da lässt man ihn am besten wie er ist (glücklicherweise recyclet die GND ja "freigewordene" Nummern nicht). Andererseits will man ja gerne zeigen, dass es GND-Nummern sind und daher nun (auch) einen Permalink unter der nun aktuellen GND-Nummer zeigen (und dementsprechend nutzen). Hat man ausserdem drittens einen echten GND-Resolver, dann will man die Entwicklung auch nicht unbedingt umkehren und Anfragen unter der aktuellen Nummer auf die Alte zurückleiten, bloss weil man sich Permalinkmäßig darauf festgelegt hat. Betreibt man nun wie die DB viertens noch eine Datenbank, die GND-Sätze spiegelt, dann muss man auf dieser Ebene natürlich von der alten auf die neue Nummer umlenken, sonst wäre es kein Spiegel mehr. Von da aus müsste man dann beim Übergang auf die Artikel auf die alte Nummer umsetzen, oder eben eher ganz pauschal alle Artikel unter jeder URL zugänglich machen, die mit einer der vergangenen oder aktuellen GND-Nummern konstruierbar ist. Das wäre dann ein Umlenkungen berücksichtigender Resolver auf Artikelebene, unabhängig von dem auf der Datenbankebene. Fünftens bricht das alles auch noch komplett zusammen, wenn das Lexikon aus Gründen der Print-Publikation nicht nachträglich revidierbar ist: Da gibt es etwa in der ADB dublette Artikel, die schon zur Zeit der Drucklegung aufgefallen sind, und solche, für die erst spätere Forschungen die Identität belegt haben, und natürlich den umgekehrten Fall: Ein Artikel, der zwei Personen (falsch) identifiziert, und entweder bereits einen anderen Artikel, der dem widerspricht oder erst spätere Erkenntnisse, die den Split erzwingen. Hier müssen dann unter einer GND-Nummer mehrere Artikel versammelt werden (aber wie adressieren?) oder umgekehrt mehrere, in der GND nicht zusammenführbare, Nummern auf denselben Artikel leiten. Die Wikisource-Edition bekommt das halbwegs hin, indem sie noch eine dünne Schicht von "WS-Annotationen" drüberlegt, die etwa Querverweise ermöglichen. Es kracht aber ganz gewaltig, wenn in Wikisource eine aktuellere GND-Nummer oder eine bessere (sachlich korrektere - auch das kommt vor: Es gibt ja nicht nur Defizite in der Normdatei, die irgendwann durch Umlenkungen bereinigt werden, sondern auch Fehlzuordnungen, die unilateral korrigiert werden müssten) vorliegt, dann funktioniert die Verlinkung auf die offizielle Version nicht mehr, WS kennt eben auch nur "die" GND-Nummer zur Biographie und dokumentiert nicht noch zusätzlich, welche abweichende GND-Nummer das offizielle Angebot nutzt...

Also, um Deine Frage zu beantworten: Nachhilfe braucht die HiKo vermutlich nicht, und ich gehe davon aus, dass sie alle Veränderungen an für sie relevanten Datasets überwachen, allerdings vermutlich anfallsweise, bei der GND vermutlich anlässlich der drei jährlichen Abzugstermine. Angesichts des unterschiedlichen Alters der diversen Datenbestände und der oben geschilderten verschiedenen Ebenen, wo Umlenkungen/redirects berücksichtigt werden müssen, ist m.E. alles recht komplex und etablierte Lösungen dafür gibt es nicht. Und dann ist alles eine Frage der Prioritäten: Wenn man davon ausgeht, dass jede einzelne Inkonsistenz sich im Laufe der Zeit (wir reden hier durchaus von Jahrn) durch automatisierte Prozesse und aktuellere Daten mehr oder weniger von selbst erledigt, ist es halt die Frage (bzw. hängt dann eher von der Summe der zu einem Zeipunkt betroffenen Sätze ab), wieviel man gewinnt, indem man das zu Beschleunigen versucht: Analog zu Deinem Beispiel ist etwa das Pärchen 138638144 (ADB) und 140570233 (ADB auf WS). Der DB-Index kennt beide, führt sie aber nicht zusammen (auch die "Expertensuche" nach den Nummern nicht, d.h. Alt-Nummern sind nicht oder nicht alle indexiert). Die Umlenkung erfolgte spätestens im Juli 2012 (aufgrund unserer Meldung im November 2011). Das ist schon recht lange... Vielleicht sollte ich die Antwort doch noch einmal revidieren: Sie wissen schon, was Umlenkungen sind, da derzeit aber nur maximal 500 ADB-Nummern betroffen sind (so viele kennt die ADB-Beacon-Datei, die die WS-Datei nicht kennt, manche davon könnte WS kennen, andere kennt sie "anders" - das sind diejenigen welche, die lassen sich aber nicht gut zählen), ist dahingehend bislang noch nichts unternommen worden. -- Gymel (talk) 22:58, 17 June 2015 (UTC)[reply]

Danke für die Vorrede und die zwei Antworten; vor allem der letzte Punkt ist spannend. So langsam wird mir klar, warum du so vehement gegen eine Eigenschaft für die DB plädiert hast. Ich habe die Komplexität leider unterschätzt. Wäre ich noch an der Uni eingeschrieben, würde ich ein Seminar in "Digital Humanities" belegen. --Kolja21 (talk) 00:46, 18 June 2015 (UTC)[reply]

Wenn die Uni das anbietet... Wobei DH ja weit mehr umfasst, etwa [15]. Worüber wir hier sprechen, ist vielleicht eher Digital Curation [16], und wenn man es höher hängen will, irgendeine Art von Bindestrich-Informatik. "Nicht in Identifiern ersaufen" hat allerdings wenig mit Computer Science (aka Informatik) zu tun, vielleicht mit Informationswissenschaften (weiss nicht genau was das ist, gerüchteweise die Diplomdokumentare mit neuem Hut?), am ehesten dann doch mit Semiotik: Wobei ich nicht glaube, dass die derzeit in der Lage ist, alltags- und massentaugliche Verfahren für Probleme des Semantic Web zu liefern. Die AfS des ISK der TU Berlin scheint immerhin zu behaupten, dass sie angewandte Semiotik im Portfolio haben [17]. -- Gymel (talk) 06:13, 18 June 2015 (UTC)[reply]

fr:Dirigeable Giffard et nl:Dupuy de Lôme-Luchtschip

Hello,
Thanks for the job you have done for Dirigeable Giffard. Anyway, could you please connect on wikidata these articles fr:Aérostat dirigeable de Dupuy de Lôme and nl:Dupuy de Lôme-Luchtschip ? Thanks you !Mike Coppolano (talk) 18:31, 17 June 2015 (UTC)[reply]

Hi, there was nothing left to do: EmausBot somehow detected the relation half an hour ago and added the sitelink to fr:Aérostat dirigeable de Dupuy de Lôme to the already existing Airship Dupoy de Lôme (Q2550070). -- Gymel (talk) 19:37, 17 June 2015 (UTC)[reply]

Well, well ! Thank you for listening ! Have a good day ! Mike Coppolano (talk) 03:54, 28 June 2015 (UTC)[reply]

Bad GND codes found

Hello, my bot detects a number of strange GND codes. Could you help to fix its or suggest algorithm for bot. Full list:

— Ivan A. Krestinin (talk) 12:49, 29 June 2015 (UTC)[reply]

Hi Ivan A. Krestinin the usual bunch of reasons: missing digit (usually at the end: C&P issue?), wrong check digit, number fit for http://d-nb.info/nnnn instead of http://d-nb.info/gnd/nnn with the sub-cases of pointing with the wrong number to an authority record (your bot usually recognizes that) or to an bibliographic record (P227 is the wrong property for that), or VIAF number inserted as GND number: Just let it land on the format constraints page. Some of those referenced as coming from German Wikipedia had already been corrected there but as a general rule the reporting mechanisms here are faster than there, I don't see how we could detect the fact "GND number on de:WP is better than ours". -- Gymel (talk) 13:52, 29 June 2015 (UTC)[reply]

Thank you for your work. Look like some automatic procedure is impossible, number of cases is too large. Bot does not list these items in "format" section because its are ok for regular expression. — Ivan A. Krestinin (talk) 20:14, 29 June 2015 (UTC)[reply]

Merge

Hi Gymel,

[18] Please keep in mind they are two different people. Thank you, Sealle (talk) 11:10, 13 July 2015 (UTC)[reply]

GND-Dubletten

Hi Gymel, wieso fügst du neuerdings bei der GND als Dublette die PPN (oder heißt es "DNB identifier"?) ein?[19] War das Absicht? Sommerliche Grüße --Kolja21 (talk) 12:54, 7 August 2015 (UTC)[reply]

14:18 Uhr: KrBot hat die PPN in eine GND umgewandelt und in einem zweiten Schritt als Dublette entfernt. --Kolja21 (talk) 16:47, 7 August 2015 (UTC)[reply]

War nicht wirklich Absicht, aber seitdem ich weiss, dass KrBot das tut, bin ich nachlässiger geworden. Ich müsste ihn mal fragen, ob er das nicht stets schon anhand der stündlichen Reports anstelle der täglichen Läaufe tun kann, dann würde es eine wirklich runde Sache... -- Gymel (talk) 07:32, 8 August 2015 (UTC)[reply]

Danke, das leuchtet mir ein. Wikidata ist eh Botland. Wenn es für dich bequemer ist, kann man den "Service" auch ruhig nutzen. --Kolja21 (talk) 11:18, 8 August 2015 (UTC)[reply]

wrong VIAF and no VIAF, yet

Hi, I'm a French librarian, and work with AC everyday (especially BNF and VIAF).

While trying to fix wrong VIAF ID (P214), I found your edit.

I am wondering : I thought these should be fixed through deprecated value, the no value with date qualifier to be used on items that should have VIAF (writers, poets, authors...) but that do not have a VIAF ID, yet.

Maybe we should harmonize our practices ? :) --Hsarrazin (talk) 12:43, 15 August 2015 (UTC)[reply]

@Hsarrazin: I'm working with AC mostly on German WP. Can you explain why Safeway (Q7398681), a supermarket chain in the Channel Islands, should link to VIAF:122405306 (deprecated value)? As fare as I see this VIAF is for a music groud (GND 10334780-X). Cheers --Kolja21 (talk) 17:31, 15 August 2015 (UTC)[reply]

it should not. There is no VIAF for a supermarket chain.

What I mean is, reading the Discuss page on VIAF ID (P214), what I understand is, just remove the value, or, if you don't want a false value to be added again, by bots (it was KrBot I believe) or unknowing persons, rank it as deprecated.

You should only put no value on items that should have a VIAF, which is not the case of Safeway (Q7398681). If one begins to add no value on all properties of all items that should not have one, we will have more no value claims than other claims ;D

it's not a question of if, it's a question of how :) --Hsarrazin (talk) 17:58, 15 August 2015 (UTC)[reply]

During the last weeks KrBot is adding all VIAF numbers from the following scenario: VIAF has by its own matching algorithms recorded a wikidata link for some VIAF cluster and the Wikidata item in question does not yet have any VIAF number. Working through the unique value violations report for VIAF ID (P214) some of these pop up, in many cases there are duplicate Wikidata items which can be merged, in other cases the Wikidata items are different and one or several of the inserted VIAF numbers are plain wrong and have to be deleted here. In order to help VIAF to remedy that on its side (i.e. to remove the Wikidata association from that VIAF cluster) I insert the correct VIAF number into the Wikidata item, but in many cases there isn't any and therefore "novalue" seems to be in place (cf. User talk:Ivan A. Krestinin#Outdated VIAF data?). It's an one-time action and there are special measures not to re-introduce any VIAF number which already had been deleted from wikidata, so these "novalues" are really nothing more than messages to VIAF to reconsider their assignment. The "deprecation" mechanics you mentioned are unrelated - they are used in cases a VIAF cluster contains data for several items so it's not quite usable. Re-import should be never an issue, completely wrong VIAF numbers should also be deleted from the Wikipedias they have been imported from. -- Gymel (talk) 00:15, 16 August 2015 (UTC)[reply]

arf, understood. Did not know that KrBot was a one-time job.

just one small problem : as "no value" is also used to mark items that do not have VIAF, yet (i.e., that will or should have, in the future, once catalogued by member libraries), it is now much more difficult to use this property to periodically re-check VIAF :/ --Hsarrazin (talk) 13:51, 16 August 2015 (UTC)[reply]

I deliberately (at not only of general lazyness) did not qualify the "novalues" with retrieved (P813) as it was discussed somewhere. I very much hope that we can erase these novalues again at some point in the future because periodical rechecking is very laborous. But also most of these items wrongly associated to VIAF clusters could be in VIAF in principle, so IMHO there cannot be a clear distinction. To my impression is that this "periodic re-check" primarily serves specific workflows internal to Wikidata (e.g. for BCU Ecrivainsvd ID (P1253) with its ambitious amount of constraints), and the should is quite subjective. (I agree that for a poet or other person primarily producing text there should be some library keeping track of his works whereas some school in Macao only could edit a yearbook or the like which would then be collected by a library. But these are different degrees of likelihood and there is no clear border...) -- Gymel (talk) 14:06, 16 August 2015 (UTC)[reply]

I agree. Even a supermarket chain could publish a booklet that would be catalogued, and then a VIAF could be attributed :D

not the same probability as poets, historians, novelists, painters, though. :)

if you don't add qualifier, that's fine for me, as the qualifier serve to select for checking updates.

I don't know if you use this script. It automatically retrieves other IDs from the VIAF, using the existing ID in the item, which is quite quick to check for new ids on the VIAF record :) --Hsarrazin (talk) 18:05, 16 August 2015 (UTC)[reply]

Alexander Cunningham

Are you sure about this? It seems to me the two biographies are mighty similar. And in the Early Modern period it wouldn't be surprising to find confusion about minor details such as year of birth. Jonathan Groß (talk) 14:10, 6 October 2015 (UTC)[reply]

Well, de:Alexander Cunningham of Block and de:Alexander Cunningham (Historiker) elaborate on that and even the authority files seem aware of the distinction (the death dates are more significant here). -- Gymel (talk) 15:00, 6 October 2015 (UTC)[reply]

Buchführung

Hallo Thomas, lässt sich Buchführung (GND 4008619-7) als Oberbegriff von:

Single-entry bookkeeping system / deWP: Kameralistik
Double-entry bookkeeping system / Doppelte Buchführung (GND 4113337-7)

verstehen? Wenn ja, müsste wir das Objekt Q192803 entsprechend aufspalten. --Kolja21 (talk) 18:42, 10 October 2015 (UTC)[reply]

Verstehe ich nicht: double-entry bookkeeping (Q192803) ist völlig in Ordnung, nur das Lemma in der Deutschen Wikipedia ist schräg (bzw. Doppelte Buchführung etc. sind Weiterleitungen darauf). Jedenfalls ist de:Buchführung halt die doppelte Buchführung der GND und nicht der Oberbegriff Buchführung. Dafür gibt es eine nette Insel de:Buchhaltung. -- Gymel (talk) 15:22, 11 October 2015 (UTC)[reply]

Wir können Q192803 in "Doppelte Buchführung" (GND 4113337-7) umbenennen (zumindest in "Auch bekannt als" müsste der Begriff aufgenommen werden), aber was wird aus der Buchführung (GND 4008619-7)? --Kolja21 (talk) 22:07, 11 October 2015 (UTC)[reply]

Könnte zu en:Bookkeeping passen, also bookkeeping (Q3707847). Da müsste dann aber wohl de:Buchhaltung abgespalten werden. Aber seit wann müssen wir jeden GND-Sachbegriff irgendwie unterbringen? Ich bin ohnehin schon ganz lala, im September hat de:User:Diopuld anscheinend massenhaft GND-Nummern zu Sachbegriffen in de.WP ergänzt, nicht immer glücklich und die hier resultierenden Unique-Value-Violations sind stellenweise echt eklig aufzulösen... -- Gymel (talk) 05:59, 12 October 2015 (UTC)[reply]

Ja, das Aufdröseln macht eine heiden Arbeit; vor allem, wenn mal wieder jemand leichtfertig mit dem Merge-Button gespielt hat. Bei double-entry bookkeeping (Q192803) gibt es im Moment zwei GNDs, sonst würde es mich nicht stören. --Kolja21 (talk) 18:46, 12 October 2015 (UTC)[reply]

Bin jetzt mal vorgeprescht und habe Wikidata und GND in Übereinstimmung gebracht: double-entry bookkeeping (Q192803) (GND 4113337-7), bookkeeping (Q3707847) aka Buchführung (GND 4008619-7). Das Wikipedia-Lemma müssen wir nicht zwangläufig in Wikidata übernehmen. --Kolja21 (talk) 18:57, 12 October 2015 (UTC)[reply]

de:Buchhaltung ist einfach krumm: Der Einleitungsabsatz betont die Organisationseinheit, die lange Liste der Teilbereiche gibt es nur auf Deutsch oder es sind zumindest auf Englisch Formen des "accounting", also des angeblichen Oberbegriffs de:Rechnungswesen, bei den Weblinks geht es dann aber um die "doppelte Buchhaltung", also de:Buchführung... -- Gymel (talk) 20:48, 12 October 2015 (UTC)[reply]

Asaf Ali Asghar Fyzee

Hi, I just noticed that you have unlinked Wikidata item from article en:Asaf Ali Asghar Fyzee. How does it will affect article or why did you unlink it? What are the benefits of linking Wikidata to an article? Thank you. --Human3015 (talk) 08:19, 18 October 2015 (UTC)[reply]

Human3015 there was another Wikidata item for the same person and I merged the two, cf. Help:Merge. As a consequence the Article in the English Wikipedia is now associated with a different Wikidata item than before. -- Gymel (talk) 08:33, 18 October 2015 (UTC)[reply]

GND ID (P227) format

I'm curious why you object to my simplification of the format string. I changed nothing about what will actually be accepted by the constraint. Popcorndude (talk) 18:06, 25 October 2015 (UTC)[reply]

So you didn't even check how the constraint report changed? Actually, the constraint has not been formulated in the most terse way but rather in a form which could better be commented at Property talk:P227#STICKY: Explanation of format constraints. Cheers! -- Gymel (talk) 18:52, 25 October 2015 (UTC)[reply]

My appologies, I did not realize that the 4th one had no dash. Popcorndude (talk) 19:12, 25 October 2015 (UTC)[reply]

Worthwhile checking with user prior to removing specific data

If you are going to downgrade from specific to more general data, like dates of life, I would hope that next time you would consult prior to the change. For English Wikisource authors, there will often be data on the Author_talk: page if I have added specific data. — billinghurst sDrewth 02:28, 10 November 2015 (UTC)[reply]

billinghurst Sorry, I don't get it: I've downgraded the dates on Archibald Campbell (Q21403371) to what is stated on en:wikisource (no talk page there), since months and days coincide with those of Archibald Campbell (Q4786246) (as stated in en:wikipedia) which seems highly unplausible - at least without any source given as it is the case here. -- Gymel (talk) 05:37, 10 November 2015 (UTC)[reply]

<sigh> Thanks, clearly I haven't saved the research,<headthunk> I did it and hopefully it will still be open on my PC; I will still have records to hand. Rest assured that it was researched from legitimate sources. Now I understand your 'why', though a ping would still have been handy. — billinghurst sDrewth 21:02, 10 November 2015 (UTC)[reply]

Meanwhile I have found and entered a reference for birth and death dates of Archibald Campbell (Q4786246), since as I understand he died in office the official records of the Canadian parliament should be quite precise. For the other issue: Would you mind merging s:en:Author:John Gwenogfryn Evans and s:en:Author:John Gwenogvryn Evans: it seems that the templates I used (sorry, couldn't find merge instructions for the Author namespace) don't trigger any maintenance category. -- Gymel (talk) 21:18, 10 November 2015 (UTC)[reply]

VIAF and ISNI removal

Hello Gymel! You just removed two identifiers. I think they belong to that item and should be restored. Jonathan Groß (talk) 12:05, 10 November 2015 (UTC)[reply]

That cluster was a bit polluted by the wrong GND record, and an unclear NUKAT entry. I guessed disassociation from Wikidata would faciliate the underqualified BNE and SUDOC entries to change to the more homogeneous VIAF cluster 12733002 for the same person. But one can never be sure. -- Gymel (talk) 12:13, 10 November 2015 (UTC)[reply]

I think this is the wrong approach. We should not remove VIAF IDs just because they link sparse third-party IDs. Instead we should create a tool that facilitates error reports to the VIAF contributors and / or VIAF itself. Jonathan Groß (talk) 17:48, 10 November 2015 (UTC)[reply]

@Jonathan Groß: Sorry, wenn ich mich einmische. Nur zur Klarstellung: VIAF nennt zwar eine Feedbackadresse, nimmt aber keine Fehlermeldungen an. Die Datenbeständige werden rein maschinell per Algorithmus gepflegt. Bei der GND gibt es die Möglichkeit, Korrekturvorschläge über die Liste de:Wikipedia:PND/Fehlermeldung an die zwei wichtigsten Mitgliedsbibliotheken (DNB und BSB) weiterzuleiten. --Kolja21 (talk) 18:31, 10 November 2015 (UTC)[reply]

(edit conflict) Jonathan Groß In April VIAF switched from en:Wikipedia to Wikidata as kind of actively handled contributor. This means for example that VIAF actually will be influenced for future clustering decisions when we record several VIAF Ids for one Wikidata item. In the case of the two Hermann Schraders the desired result is not as simple as just merging the clusters, since the GND Schraders involved definitely are two different persons. If one could influence BNE and SUDOC to provide the exact death years in their records I'm convinced they would be soon associated with the "better" VIAF cluster and in this case not recording the suboptimal VIAF number in Wikidata would positively influence that process. But actually we do not have this kind of influence and given the fact that the majority of the records in the VIAF cluster is about the same Schrader we can just additionally record its ID and stop speculating about how to make life easier for VIAF. -- Gymel (talk) 19:04, 10 November 2015 (UTC)[reply]

PS: Das Problem sind nicht spärliche (sparse) Informationen, sondern reine Namenseinträge, vergleichbar mit BKL-Seiten. Beispiel aus dem englischen Wikisource, wo wild jeder vermeintliche Treffer verlinkt wurde:

s:en:Author:Henry L. Clarke (?-?) = VIAF:44686158 (undifferentiated).[20]

Diese VIAF-Nummern sollten wir in der Tat löschen, da wir sonst VIAF, wie in diesem Fall bereits geschehen, vorgaukeln, dass die Nummer sich auf eine konkrete Person bezieht. --Kolja21 (talk) 18:49, 10 November 2015 (UTC)[reply]

Hier im Beispiel war kein Tn beteiligt, sondern ein Tp zum Begründer einer Schriftenreihe, über den einfach nichts herauszufinden ist. (und m.E. ist VIAF unterschiedlich erfolgreich im Berücksichtigen von Wirkungsjahren, GND-Sätze verstecken die wohl so gut dass sie unberücksichtigt bleiben, in anderen Quellen sind sie von Lebensjahren nicht unterscheidbar, das ist auch nicht gut...) -- Gymel (talk) 19:04, 10 November 2015 (UTC)[reply]

Okay. Wenn Eingaben an VIAF nicht sinnvoll sind, müssen wir wohl Fehlermeldungen an die VIAF-Partner absetzen. Ich habe das im Sommer mal mit ISNI ausprobiert. Die haben nach sechs Wochen geantwortet. Bei der GND-Fehlermeldung habe ich lange Zeit alles gemeldet, was ich gefunden habe, aber seit Jahren stauen sich dort die Meldungen, von denen einige anscheinend ganz ignoriert werden.

Sollen wir einen neuen Anlauf mit GND-Fehlermeldungen starten? Vielleicht den direkten Kontakt zur GND suchen? Jonathan Groß (talk) 08:14, 11 November 2015 (UTC)[reply]

Wir haben einen direkten Kontakt zur den GND-Redaktionen der BSB (Bearbeitungszeit: 1 Monat) und er DNB (Bearbeitungszeit: 2 Jahre). Weitere Ideen & Vorschläge unter de:Portal:BID/Normdaten erwünscht. --Kolja21 (talk) 15:59, 11 November 2015 (UTC)[reply]

Q218960

My edit was based on the constraint report for screenwriter (P58). There were a lot of P58 statements which didn't have a relevant P106 claim. Since the list was too long for manually checking I added the statement using autolist for item that has a P58 claim. Mbch331 (talk) 18:52, 16 November 2015 (UTC)[reply]

Ah, A Cock and Bull Story (Q300371). Yes, it's tempting to add the "author of the work the film is based on" as screenwriter, especially since the display of based on (P144) doesn't reveal him. -- Gymel (talk) 19:27, 16 November 2015 (UTC)[reply]

Nello Vegezzi

Why did you remove the reference to GND to that author? It's a correct reference, as you may verify by yourself directly on GND database just following this link. And, yes, Nello Vegezzi has a double entry on VIAF, the second one referring exactly to this GND ID. I reverted your revert, since the GND ID is present and verifiable. --L736E (talk) 18:39, 22 November 2015 (UTC)[reply]

Hi @l736E: GND 179203215 corresponds to a so-called "name entry" and as such does not stand for a single person. Therefore it does not represent a single person like Nello Vegezzi (Q21501598). Unfortunately the property description doesn't tell in all languages "please don't use type n = name, disambiguation".

As for the VIAF entry: VIAF in principle is aware of the concept of an "undifferentiated" entry and displays that fact e.g. at VIAF 191149527. But there are caess where such undifferentiated entries are included with "regular" entries within one cluster. This may happen when VIAF knows about titles connected with that name entry and these titles (or their majority?) also applies to the regular ones. In the Vegezzi case VIAF seems to have no evidence of any title connected to GND 79203215 and probably on purpose does not try to integrate that record into the other Vegezzi cluster VIAF 78013091. So for VIAF clusters which essentially only consist of an "undifferentiated" GND record the same reasoning as for the GND record itself should apply. -- Gymel (talk) 21:22, 22 November 2015 (UTC)[reply]

OK clear now. Thanks for the explaination.--L736E (talk) 18:18, 23 November 2015 (UTC)[reply]

LC Classification

Gymel, Concerning one of your corrections [21] can you explain when the LC Classification for a book should be entered in this database? I have added this only recently but probably dozens one month ago including about 15 books by Rick Riordan (example [22]) where I added them here at the same time as doing the infobox at English Wikipedia. Should I delete all?

LCAuth i understand. Probably i typed 'LC' and accepted the autocompletion without looking.

--P64 (talk) 16:30, 4 December 2015 (UTC)[reply]

P.S. See a book record at LCCN [23] (another title whose LC Classification i entered here in mid-October), i wonder now also about the Dewey classification 301.5/4/0942 and the home National library number B72-35164 (in this case, British). --P64 (talk) 18:38, 4 December 2015 (UTC)[reply]

P64 There are two Iconclass properties: Iconclass notation (P1256) is the mapping between concepts here and classification numbers there, tentatively an 1:1 correspondence. And depicts Iconclass notation (P1257) is for actually recording iconclass notations as determined by applying Iconclass rules to a specific work of art. What you are asking for in the LCSH context would be an analogue of the latter, but I'm quite confident that we don't currently have a corresponding property at Wikidata. -- Gymel (talk) 20:09, 6 December 2015 (UTC)[reply]

Singular or plural

Hi,

I see you changed the instance of (P31) and changed the labels to plural on faun (Q223194) but shouldn't this item be about singular (the creature in itself) rather than plural? Or should we create two different items?

Cdlt, VIGNERON (talk) 15:16, 7 January 2016 (UTC)[reply]

VIGNERON It's long time since, but I can recollect that I have been trying to work around a possible conflict with "the" faunus Faunus (Q3089703). -- Gymel (talk) 17:07, 7 January 2016 (UTC)[reply]

I forgot about the god.

Can I revert you and switch back to singular ? I see no reason no to.

Cdlt, VIGNERON (talk) 14:13, 9 January 2016 (UTC)[reply]

I did so. However I'm not sure about Capitalization in most of the languages: Singular is o.k., but it's not the proper name of one being, but of a class... -- Gymel (talk) 15:47, 9 January 2016 (UTC)[reply]

Lichtenbusch

Hallo Gymel,

Warum darf es für Lichtenbusch keine VIAF und GND Einträge geben? Grüße, --ACBahn (talk) 16:54, 19 January 2016 (UTC)[reply]

Weil es jetzt drei Lichtenbusch-Items gibt und die Normdaten daher passender verteilt werden können und auch müssen: Lichtenbusch (Q882843) das Ganze, Lichtenbusch (Q21839544) der Ortsteil von Aachen mit GND und VIAF, Lichtenbusch (Q3238097) der Ortsteil von Raeren mit anderer GND und VIAF. -- Gymel (talk) 16:58, 19 January 2016 (UTC)[reply]

Revert on Dante Della Terza (Q3702354)

He is the same person, I personally checked. SBN item "IT\ICCU\AUFV\001433" it's a duplicate of "IT\ICCU\CFIV\062522", I included it in Dante Della Terza (Q3702354) for the time to avoid that someone might create a duplicate (maybe with Mix'n'match).

I already alerted ICCU (where I work) for matching those two SBN codes (and other codes which I found are duplicate), they'll do it asap. In the meanwhile, I ask you if I can revert your edit or if you can do it on your own. --Sannita (ICCU) (talk) 13:44, 28 January 2016 (UTC)[reply]

Dante Della Terza (Q22280150) <-- Q.E.D. (Q188722) --Sannita (ICCU) (talk) 13:57, 28 January 2016 (UTC)[reply]

Sannita Just go ahead. There was no contradicting information in the ICCU records (I noticed one inconsistently assigned work on Dante) but a specialist in early italian literature mostly working abroad translating socialist literature from German to Italian just did not appear plausible to me. However if you were in a position to check the identity based on the work in question there is no room left to dispute. -- Gymel (talk) 22:34, 28 January 2016 (UTC)[reply]

Revertierung meiner Änderungen an Amitav Ghosh (Q336125)

Hallo Gymel,

du hast die von mir zu Amitav Ghosh (Q336125) hinzugefügten Normdaten-IDs wieder entfernt, da du der Meinung bist, dass es sich um verschiedene Personen handelt.

Im Grunde geht es dabei darum, ob die beiden VIAF-cluster 90707863 und 261269554 (bzw. die zugehörigen Normdaten-IDs) ein und dieselbe Person beschreiben.

Aufgrund der folgenden drei Punkte gehe ich davon aus, dass es sich um die selbe Person handelt:

beide Cluster sind mit dem selben Namen „Ghosh, Amitav“ versehen
beide Cluster nennen als Geburtsdatum 1956
die Cluster nennen viele identische Buchtitel (hier nur ein Auszug der Gemeinsamkeiten):

Calcutta chromosome in beiden Clustern und Chromosom z Kalkuty : powieść o gorączce, delirium i olśnieniu in 90707863 (auch im deutschen und englischen Wikipedia-Artikel genannt)
Circle of reason in beiden Clustern und El Círculo de la razón in 261269554 (auch im englischen Wikipedia-Artikel genannt)
Countdown in beiden Clustern (auch im englischen Wikipedia-Artikel genannt)
Dancing in Cambodia : at large in Burma in 261269554 und Dancing in Cambodia, at large in Burma / Amitav Ghosh in 90707863 (auch im englischen Wikipedia-Artikel genannt)
Glaspaladset und The ¤glass palace in 90707863 sowie Glass palace und Glaspalast Roman in 261269554 (auch im deutschen und englischen Wikipedia-Artikel genannt)
…

Es kann natürlich sein, dass einzelne Normdaten-IDs aus den Clustern eine andere Person beschreiben, aber ich denke man kann recht sicher davon ausgehen, dass jeweils die Mehrheit der Normdaten-IDs in den beiden Clustern ein und dieselbe Person beschreiben, die auch durch Amitav Ghosh (Q336125) repräsentiert wird.

Viele Grüße, --Floscher (talk) 13:47, 31 January 2016 (UTC)[reply]

Wenn ich mich recht entsinne, meinen in dem Cluster ICCU und Nukat den bekannten Schriftsteller, und LCNAF definitiv einen anderen (selbstpublizierten Reiseführer zu Schottland), bei den anderen ist es unklar, daher sollten die nicht ins Item. ICCU habe ich m.E. wiederhergestellt, Nukat noch nicht (die VIAF-Übernahme klemmte in dem Moment). -- Gymel (talk) 14:06, 31 January 2016 (UTC)[reply]

Ja stimmt, das hab ich übersehen. Hab mal noch die ISNI-Nummer hinzugefügt, da auch dort das Geburtsdatum und die aufgelisteten Titel übereinstimmen. Danke für die Erklärung, mit dem jetzigen Stand bin ich dann zufrieden. --Floscher (talk) 14:30, 31 January 2016 (UTC)[reply]

Done

Normdaten, die Zweite

Hallo Gymel,

du hast mir vorhin meine Watchlist geflutet. Gestern und heute habe ich nämlich versucht, dort wo eine FAST-ID an einer BKL hing, die ID auf den Wikidata-Eintrag für die jeweils gemeinte Person zu übertragen. Du hast nun bei den folgenden Wikidata-Elementen, die alle BKLs sind, die FAST-ID wieder hinzugefügt:

Ole Hansen (Q21877305) (31.1.2016 19:51)
Dhumketu (Q20998143) (31.1.2016 19:51)
Dennis Marks (Q20998080) (31.1.2016 19:51)
Joyce Chen (Q20999364) (31.1.2016 19:51)
Horace R. Cayton (Q20999090) (31.1.2016 19:51)
Will Thomas (Q20815897) (31.1.2016 19:51)
Keith Thibodeaux (Q20815895) (31.1.2016 19:51)
Charles Simms (Q20815810) (31.1.2016 19:51)
Roy Simmons (Q20815809) (31.1.2016 19:51)
Patrick Scott (Q20815789) (31.1.2016 19:51)
Pope Peter of Alexandria (Q20815727) (31.1.2016 19:51)
Howard Reid (Q20815748) (31.1.2016 19:51)
Kate O'Brien (Q20815668) (31.1.2016 19:51)
Eugene Meyer (Q20815608) (31.1.2016 19:51)
Henry Huth (Q20815365) (31.1.2016 19:51)
Ramiro Martinez (Q20815572) (31.1.2016 19:51)
John Heydon (Q20815342) (31.1.2016 19:51)
George Lynn (Q20815539) (31.1.2016 19:51)
Paul Hiebert (Q20815345) (31.1.2016 19:51)
John Henley (Q20815337) (31.1.2016 19:51)
Peter Gould (Q20815277) (31.1.2016 19:51)
Bruce Elder (Q20815211) (31.1.2016 19:51)
Laura Dean (Q20815176) (31.1.2016 19:51)
Louise Cox (Q20815157) (31.1.2016 19:51)
Manuel da Costa (Q20815168) (31.1.2016 19:51)
Mario Merola (Q20660669) (31.1.2016 19:51)
Sándor Bródy (Q19001690) (31.1.2016 19:50)
Michael Saward (Q17349676) (31.1.2016 19:49)
Mary Healy (Q12035945) (31.1.2016 19:47)
Curley (Q11252057) (31.1.2016 19:47)
Reza Pahlavi (Q11174627) (31.1.2016 19:47)
Luís de Sousa (Q10321770) (31.1.2016 19:47)
Wade Davis (Q7959037) (31.1.2016 19:46)
William Page (Q8016528) (31.1.2016 19:46)
Thomas Armstrong (Q7787132) (31.1.2016 19:46)
Ron Smith (Q7364398) (31.1.2016 19:46)
Rhys Davies (Q7321772) (31.1.2016 19:46)
John Sayer (Q6256806) (31.1.2016 19:46)
John Haynes (Q6238404) (31.1.2016 19:46)
John Disney (Q6229483) (31.1.2016 19:46)
John Gwynne (Q6236677) (31.1.2016 19:46)
John Brown (Q6217561) (31.1.2016 19:46)
Eric Walker (Q5387692) (31.1.2016 19:45)
Charles Kent (Q5079761) (31.1.2016 19:45)
Charles Forbes (Q5077721) (31.1.2016 19:45)
Charles Bridges (Q5075776) (31.1.2016 19:45)
Andrew Harvey (Q4757252) (31.1.2016 19:44)
Alexander Rose (Q4719974) (31.1.2016 19:44)
Alun Lewis (Q4707150) (31.1.2016 19:44)
Alexander Mitscherlich (Q3610789) (31.1.2016 19:42)
Louis Marin (Q3262636) (31.1.2016 19:41)
Julie Harris (Q3189219) (31.1.2016 19:41)
Louis Thomas (Q3263179) (31.1.2016 19:41)
Walter Judd (Q2544964) (31.1.2016 19:40)
Jack Brooks (Q1956323) (31.1.2016 19:37)
Gordon Williams (Q1445177) (31.1.2016 19:31)
János Vajda (Q1400953) (31.1.2016 19:31)
Thomas Thynne (Q1270738) (31.1.2016 19:30)
John Burke (Q1270112) (31.1.2016 19:30)
John Hope (Q1215064) (31.1.2016 19:30)
Alfonso of Aragon (Q1180515) (31.1.2016 19:30)
Billy Jenkins (Q863132) (31.1.2016 19:28)
Arthur Berger (Q708635) (31.1.2016 19:28)
Thomas Bennett (Q600932) (31.1.2016 19:28)
Alan Jones (Q530506) (31.1.2016 19:27)
Peter Allen (Q528058) (31.1.2016 19:27)
Charles Dumont (Q475755) (31.1.2016 19:27)
Ray Collins (Q406286) (31.1.2016 19:27)
Robert Richardson (Q402649) (31.1.2016 19:27)
John Bell (Q403286) (31.1.2016 19:27)
Theodoros Pangalos (Q365590) (31.1.2016 19:27)
Charles Stuart (Q363336) (31.1.2016 19:27)
John Lewis (Q359218) (31.1.2016 19:27)
Robert Brown (Q358773) (31.1.2016 19:27)
Robert Smith (Q294776) (31.1.2016 19:26)
David Johnson (Q239537) (31.1.2016 19:26)
John Smith (Q245903) (31.1.2016 19:26)
Andrew Kennedy (Q129334) (31.1.2016 19:26)
Meto Jovanovski (Q72264) (31.1.2016 19:24)
John Gillies (Q15393) (31.1.2016 19:24)

Bei einigen hab ich die Änderung wieder rückgängig gemacht, bei anderen noch nicht. Die IDs wurden dieser Tage von User:Reinheitsgebot hinzugefügt auf Grundlage der in FAST hinterlegten Wikipedia-Seite. Da diese teilweise nicht auf dem neusten Stand ist, zeigt diese inzwischen auf eine BKL-Seite.

Viele Grüße, --Floscher (talk) 21:25, 31 January 2016 (UTC)[reply]

Gerade ist mir noch aufgefallen, dass du bei denjenigen BKLs, die noch eine FAST-IDs hatten, diese entfernt hast. Da hättest du sie lieber dem korrekten Wikidata-Element zuordnen sollen, statt sie einfach zu löschen. Wenn du das nicht gemacht hättest, hätte ich es in den nächsten Tagen sicherlich gemacht, da ich eh gerade dabei bin, die constraint violations für die FAST-ID zu beheben. --Floscher (talk) 21:35, 31 January 2016 (UTC)[reply]

Hallo Floscher, danke für die Liste oben: Die Zuordnungen zu den BKL-Seiten sind in Mix'n'Match hinterlegt und müssen dort ausgetragen werden, damit sie nicht immer wieder kommen (solange sie dort falsch sind, können die hier bereits korrigierten Zuordnungen nicht übernommen werden). Ich mache mich mal dran. -- Gymel (talk) 23:10, 31 January 2016 (UTC)[reply]

Im Zusammenhang damit: Alexander Schreiner (Q2012405), John Nunn (Q450419) und Graham Nash (Q357211): Wenn wir davon ausgehen, dass die FAST-Records eine Kopie des LCNAF darstellen und quasi als Momentaufnahme VIAF-Nummern, Wikidata-Item-Nummern und en-Wikipedia-Links hinterlegt sind, dann "zieht" für die Bedeutung letztlich stets die LCNAF-Nummer. Und für diese drei Personen "gehören" die von Dir wiederhergestellten FAST-Nummern zu (LCNAF-weise) völlig anderen Personen. Zudem sind die so randständig, dass sie hier auf absehbare Zeit kein eigenes Item haben werden, ausser zum zugehörigen FAST-Item wird eins erzeugt. Hinterlassen im Wikidata-Item (in der Hoffnung, dass jemand eine "Dublette" erkennt?) hielte ich daher für eine schlechte Idee. -- Gymel (talk) 00:23, 1 February 2016 (UTC)[reply]

Ganz so einfach ist es leider nicht:

Beide FAST-items für Alexander Schreiner (Q2012405) (1467298 und 192701) beschreiben einen in Nürnberg geborenen Organisten des „Mormon Tabernacle Choir‏“, der in Salt Lake City gestorben ist.‏ Unwahrscheinlich, dass das zwei verschiedene Personen sind. Die beiden LCNAF-Einträge beschreiben allerdings höchstwahrscheinlich zwei unterschiedliche Personen, denn der Organist wird wohl eher nicht drei Jahre vor seinem Tod ein Buch mit dem Titel „Einfluss des Oberflächenzustandes und des Randkohlenstoffgehaltes auf Nitrocarburierschichten aus der Gasphase“ geschrieben haben. Deshalb bin ich mit dem momentanen Stand des Wikidata-items zufrieden.
Bei John Nunn (Q450419) kannst Du gerne die FAST-ID 105858 entfernen, da die Infos in der FAST-Datenbank nicht eindeutig auf den Schachgroßmeister verweisen. In LCNAF wiederum sieht es aber tatsächlich eher nach zwei verschiedenen Personen aus, außer der Schachgroßmeister hat Bücher über „Bath Assembly Rooms“ geschrieben. Bei diesem Item hab ich auf Grundlage der Links zu VIAF und enwiki gefolgert, dass es sich bei den FAST-Einträgen um die selbe Person handelt.
Bei Graham Nash (Q357211) scheinen ebenfalls die FAST-Einträge (mangels Information) nicht eindeutig zwei verschiedene Personen zu beschreiben. Die LCNAF-Einträge dank der Literaturangaben schon. Von daher könnte von mir aus auch hier die FAST-ID 118091 entfernt werden.

Danke für den Hinweis, werde zukünftig öfter mal bei Unsicherheiten LCNAF zu Rate ziehen. Die obigen FAST-IDs hab ich rein auf Grundlage der FAST-Einträge als Dubletten eingestuft. Denn wie man an dem ersten Punkt sieht, ist FAST nicht immer nur eine Kopie von LCNAF. --Floscher (talk) 15:19, 2 February 2016 (UTC)[reply]

Zu Alexander Schreiner waren am 15.2.2015 zum Zeitpunkt der Generierung des Fast-Records noch beide LCNAF-Aufnahmen Bestandteil desselben VIAF-Clusters 50091967, wie man an dessen History erkennen kann (der zweite LCNAF-Satz wurde im Juli 2015 abgetrennt). Für den FAST-Record wurde aus dem VIAF-Record angereichert, daher dann auch die identischen Wikipedia-Links. Es war also (unter der These, dass FAST LCNAF und LCSH repliziert) etwas verschiedenes gemeint, es wurde aber aufgrund des "unsauberen" VIAF-Clusters zu einem bestimmten Zeitpunkt stets dasselbe ausgedrückt. Was das nun im Hinblick auf die Identität der beiden FAST-Records bedeuten kann, ist mir auch nicht klar, wie praktisch damit umgegangen wird schon eher: Es ist ja keinem Nutzer von FAST-Headings zuzumuten, die präsentierte Information auszublenden und sich auf die - wahrscheinlich von niemandem archivierten - historische Version eines LCNAF-Satzes zurückzuziehen. Also dürfte es wohl als Dublette behandelt werden. Allerdings weiss ich von FAST nur, dass OCLC es innerhalb des WorldCat verwendet, ob es redaktionelle Strukturen gibt, die mit Dubletten umgehen, oder ob einfach weiterhin jeder neue LCNAF-Record (unter gewissen Randbedingungen) automatisiert eine eigene FAST-Id verpasst bekommt und aus VIAF etwas angereichert auf die Reise geschickt wird, weiss ich nicht... -- Gymel (talk) 21:45, 2 February 2016 (UTC)[reply]

William Stuart = William E.D. Stuart

Hi, I noticed your reversion of my edit on William E. D. Stuart (Q21464645). I believe these are the same person, as they clearly both are marine painters and according to the Australian biography, he was the only one painting ships under that name at that time. I have linked a few of these doubles over the years and the PCF has merged them, though it may take a year for them to get around to it. Best, --Jane023 (talk) 09:08, 22 February 2016 (UTC)[reply]

Hi Jane23: I noticed that BBCYP knew both of them, an (obvous) marine painter William Stuart, d. after 1867 [24] (quite certainly this is RKD 75888 "active in London"), and William E.D. Stuart d. 1858 with a still life [25] (probably RKD 208873, but who is "Stuart William E.D. (I)?). Right now I notice the Battle of Trafalgar for the second painter at BBCYP and "stillevens" at RKD. Likewise there are two corresponding William Stuart / William E. D. II. Stuart in ULAN. And DAOO might indeed provide the link to Australia. Also Benezit (I'm usually giving most trust to this source) knows about William Stuart (historical subjects, battles, seascapes, "William Stuart exhibited in London between 1848 and 1867.") and W. E. D. Stuart (still-lifes and fruit, "W.E.D Stuart exhibited in London from 1846 to 1858"). So following the distinct genres I think there were actually two different painters active in London about the same time and one of them might have been emigrated to Australia in 1857. Who of them might have been fully named William Evans Dutton Stuart would be another question, and perhaps the hints to "W. E. D. Stuart (I)" vs. ""W. E. D. Stuart (II)" are just indicative for the fact that they have been commonly confused ... -- Gymel (talk) 14:38, 22 February 2016 (UTC)[reply]

If there are two painters, then one is a still life painter and the other is a marine painter. I find it highly doubtful that two painters with the same name both made paintings in these two genres. It's much more probable that they are in fact the same person, as their dated works are all about the same style-wise. The (I) and (II) is also just a shot in the dark. --Jane023 (talk) 00:02, 23 February 2016 (UTC)[reply]

You mean the style of the fruit still lives is the same as that of the naval battle scenes? The only thing apparent to me at BBCYP wsa that neither of them is signed in front. The Australian person also worked at a school teacher so I think we are talking about the probability that there were two persons with the not very distinctive name W[illiam?] Stuart in London around 1850 who could paint decently enough to exhibit. -- Gymel (talk) 05:43, 23 February 2016 (UTC)[reply]

Complicated. W. E. D. Stuart was from a family of artists, and his father William Stuart also was a marine painter. Christie's [26] give a Trafalgar picture that they attribute to the father. I'm looking at The Dictionary of Victorian Painters, and it keeps W. E. D. Stuart and William Stuart separate: the information there is consistent with the theory that the first is the son and emigrant to Australia, the second the father. Charles Matthews (talk) 09:27, 25 February 2016 (UTC)[reply]

Oxford Dictionary of National Biography ID (P1415) and CERL Thesaurus ID (P1871)

Hello again. Some good news about Oxford Dictionary of National Biography ID (P1415). By means of a SPARQL query I am now able to find the missing numbers, and fill in the items. For example, I have now checked the numbers 101000001 to 101009999, which is about 17% of the 60K actual identifiers. There are 16 numbers not used in that range, and I have a list.

For CERL Thesaurus ID (P1871), there is a BEACON file matching to GND, mentioned on https://www.cerl.org/resources/cerl_thesaurus/linkeddata. I was discussing CERL on mix'n'match with Magnus Manske. The BEACON file itself does not really have enough good information to support matching. The way the FAST identifier is handled now on mix'n'match is to provide two identifiers (VIAF and LCAuth), and also dates where possible. So I thought I would ask you if that could also be possible for CERL, based on the matching to GND. Charles Matthews (talk) 08:51, 25 February 2016 (UTC)[reply]

Charles Matthews Great news about ODNB, indeed. As for FAST, I'm extremly unhappy about including them in Wikidata at all: The display at the OCLC site usually contains only the "authorized heading". When working through the constraint reports I quite often encounter the situation where this heading does not contain dates and I have to query for the Q-Number in Mix'n'Match to get the VIAF and LC number from Magnus' display. Only then I'm able to consult the LCNAF record and learn the meaning of the FAST heading (I presume it was the base for the FAST record because FAST is an attempt to get rid of LCSH in subject cataloguing which includes those LCAuth records suitable for that task). Sometimes it even turns out that the LCAuth record is an "undifferentiated" one. Given the fact that we don't even know who is using FAST we are confronted with the unfortunate task of dealing a huge dataset which came into existence by automated cloning of another huge dataset and the hope that the semantic content of the record will somehow magically migrate with the records along their path...

The situation with CERL indeed is quite similar: The (almost-) BEACON file http://thesaurus.cerl.org/beacon/gnd.txt contains some 525.000 tuples and has a timestamp of 2012-03-23 and I just verified that this is identical to a copy from September 2012 I happened to find on my disk. So at some time in the past they (I actually never found out who is behind CERL in the sense of doing actual work, this particular import might have been performed by people from GBV in Göttingen associated with the VD-17 project) cloned a huge part of the PND (everything connected to old literature, especially VD-17, and/or printers, etchers et c.). The newest record mentionend in the BEACON file is dated 2012-02-28, which means the data set described by the BEACON file from 2012-03 has been "current" in a sense. However the contributor page states that the "PND" dataset is updated monthly (and sized about 403.000 records). Other substantial ingredients are 128.000 records from VD-16 imported in 2003 from the Bayerische Staatsbibliothek and 188.000 personal name headings imported 2006 from GBV - these have been possibly migrated into the GND long before 2012. Then there seems to be a monthly update from BNF records.

So,

assuming that those updates actually happen (all contributors are in a league where signing some project contract constitutes a stronger "truth" than the processes actually happening) the BEACON file from 2012 is quite useless (we could track changes in the GND since but we should have to verify that the individual CERL numbers still exist and their meaning did not change within the last four years - impossible!).
if CERL has some dynamics by ingesting some datasets on a regular base we don't know what actions (associations) they are perfoming on it to turn it into the CERL thesaurus. Are they processing deltas or exchange the whole dataset? Can they track redirects within the GND or BNF dataset? These all should be influencing factors for the stability of their "cn"-Numbers and should have been known before it was decided here to create CERL Thesaurus ID (P1871)...

Since CERL is of some interest because of (again not very clear) links to Europeana, User @Hanshandlampe: might know more about CERL, since he is involved with DDB, another venue in contact with Europeana. -- Gymel (talk) 10:26, 25 February 2016 (UTC)[reply]

Thanks for the very full reply. Obviously there should be some better ways to handle CERL, and I'll mention this all to Magnus. Charles Matthews (talk) 10:30, 25 February 2016 (UTC)[reply]

Historische Kommission

Falsche GND-Zuordnung der Historischen Kommission bei der Bayerischen Akademie der Wissenschaften: Charles Le Morvan (Q2960753) mit der GND von Pierre Puiseux (Q984602).[27] Habe den Fehler korrigiert. Gruß --Kolja21 (talk) 18:07, 27 March 2016 (UTC)[reply]

Danke. Die BEACON-Datei enthält sehr viele Tn, wie ich bei der Bearbeitung der über 100 entstandenen "single value" violations feststellen muss. Methodisch kommt die Datei der HiKo wohl so zustande, dass sie die aus den in/bei der Stuttgart Database of Scientific Illustrators hinterlegten VIAF-Nummern per VIAF die GND-Nummern herausgezogen haben, und ich habe wiederum anhand der SDI-Nummer diese GND-Nummern hier ergänzt (allerdings nur in den Fällen, wo noch gar keine eingetragen war). Waren ein paar hundert, und davon fliegt nun gefühlt die Hälfte wieder raus. -- Gymel (talk) 18:14, 27 March 2016 (UTC)[reply]

Soll ich die falsch zugeordneten GNDs einfach löschen oder willst du die Fehler sammeln? Neu: Max Landsberg (Q1391016). Gruß --Kolja21 (talk) 18:25, 27 March 2016 (UTC)[reply]

Mit den "single value" violations bin ich gerade durch, in ein paar Stunden mache ich mich an die (wenigen) "unique value" violations. Sammeln tue ich da nichts, irgendwem zu melden, dass die VIAF-Zuordnung ganz nett ist, aber die davon abgeleitete GND-Zuordnung problematisch, ist eine Nullaussage. -- Gymel (talk) 18:31, 27 March 2016 (UTC)[reply]

VIAF für Hat Yai (Q475518)

Warum hast du den VIAF-Link für den Kreis Hat Yai gelöscht? Soweit ich das aus der VIAF-Seite lese, ist tatsächlich der Kreis gemeint, und nicht etwa die Stadt Hat Yai (Q651286), zu der der fälschlicherweise in der DE-Wikipedia gelinkt war. Bei der Stadt habe ich ihn noch dringelassen aber als "deprecated" markiert, damit der Bot ihn nicht gleich wieder falsch einträgt - also wenn du ihn als doppelten Link löschen wolltest, dann hast du den falschen der beiden erwischt. Ahoerstemeier (talk) 10:52, 4 April 2016 (UTC)[reply]

Ahoerstemeier VIAF 147885649 ist verbunden mit:

GND 4415782-4 "Definition: Stadt auf d. Halbinsel Malakka nahe d. Grenze zu Malaysia"
FAST 01335313 Thailand--Hat Yai (Amphoe)

Ooops. Also stimmt beides (ich hatte wohl "Amphoe" für den Namen des zugehörigen Distrikts gehalten...). Lösung ist, diese VIAF-Nummer gar nicht zu verwenden, sondern VIAF 125534965 für die Stadt und VIAF 931145857933823020652 für den Distrikt. -- Gymel (talk) 12:57, 4 April 2016 (UTC)[reply]

Danke, die Verwirrung zwischen Stadt und Kreis (und in diesem Fall sogar noch ein Unterkreis Hat Yai (Q16295550), der noch dazu genau die Fläche der Stadt abdeckt aber eine andere Verwaltungsstruktur ist) ist immer schwer auseinanderzusortieren, noch schlimmer bei Geburtsorten, wenn eine Thai-Quelle die Provinz meint wird dann durch Verkürzung oft die Provinz"hauptstadt" draus. Ahoerstemeier (talk) 09:11, 5 April 2016 (UTC)[reply]

Antikensammlung/Antiquarium

Es wäre wirklich super, wenn endlich Jeder mal das tut, was er/sie selbst kann und wovon man wirklich Ahnung hat. Dann passiert nicht solcher Unsinn. Was soll denn das alles? Das ist doch mal wieder eine Geschichte aus Absurdistan. Das Antiquarium existiert nicht mehr. Existierte vergleichsweise nur kurz und auch nur Teilselbstständig. Es ist schon ewig in der Antikensammlung aufgegangen. Es hat keinen selbstständigen Eintragswert. Marcus Cyron (talk) 19:13, 5 April 2016 (UTC)[reply]

Ja, dann ist das eben eine VIAF-Nummer, die auf ewig ohne Wikidata-Item bleiben wird. Das ist kein Verteilungsspiel, von dem vorher klar ist, das für alles ein Töpfchen da ist und man es nur finden muss. Sondern es geht darum, nur das zu matchen, was eine weitestgehende Übereinstimmung hat. Das meinte ich mit "aufdröseln": Antiquarium, Antikensammlung, Antikenmuseum, Pergamon-Museum etc. sind in den diversen Normdateien (und mittlerweile auch in VIAF) recht scharf gegeneinander konturiert, insofern gibt es eine realistische Chance, Wikidata-Items etwas passendes zuzuordnen. -- Gymel (talk) 19:37, 5 April 2016 (UTC)[reply]

Schnee-Eifel Q896245 und Schneifel Q896002

Hallo Gymel, nachdem du jetzt die beiden Lemmata geografisch sauber zugeordnet hast, stellt sich für mich die Frage, wo gehört die GND-Nummer 4267498-0 jetzt hin? Zur Zeit ist sie sowohl hier, als auch in den Wikipedia-Artikeln über die Vorlage:Normdaten in beiden Lemata vorhanden. Kann das so bleiben? Grüße, --ACBahn (talk) 04:49, 27 April 2016 (UTC)[reply]

Hallo ACBahn, über die Normdatendopplung bin ich überhaupt auf die beiden gestoßen. Vorher "wusste" ich, dass das dasselbe ist, jetzt bin ich schlauer. Falls es sich nicht um Theoriefindung in der Wikipedia handelt und die Wirklichkeit gar nicht so klar ist, etwa weil 95% derer, die den einen oder den anderen Begriff verwenden, so wie ich gar nicht wissen, dass es den jeweils anderen Begriff auch gibt. Der GND-Datensatz meint bestimmt beides, zumindest in der Praxis, und ich glaube es lohnt nicht, in den als Quelle angegebenen Geo-Duden und Brockhaus 1986 unter dem Stichwort Eifel nachzusehen, ob da evtl. die Mini-Region "Schnee-Eifel" gänzlich unbekannt oder unerwähnt ist (und daher die "Definition" im GND-Satz unbedingt den Gebirgszug meinen muss). Ich halte beides für eine "naturräumliche Einheit", der Gebirgszug "Schneifel" ist klarer konturiert (vielleicht auch "naturräumlicher" als die Region?) und als Begriff viel älter, dafür ist "Schnee-Eifel" räumlich umfassender - eine Pattsituation, zund umindest bis jemand einen Wanderführer schreibt, der beides im Titel hat ("Die schönsten Pfade der Schnee-Eifel, von Prüm zur Schneifel") wird sich da m.E. auch nichts ändern. Ich habe daher für mich entschieden, das als Normdaten-Dublette hier und in de.WP stehen zu lassen. -- Gymel (talk) 06:11, 27 April 2016 (UTC)[reply]

Andreas Bohnenstengel Q19547389

Hallo Gymel, wieso hast du die GND und die Category entfernt? Grüße --Andreas Bohnenstengel 12:55, 24 Mai 2016 (UTC)

Den Link zur Commons-Kategorie hattest Du selber entfernt. Deie GND-Nummer 113895283 steht für einen sogenannten Namenssatz, also alle Andreas Bohnenstengel sämtlicher Epochen und Länder, also insbesondere nicht für die konkrete Person des Wikidata-Items Andreas Bohnenstengel (Q19547389). Ich hatte darüber hinaus aber alle Instanzen von award received (P166) herauslöschen müssen, die dort zu erfassenden Objekte sind naturgemäß Preise und nicht Firmen oder Berufe oder Verbände. -- Gymel (talk) 11:07, 24 May 2016 (UTC)[reply]

Danke für die schnelle Antwort und die vorausgegangene Unterstützung! --Andreas Bohnenstengel 13:25, 24 Mai 2016 (UTC)

范源濂(Q11617140) and Fan Yuanlian (Q21428383)

These two items are referring to the same person. They need to be merged. Zhenqinli (talk) 01:09, 30 May 2016 (UTC)[reply]

Zhenqinli OK. Done. -- Gymel (talk) 04:52, 30 May 2016 (UTC)[reply]

GND für Chachoengsao (Q334906)

Warum hast du denn den GND 4271397-3 aus Chachoengsao wieder rausgenommen? Der ist genauso richtig oder falsch wie 4238121-6 - keiner von beiden sagt explizit daß es um die Provinz geht, ersterer gehört zu einer Region Chachoengsao (die es nicht gibt), letzterer könnte genausogut die Stadt Chachoengsao (Chachoengsao (Q1026368)) meinen. IMHO sollten beide verlinkt sein, allein schon damit bei GND bemerkt wird das die etwas korrigieren müssten. Ahoerstemeier (talk) 12:47, 15 June 2016 (UTC)[reply]

Ahoerstemeier: Das ist der Grund, warum ich selber keinen von beiden hineingesetzt hatte, wobei ich den Unterschied ebenfalls sehe: Das mit "Region" (was immer das sein mag - üblicherweise ja die "Gegend um [die Stadt]", es ist keine administrative Entität, Nutzung für eine Dissertation die eine Umfrage zur Pestizidnutzung im Reisanbau zum Thema hat) ist definitiv nie die "Provinz", aber der unspezifische Satz könnte immerhin die Provinz meinen (d.h. manch einer mag ihn benutzen wenn er die Provinz meint, wobei ja normalerweise der Ersteller des Normsatzes die Bedeutung festlegt, nicht der Nutzer... Deutschlandweit scheint übrigens nur die auch von der DNB zitierte Igel-Dissertation damit verknüpft zu sein, das deutet auf die Intention als "Stadt" hin - "provinzielle" Slums kann ich mir nicht so recht vorstellen). "Die bei der GND" werden allerhöchstens dann etwas bemerken, wenn - so wie wir gerade hier - es akut wird, etwas zur Provinz zu sagen und dann das Rätseln beginnt, ob einer der vorhandenen Sätze die meint oder ein neuer angelegt werden muss. -- Gymel (talk) 13:15, 15 June 2016 (UTC)[reply]

clean of links on Q2962522

Hello Gymel, I noticed you remove some links on the wikidata Q2962522 (book way of perfection). I don't understand why : I get this links from the VIAF web site, so I thinks they are good. Can you explain me shortly how you identify them as wrong ? so we'll avoid to do and revert the same job. Thanks. --FERNANDES Gilbert (talk) 06:42, 25 July 2016 (UTC)[reply]

Hello Gilbert, VIAF just lists authority numbers e.g. from Library of Congress authority ID (P244). But if I klick on such a link and as result get the message from the LoC service that that identifier does not exist I of course take that as more authoritative than the VIAF listing. -- Gymel (talk) 19:39, 25 July 2016 (UTC)[reply]

OBINs

See Wikidata talk:WikiProject DNB#ODNB completeness for an update. The problem you raised has essentially been solved. The dataset still needs some work, and continuing maintenance. Charles Matthews (talk) 05:25, 2 January 2017 (UTC)[reply]

Charles Matthews This is truly great news, especially the part about permanently being able to track completeness! -- Gymel (talk) 18:45, 4 January 2017 (UTC)[reply]

ISNI increase 2018-06-12--18

ISNI (Property:P213) went from ~550 000 (2018-06-12) to ~970 000 (2018-06-18). The unique value constraint violations went up from ~340 to 3300 [28]. They can help to find duplicates. Several have been fixed. Maybe you can update User:Gymel/Duplicates according to VIAF with the July dump, include the VIAF ID and sort by the list by VIAF ID. 92.230.132.107 10:02, 27 June 2018 (UTC)[reply]

Wikidata:Property proposal/Deutsche Biographie person ID 92.230.132.107 10:44, 27 June 2018 (UTC)[reply]

Will do. -- Gymel (talk) 19:10, 27 June 2018 (UTC)[reply]

Did so. The first example is quite illustrative: Probably there never existed a "William Willougby Hooper" (Mix'n'Match addition Willoughby Wallace Hooper (Q52155190) to Wikidata, perhaps by consulting ULAN) but rather Willoughby Wallace Hooper (Q23661890) "Willoughby Wallace Hooper" with same profession and birth/death dates. The ISNI record clearly indicates that the integration of a person with that name was derived from an older VIAF identification, i.e. VIAFs clustering of the ULAN record (this is not a surprise, since the ISNI database was initially constructed from a subset of the VIAF database)... -- Gymel (talk) 19:43, 10 July 2018 (UTC)[reply]

Hallo Thomas, nur zur Info: de:Wikipedia:Bearbeitungsfilter/Anträge#Deutsche-Biographie-Troll. Gleiche Person, gleiches Hobby (ISNI und GND). --Kolja21 (talk) 22:47, 10 July 2018 (UTC)[reply]

User talk:Gymel

Property:P428 (botanist author abbreviation)

Items merge

Property with comment

Straßenschlüssel

naturalist

Property proposal for Place of origin

TLS

consecrator (P1598)

BBF ID (P1650)

Dubletten sammeln?

Ensemble/Band

Property talk:P106

STOP

Linné

Quellen für GND

Jean de Saive

Historische Kommission als Quelle für GND

Qualifikatoren für P227 (GND)

Q7379767 Rundell and Bridge

GND removal

Property documentation

GND removal 2

Deutsche Biographie

fr:Dirigeable Giffard et nl:Dupuy de Lôme-Luchtschip

Bad GND codes found

Merge

GND-Dubletten

wrong VIAF and no VIAF, yet

Alexander Cunningham

Buchführung

Asaf Ali Asghar Fyzee

GND ID (P227) format

Worthwhile checking with user prior to removing specific data

VIAF and ISNI removal

Q218960

Nello Vegezzi

LC Classification

Singular or plural

Lichtenbusch

Revert on Dante Della Terza (Q3702354)

Revertierung meiner Änderungen an Amitav Ghosh (Q336125)

Normdaten, die Zweite

William Stuart = William E.D. Stuart

Oxford Dictionary of National Biography ID (P1415) and CERL Thesaurus ID (P1871)

Historische Kommission

VIAF für Hat Yai (Q475518)

Antikensammlung/Antiquarium

Schnee-Eifel Q896245 und Schneifel Q896002

Andreas Bohnenstengel Q19547389

范源濂(Q11617140) and Fan Yuanlian (Q21428383)

GND für Chachoengsao (Q334906)

clean of links on Q2962522

OBINs

ISNI increase 2018-06-12--18

Navigation menu

Search