Hilfe Diskussion:Personendaten/Archiv/3

Dieses Diskussionsarchiv hat die empfohlene Seitengröße erreicht und gilt damit als abgeschlossen. Sein Inhalt sollte nicht mehr verändert werden (ausgenommen Kleinbearbeitungen wie Link- und Vorlagenfixe). Verwende für die Archivierung von Diskussionsbeiträgen bitte das aktuelle Archiv und benutze bitte für aktuelle Diskussionen die aktuelle Diskussionsseite. Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise [[Hilfe Diskussion:Personendaten/Archiv/3#Abschnittsüberschrift]] oder als Weblink zur Verlinkung außerhalb der Wikipedia https://de.wiki.x.io/wiki/Hilfe_Diskussion:Personendaten/Archiv/3#Abschnittsüberschrift

Sprachkennzeichnung in Alternativnamen

Vermutlich ist

• Personendaten|NAME=Wolkow, Fjodor Kondratjewitsch|ALTERNATIVNAMEN=Волков, Фёдор Кондратьевич (russisch); Вовк, Федір Кіндратович (ukrainisch)

erwünscht, und nicht

• Personendaten|NAME=Wolkow, Fjodor Kondratjewitsch|ALTERNATIVNAMEN=\{\{lang|ru|Волков, Фёдор Кондратьевич\}\}; \{\{lang|uk|Вовк, Федір Кіндратович\}\}

- oder doch nicht? Ein entsprechendes Beispiel mit nicht-lateinischer Schrift auf Hilfe:Personendaten könnte das ohne lange Erläuterungen klarstellen. --Griot 02:35, 25. Jan. 2008 (CET)

Nein. Standardmäßig wird in der deutschen Wikipedia der HTML-Code mit dem Tag language="de" geparst. Korrekter HTML-code ist {{lang|ru|Волков, Фёдор Кондратьевич}}, die Verwendung von Фёдор Кондратьевич ohne Vorlage erzeugt einen nicht den HTML-Konventionen entsprechenden Code und führt zu fehlerhaften Suchergebnissen, etwa bei Google. --Matthiasb 10:15, 25. Jan. 2008 (CET)

Ok. Ergibt aber die nächste Frage: Die Sprache ist dann im Eintrag zwar kodiert, jedoch unsichtbar (ausser im Quelltext). Soll also "(russisch)" als sichtbare Erläuterung hinzugefügt werden - wie es im Magellan-Beispiel gemacht wird? --Griot 10:46, 25. Jan. 2008 (CET)

Welche Felder verlinken?

Vielleicht könnte man in der Hilfe einmal klar darstellen, welche Felder verlinkt werden sollen und welche nicht, denn immer wieder sind Putzbrigaden unterwegs, die entweder alles ver- oder alles entlinken. Mir selbst ist es auch nicht klar, was gewollt ist. --K@rl 15:07, 27. Jan. 2008 (CET)

Geburtsort und Sterbeort sollten genau verlinkt sein. Beim Rest spielt es keine Rolle. Den Artikel extra wegen Ver- oder Entlinkung in den Personendaten zu bearbeiten (die sowieso kaum jemand sieht) ist Hamsterquälerei. --Ephraim33 15:42, 27. Jan. 2008 (CET)

da sind leider manche große Hamstersadisten ;-) --K@rl 20:22, 28. Jan. 2008 (CET)

Es ist zwar eine Quälerei aber auch eine Datenveredelung! -- sk 20:30, 28. Jan. 2008 (CET)

ungenauen Geburts-/Sterbeort verlinken?

Wenn der Geburts-/Sterbeort nicht bekannt ist, sondern nur z.B. 'Gouvernement Twersk', oder gar nur 'Russland', sollte dies dann verlinkt werden? Also immer der genaueste bekannte Teil? Evtl. nur, wenn er eine gewisse Größe nicht übersteigt? --Griot 02:35, 25. Jan. 2008 (CET)

Hallo Griot, ich wollte gerade dazu aufrufen, ähnlich wie bei den Geburts- und Sterbedatum eine Standardisierung mit klaren Regeln auszuarbeiten. Wir haben derzeit sehr großes Durcheinander bei den Orten. Wenn man Allein mal nach Berlin und seinen Stadtteilen sucht dann gibt es zahlreiche Schreibweisen. Ich würde darum folgendes vorschlagen.

1.) Wenn der Ort/-steil einen Artikel hat in der Wikipedia, dann wird nur der Ort eintragen. Kein Land, Keine Provinz, kein Kreis oder Kanton; Artikel sollte aber keine Begriffsklärung sein. Beispiel:Berlin-Steglitz

2.) Wenn genauerer Ortsangaben vorliegen, dann werden diese nach dem Ort angegeben. Wenn es einen eigenen Artikel gibt, dann muss dieser auch verlinkt werden Beispiel: Berlin-Steglitz, Burg Hartenstein

3.) weitere Reglungen für unbekannte Orte und sonstige Fälle (verschollen im Atlantik etc.)

Andere Meinungen? -- sk 20:16, 26. Jan. 2008 (CET)

Ich finde den Vorschlag, genauere Angaben nach dem Ortsnamen anzugeben, etwas merkwürdig. Widerspricht doch der normalen Reihenfolge. — ThomasO. 00:43, 27. Jan. 2008 (CET)

(Parallel zur Antwort von ThomasO. entstanden:)

Hallo sk, entscheidend muss natürlich die beabsichtigte Verwendung der Personendaten sein, die mir nicht ausreichend bekannt ist. Deshalb kann ich nur intuitiv antworten.

a) zu 1.) Ist es sinnvoll, Ortsteile wie Berlin-Steglitz hier anzugeben, auch zu verlinken? Nicht doch nur Orte, also Berlin? Ohne Kenntnis der beabsichtigten Verwendung weiß ich es nicht.

b) noch zu 1.) Land/Provinz etc. nicht anzugeben, scheint für heutige Orte in Deutschland in der deutschen Wikipedia vernünftig. Aber wohl eher nicht für ausländische Orte - wer überschaut schon, wo es überall Orte eines gewissen Namens gibt? Wenn man (ausser bei Namen, die 'jeder Deutschsprachige' [was das auch immer heissen mag] mit einem festen Ort verbindet - wie Madrid, schon bei Sevilla kommen Zweifel auf -) ausländischen Orten im Regelfall wenigstens die Angabe einer territorialen Einheit hinzufügt, können durch spätere Erweiterungen entstehende Mehrdeutigkeiten erkannt und wohl sogar (halb-?)automatisch beseitigt werden. Ähnliches gilt für historische Orte: Ich hielte "Cölln, Brandenburg" für besser als nur "Cölln".

c) immer noch zu 1.) Ob ein Ort einen Eintrag in der Wikipedia hat, sollte keine Rolle spielen, diese Eigenschaft ist nicht dauerhaft genug.

d) zu 2.) Der Wunsch, genauere Angaben, als den Ort aufzunehmen, besteht offenbar. Da gröbere Angaben als der Ort aber wohl doch mindestens manchmal nötig sind, entsteht das Problem, möglichst automatisch entscheidbar zwischen beiden Angaben unterscheiden zu können. Wie wäre es mit folgender Form:

Kiez, Stadtbezirk, Ort, Kreis, Land, ...

also fortlaufend aufsteigend, wobei die Ausführlichkeit dem Schreiber überlassen wird (keine unnötig starren Regeln). Den 'Kern-'ort müsste man dann wohl irgendwie als solchen kenntlich machen - dies erfolgt hier durch seine Verlinkung. Das ist aber ein schwacher Punkt dieses Vorschlags. Sollte jetzt oder irgendwann später entschieden werden, alle Bestandteile zu verlinken, ginge die Markierung als 'Kern-'ort verloren... Eine Markierung etwa durch ein Semikolon nach dem Ort wäre ungewohnt, würde leicht vergessen werden. Eine Alternative könnte sein

Kiez, Stadtbezirk, Ort (Kreis, Land, ...)

da die Klammerangabe ja durchaus üblich ist. Einige Beispiele zur zweiten Form wären:

Cölln, Meissen (Sachsen) oder gleichberechtigt Cölln, Meissen
Cölln (Brandenburg)
Borowitschi (Gouvernement Nowgorod)

und, wenn ich die von mir in der ursprünglichen Frage angedeutete Antwort als gültig annehme:

Rayon Pirjatinsk (Oblast Poltawa, Ukraine)
oder konsequenter
(Rayon Pirjatinsk, Oblast Poltawa, Ukraine)

e) zu 3.), also den komplizierteren Fällen - "verschollen im Atlantik", "bei Odessa" (bei mir gerade) - wäre wohl eine Sichtung der vorkommenden Fälle ein erster Schritt. Eine Entscheidung zu den 'einfachen' Fällen scheint aber relativ unabhängig hiervon zu sein, so dass sie bereits vor einer Entscheidung zu den komplizierteren Fällen erfolgen könnte.

f) Bei der Auswahl von Beispielen stieß ich gleich auf die nächste Frage - eigentlich unabhängig von dieser: Wie wichtig ist bei den Personendaten die Lesbarkeit für den Menschen? Konkreter Fall: sollte [[Perm (Stadt)|Perm]] oder [[Perm (Stadt)]] geschrieben werden? --Griot 02:31, 27. Jan. 2008 (CET)

Danke für die ersten Antworten. Also grundsätzlich sind die Personendaten ja entstanden für die Erstellung der DVD. Das heißt ihre Hauptfunktion ist auch heute noch die Maschinenlesbarkeit. Davon sollte die zukünftige Regelung abhängig sein. Es kann nicht sein, dass wir z.B. für Chemnitz X verschiedene Schreibweisen haben.

• Chemnitz
• Chemnitz, Deutschland
• Karl-Marx-Stadt
• Karl-Marx-Stadt, Sachsen
• Chemnitz, ehemals Karl-Marx-Stadt
• Karl-Marx-Stadt, heute: Chemnitz
• Chemnitz, ehemals: Karl-Marx-Stadt

Deshalb möchte ich hier mal eine Tabelle anfangen, die ihr bitte einfach ergänzt, oder verbessert. Dann sehen wir ja was am Ende raus kommt. --sk 11:01, 27. Jan. 2008 (CET)

falsch	richtig	Grund
Cölln	Cölln	Verlinkung erzeugt eindeutige Zuordnung;
[[Perm (Stadt)|Perm]]	[[Perm (Stadt)]]	Eingabe ist performanter von Maschinen lesbar
Buda, heute Budapest Augusta Treverorum, heute Trier	Buda Augusta Treverorum	Sobald ein Artikel der original Geburtstadt vorhanden ist, sollte er in den Personendaten verlinkt werden
Brückenstraße 10, Trier Trier	Trier, Brückenstraße 10	genauer Geburtsort von Karl Marx ist bekannt, kann also eingetragen werden; Wissen soll ja nicht unterschlagen werden. Da erst Ort und dann feinere Zuordnung ist das ganze auch einfach auswertbar für Computer
Chemnitz Chemnitz, Deutschland Karl-Marx-Stadt Karl-Marx-Stadt, Sachsen Chemnitz, ehemals Karl-Marx-Stadt Karl-Marx-Stadt, heute: Chemnitz Chemnitz, ehemals: Karl-Marx-Stadt	Chemnitz	immer neuste Ortsbezeichnung benutzen, wer alte Bezeichnung braucht, findet diese dann im Ortsartikel selber; Vorteil: Maschinell lassen sich eindeutige Zuordnungen leichter herstellen (z.B: Wer ist alles in Chemnitz geboren und gestorben?), als wenn tausend unterschiedliche Schreibweisen benutzt werden.
verschollen im Atlantik (?)	wie besser ?	Bsp: Amelia Earhart
Fluss Saleph (heute Göksu), nahe Seleucia	wie besser ?	Bsp:Friedrich I. (HRR)

warum Karl-Marx-Stadt nicht mittels [[Chemnitz|Karl-Marx-Stadt]] - sollte man die PD bspw. irgendwann mal nutzen um etwas daraus etwas anzuzeigendes zu genieren wäre schon der damals gültige name der bessere weg und mit einer stupiden vereinheitlichung auf Chemnitz schwierig ...Sicherlich ^Post 13:24, 27. Jan. 2008 (CET)

Hm, ich find das nicht so gut. Es gibt zwei Aspekte der Orte in den Personendaten: einmal der korrekt anzuzeigende Ort (maschinenlesbar) und zum zweiten der Link zum korrekten Ort (natürlich auch maschinenlesbar). Unsere Verlinkung leistet ja genau das. Da auf deine Art und Weise zwar schön immer der korrekte Ort erkannt werden kann, sind ein Teil der Auswertungen gut möglich. Ich stelle mir eine Seite vor, die für sämtliche Personen eine Datenbankseite hat und ein Klick auf den Geburtsort zeigt sämtliche Personen, die dort geboren wurden. Daher ist es sinnvoll, alle Personen auf Chemnitz zu verlinken, wie du das auch vorschlägst. Aber die Seite soll ja auch den Geburtsort anzeigen. Da kann aber nicht immer Chemnitz stehen, genausowenig wie da "Perm (Stadt)" stehen sollte. Daher mein Vorschlag: immer das Format [[Link auf korrekten Artikel heutiger Schreibweise|Anzuzeigender Name in korrekter damaliger Schreibweise]]. Schwerer zu Parsen ist das wirklich nicht - wenn jemand doch nur den Link will, dann sucht er halt nach nem "|" nach "[[" statt nach "]]" nach "[[". Sollte keinen Unterschied machen.

Die zweite Sache ist die, welche Gliederungsebenen wir mit angeben. Da sollte ein Parser auf jeden Fall alles nach dem ersten Link (der oben genannten Form) ignorieren, es ist also nicht nötig, wenn aber hinter Chemnitz noch ", Deutschland" steht, dann schadet das nicht. Sonst müssten wir zu viele Artikel nachbearbeiten. --APPER\^☺☹ 14:39, 27. Jan. 2008 (CET)

Prinzipiell reicht doch wohl genau eine, möglichst genaue, verlinkte Angabe aus, um den Ort zu identifizieren. Alles andere ergibt sich durch den Link. Wozu sollte da noch sonstiges - wie z.B. das Land - stehen, das macht doch nur zusätzliche Arbeit. — ThomasO. 16:43, 28. Jan. 2008 (CET)

Korrekt ThomasO. Ein einziger verlinkter Ort reicht völlig aus. Alles andere kann man aus dem Ortsartikel herauslesen. Weshalb ich hier die Erstellung eines Standards fordere, lässt sich an der folgenden Liste sehr gut sehen. Dort sind mal alle Geburts- und Sterbeorte mit Karl-Marx-Stadt und Chemnitz nach Häufigkeit aufgelistet, so wie sie derzeit bei den Personendaten im letzten Dump verfügbar waren. Dieses Chaos kann ich beim besten Willen nur sehr schwer mit einem Parser maschinell alle zur Stadt Chemnitz zusammenführen. Mir fällt kein vernünftiger und sauberer Ansatz ein. Deshalb sollten Regeln erstellt werden, nach denen wir vorgehen! -- sk 19:30, 28. Jan. 2008 (CET)

• 174 Chemnitz
• 28 Chemnitz
• 17 Karl-Marx-Stadt
• 16 Karl-Marx-Stadt
• 8 Chemnitz in Sachsen
• 6 Karl-Marx-Stadt
• 3 Chemnitz, Sachsen
• 2 Karl-Marx-Stadt, DDR
• 2 Karl-Marx-Stadt, Sachsen
• 2 Karl-Marx-Stadt, Sachsen, DDR/Deutschland
• 2 Chemnitz, Sachsen
• 2 Chemnitz, Deutschland
• 1 Schönau/Chemnitz
• 1 Einsiedel
• 1 Chemnitz-Siegmar, Sachsen
• 1 Oberhermersdorf, heute Chemnitz-Adelsberg
• 1 Karl-Marx-Stadt (Chemnitz)
• 1 bei Chemnitz
• 1 Lichtenwalde/Chemnitz
• 1 Karl-Marx-Stadt, heute Chemnitz
• 1 Karl-Marx-Stadt, heute Chemnitz
• 1 Harthau
• 1 Chemnitz, Deutschland
• 1 Lunzenau bei Chemnitz
• 1 Schloßchemnitz)
• 1 Altenhain bei Chemnitz
• 1 Karl-Marx-Stadt, Sachsen
• 1 Markersdorf bei Chemnitz
• 1 Hartmannsdorf (bei Chemnitz)
• 1 Chemnitz,
• 1 Röhrsdorf bei Chemnitz
• 1 Wittgensdorf bei Chemnitz
• 1 Oberlichtenau, Chemnitz
• 1 Garnsdorf bei Chemnitz
• 1 Lugau bei Chemnitz
• 1 Erdmannsdorf bei Chemnitz
• 1 Chemnitz-Rabenstein
• 1 Chemnitz/Sachsen
• 1 Chemnitz-Rabenstein
• 1 Chemnitz in Sachsen/Deutschland
• 1 Altenhain
• 1 Rabenstein bei Chemnitz
• 1 Karl-Marx-Stadt, DDR
• 1 Adelsberg bei Chemnitz
• 1 Reichenbrand bei Chemnitz
• 1 Karl-Marx-Stadt, Sachsen, DDR
• 1 in Chemnitz
• 1 Chemnitz, Kurfürstentum Sachsen
• 1 Karl-Marx-Stadt, Deutschland
• 1 Rottluff bei Chemnitz
• 1 Chemnitz, Sachsen, Deutschland
• 1 Karl-Marx-Stadt (heute Chemnitz)
• 1 Chemnitz-Siegmar
• 1 Karl-Marx-Stadt (Chemnitz), Sachsen
• 1 Oberauerswalde in der Nähe von Chemnitz (Sachsen)
• 1 Einsiedel, Sachsen (heute zu Chemnitz)
• 1 Claußnitz bei Chemnitz
• 1 Hilbersdorf bei Chemnitz

Hallo sk und andere hier Diskutierende, bevor ich mich in den Urlaub abmelde, noch einmal mein (Griot) 'Senf' dazu. (Vielleicht sollte aber der Abschnitt - ohne meinen ersten fragenden Absatz - eine neue Überschrift bekommen? Ich kenn die Regeln noch nicht ausreichend, trau mich daher nicht.)

Dein (sk) Vorhaben, hier größere Einheitlichkeit zu erzielen, halte ich für höchst verdienstvoll. Die Chemnitz-Liste zeigt, wie notwendig dies ist. Ebenso nützlich ist eine Tabelle, wie Du sie oben angefangen hast. Es zeigt sich jedoch bereits, dass über viele Details noch keine Einmütigkeit besteht, in einer solchen Tabelle muss aber die exakte Form angegeben werden - es ist daher noch sehr schwierig, dort etwas einzutragen. Ich schlage vor, die Tabelle zunächst zurückzustellen, auf sie zurückzukommen, sobald (hoffentlich) eine Einigkeit zu einigen Grundfragen erzielt ist.

Um eine solche Einigung zu erreichen, kann die Diskussion vielleicht in Einzelfragen gegliedert werden? Nummerierung der Argumente hilft eventuell, sich bei Kritik oder Zustimmung besser darauf beziehen zu können. Also los, beginnend beim Urschleim. (Pardon, wenn's pedantisch und ermüdend wird, ...) Ich bitte zu berücksichtigen, dass die folgenden Einzelantworten großenteils voneinander unabhängig sind. Also bitte nicht ab einer Position, die nicht geteilt wird, alles weitere verwerfen...

(A) Regeln für die Ortsangaben im Feld Geburts-/Sterbeort sind dringend zu erarbeiten. Begründung: siehe von sk gegebene Argumente.

(B2a) Ein Parser für regelgemäße Angaben muss mit vertretbarem Aufwand programmierbar sein. Begründung: klar, oder?

(B2b) Die Einfachheit des Parsers ist jedoch nicht primäres Ziel. Wenn gute Gründe für eine etwas kompliziertere Form der Angaben vorliegen, darf diese gewählt werden (solange (B2a) erreichbar bleibt). Begründung: Zu viel Gewicht auf die Einfachheit des Parsers zu legen, schränkt die Möglichkeiten allzusehr ein. Beispiel: oben die Argumentation von APPER für [[Perm (Stadt)|Perm]].

(B3) Die Regeln sollten möglichst intuitiv sein, nicht unnötig von der den Nutzern gewohnten Form abweichen, so dass sie sich gut merken lassen. Begründung: Konsens, hoffe ich?

(B4) Die Regeln sollten nicht unnötig von den bisher verwendeten Formen abweichen. Eine Abweichung ist jedoch zulässig, wenn andere wichtige Ziele sonst wohl nicht zu erreichen sind. Begründung: Dies ist vermutlich kontrovers. Es könnte dazu führen, dass relativ viele Einträge zu überarbeiten sind. Da jedoch

• ohnehin viel zu überarbeiten ist - s. oben 'Chemnitz'
• eine Überarbeitung nicht notwendig durch eine Putzaktion erfolgen muss - sie kann auch durch 'Änderung nebenbei' innerhalb eines längeren Zeitraums erfolgen
• eine Abweichung wirklich nur aus sehr gutem Grund erfolgen sollte

vor allem aber, um einer zu früh agierenden 'Schere im Kopf' zu begegnen, scheint mir diese Herangehensweise angebracht. (Und es ist ja noch gar nicht ausgemacht, ob von dieser Freiheit letzlich Gebrauch gemacht wird.)

(B5) Die Regeln sollten den Nutzer nicht unnötig einschränken, nicht starrer sein, als unbedingt nötig. Begründung: Zu starre Regeln werden ohnehin ignoriert. Eine Beschränkung sollte sich plausibel erklären lassen.

---

Jetzt zur Frage des Inhalts der Felder. Dabei scheint es mir sinnvoll, sich zunächst(!) auf die relativ einfachen Fälle zu beschränken, erst nach deren Klärung Fälle wie 'verschollen im Atlantik' einzubeziehen. Unter einem 'relativ einfachen Fall' verstehe ich hier die Angabe eines Ortes, dessen heutige und eventuell frühere Bezeichnung und territoriale Einordnung vollständig bekannt ist.

Ich verwende im weiteren die Worte 'dürfen' und 'zulässig' im Sinne von 'ist regelgerecht', 'muss von einem vollständigen Parser beherrscht werden'. Es kann durchaus sein, dass in diesem Sinne zulässige Formen nicht als 'erwünscht' gelten. Eine Diskussion über 'erwünschte' Formen schiene mir verfrüht zu sein.

(C1) Die Angabe enthält den Ortsnamen. Begründung: fällt mir grad keine ein... (Pardon für Pedanterie.)

(C2) Die Angabe darf genauere Angaben enthalten. Begründung: s. oben sk's Tabelle: Grund für 'Brückenstraße 10, Trier'

(C3) Die Angabe darf weniger genaue Angaben (umfassende territoriale Einheiten) enthalten. Begründung: Dies ist für deutsche Orte nicht so zwingend. Aber die zulässigen Formen müssen ja ausländische Orte ebenso gestatten. Auf die Existenz eines Artikels für den Ort kann hier nicht vertraut werden - es ist nicht zu erwarten (wohl nicht einmal wünschenswert), dass die deutsche Wikipedia einmal Artikel zu allen in Frage kommenden Orten der Welt enthält. Ein Beispiel, wenn (C3) NICHT akzeptiert wird (mit dem erfundenen Ortsnamen 'Plonk'):

• Nutzer Ax erzeugt den Artikel über "A B", geboren in Plonk (Schweden). Ergebnis: Geburtsort=[[Plonk]].
• Nutzer Ex erzeugt den Artikel über "U V", geboren in Plonk (Portugal). Ergebnis: Geburtsort=[[Plonk]].

etc. Es wäre extrem schwierig, diese Plonks später wieder zu trennen. Deshalb sollte 'Schweden'/'Portugal', etc. in der Angabe zum Geburtsort mit erscheinen.

(C4) Eine Ortsangabe darf sowohl genauere Angaben gemäß (C2), als auch weniger genauere Angaben gemäß (C3) enthalten. Begründung(schwach): zugegeben, ich habe im Moment kein gutes Beispiel. Eine andere Regelung erschiene mir aber kontra-intuitiv. (In obiger Chemnitz-Liste kommt's vor, z.B. Chemnitz-Siegmar, Sachsen.)

(D1) Der reine Ortsname muss leicht - sogar von einem einfachen Parser - von den anderen Angaben zu trennen sein. Begründung: Dies ist sicher die am häufigsten zu extrahierende Information.

(D2) Die genaueren Angaben (C2) und die ungenaueren (C3) sollten als solche automatisch erkennbar sein. Begründung: Auch wenn das zur Zeit noch nicht genutzt wird - es erscheint mir sinnvoll, um nicht spätere, noch nicht bekannte Verwendungsmöglichkeiten der Ortsinformation unnötig zu be-/verhindern.

(E1) Die Angabe eines konkreten Ortes in möglichst einheitlicher Form sollte gefördert werden. Begründung: Die Pflege und Nutzung der Ortsangaben wird einfacher. Anmerkung: Die einheitliche Form sollte 'gefördert', nicht erzwungen werden. Möglichst so, dass eine empfohlene, den Nutzern nicht unvertraute Form der Angabe von selbst Einheitlichkeit erzeugt. (S. auch (E2).)

(E2) Die Form der Angaben sollte Änderungen der übrigen Wikipedia gegenüber - speziell der Hinzufügung von Artikeln - möglichst stabil bleiben. Begründung: Völlige Stabilität ist nicht zu erreichen. Wenn ein Ortsartikel verschoben wird (wie das möglicherweise einmal mit 'Perm' -> 'Perm (Stadt)' geschehen sein könnte), ist Anpassung nötig. Wenn aber z.B. im obigen Plonk-Beispiel ein Artikel für das 'Plonk' in Schweden aufgenommen wird, so braucht eine Ortsangabe wie z.B. 'Plonk (Schweden)' nicht geändert zu werden. Danach wäre natürlich ein '[[Plonk]]' ausreichend, aber gerade um Ziel (E1) zu erreichen, wäre es besser, immer noch '[[Plonk]] (Schweden)' zu schreiben.

(E3) Wenn möglich, sollte das Mittel, (D1) und (D2) zu erreichen, nicht davon abhängig gemacht werden, welche Teile der Ortsangabe verlinkt werden. Begründung: Die vielen Diskussionen um die Verlinkung (auch anderer Teile) interpretiere ich als noch bestehende starke Unsicherheit diesbezüglich. Es wäre daher unvorsichtig, sich hier an den momentanen Stand zu binden. das könnte sehr schnell dazu führen, dass man entweder viel überarbeiten muss, oder sagen muss "zu spät, kann nicht mehr geändert werden, der Aufwand wäre zu groß".

(F1) Bei Namenswechsel ist 'X, heute Y' besser als 'Y, ehemals X'. Begründung: 'Y, ehemals X' versagt bei den häufigen Eingemeindungen - etwa wäre 'Berlin, ehemals Pankow' sehr ungewöhnlich, dagegen 'Pankow (Brandenburg), heute zu Berlin' akzeptabel. (Ok, ich habe ein 'zu' eingeschmuggelt, aber wie würde man das in der ehemals-Formulierung machen?) Wichtiger: wer eine Ortsangabe findet und einträgt, wird in vielen Fällen gar nicht wissen, dass der Ort inzwischen anders heißt. Das kann später, evtl. sogar automatisch nachgetragen werden. Wenn zunächst eine 'feinere' Information vorhanden ist, kann eine 'gröbere' abgeleitet werden - leichter jedenfalls, als umgekehrt.

Uff, tut mir leid, dass es so lang wurde. Und trotzdem noch nicht bis auf Details einging. Ich bin gespannt, was ich nach dem Urlaub vorfinde. --Griot 12:10, 29. Jan. 2008 (CET)

Datenveredelung durch strengere Regeln

Ich will mal hier eine kleine Diskussion in Gang bringen. Ich bin dafür, dass wir die Einträge in den Personendaten wesentlich strengeren Regeln unterwerfen. Gedacht waren die Datenfelder mal für die Wikipedia-CD und erfüllen diesen Zweck auch recht gut. Aber auf Grund der teilweise miesen Qualität lassen sich maschinelle Auswertungen nur schwierig durchführen. Schon allein die Abfrage nach allen Personen die in einem Ort geboren wurden bringt nur ein Bruchteil der möglichen Ergebnise, weil es für die Ortsangaben keine genormte Formatierung gibt. Anbei mal ein erster Ansatz für strengere Regeln. -- sk 19:29, 19. Feb. 2008 (CET)

Ich verstehe dein Anliegen, bin mir aber ziemlich sicher, dass es nicht erfolgreich sein wird. Wir haben über 100.000 Personenartikel und ständig kommen mehr dazu, die sowohl umgestellt als auch überwacht werden müssten. Ich bin mir auch nicht sicher, dass es wirklich notwendig ist, redundant Daten vorzuhalten. So ist die Nationalität bereits über die Kategorien gegeben, genauso wie der Beruf. Warum muss das nochmal in den Personendaten eingearbeitet sein? Wenn der Name mit dem Artikel identisch sein muss, warum dann nicht gleich den Artikelnamen verwenden? Den Sortiernamen findet man über DEFAULTSORT oder die Angabe in der Kategorisierung auch heraus. Ich denke einfach, dass das erfolgreichste Modell eins sein wird, dass sich den Gewohnheiten der Wikipedianer anpasst anstatt zu erwarten, dass die Wikipedianer ihre Gewohnheiten anpassen. sebmol ^{? !} 19:40, 19. Feb. 2008 (CET)

Gerade für die Überwachung hab ich ja die Fehlerliste erstellt. Nur bringt es nichts wenn ich sie alleine abarbeite und die große Masse den Sinn nicht sieht. Deshalb möchte ich die Regeln auf der PD-Seite klar definieren, damit jeder der möchte sich daran halten kann und jeder der sie für notwendig erachtet in Zukunft umsetzen kann. Eine Umstellung mit einem Bot oder so sehe ich nicht so sinnvoll, aber gegen eine schleichende Verbesserung wird niemand etwas haben. Nur dazu müssen wir irgendwann mal entsprechende Qualitätsmerkmale bzw. Richtlinien setzen. -- sk 20:06, 19. Feb. 2008 (CET)

Allgemeines

• Alle Datenfelder müssen in der Vorlage enthalten sein, auch wenn leer!
• Verlinkung ist nur bei Ortsangaben zulässig

Namen

• Name muss identisch sein mit Artikelname, nur in richtiger Sortierreihenfolge. (Andere Schreibweisen gehören in die Alternativnamen)

Alternativnamen:

• Keine Verlinkung erlaubt
• Es dürfen keine Vorlagen für Sprachen benutzt werden
• Es muss immer mit einem Semikolon getrennt werden
• Format: Sprachadjektiv: Nachname, Vorname (Anmerkung)
• Bsp.:
  • dänisch: Krug, Ute (Künstlername); russisch: Krugiulla (deutsch Polkakönigin)
  • jamaikanisch: Reggyman (Pseudonym); ukrainisch: Uischalyr (Geburtsname)

Kurzbeschreibung:

• Nationalität immer in Adjektiv dem Beruf vorangestellt in sch-Form (deutscher, dänisch, US-amerikanisch, schweizerisch/Schweizer, britisch, ...)
• Keine Konfession vor dem Beruf
• Keine Verlinkung erlaubt
• Format: Nationalität Beruf (Zusatz), Anmerkungen
• Bsp.:
  • nicht katholischer Papst sondern: deutscher Geistlicher (katholisch), Papst (seit 2003)
  • nicht Prinz von Transitia sondern: ungarisch-US-amerikanischer Adliger, Prinz von Transitia
  • nicht Entdecker der Unendlichkeit sondern: deutscher Mathematiker, Entdecker der Unendlichkeit
  • nicht republikanischer US-Politiker sondern: US-amerikanischer Politiker (Republikaner)
  • nicht Herrscher von Byzanz sondern: byzantinischer Herrscher

Geburts und Sterbeort

• Hier ist ein Link auf den Ortsartikel erlaubt
• Hinweis auf Begrabungsstätte ist nicht erlaubt (z.B. Wien, Zentralfriedhof), da die Person in den seltensten Fällen auf dem Friedhof direkt verstorben ist
• Wenn Ortsartikel in der deutschsprachigen Wikipedia, dann nur verlinkten Ort eintragen
• nicht: New York sondern: New York City
• nicht: Dresden, Königreich Sachsen sondern: Dresden
• nicht: Dresden, Washington County, USA sondern: Dresden (Washington County)
• nicht: Tananarive, heute Antananarivo sondern: Antananarivo, damals Tananarive

Geburts- und Sterbedatum

• keine Jahrhunderte erlaubt (im 5. Jahrhundert)
• Verlinkung nicht erlaubt

an eine "schleichende Verbesserung" glaubst du sk doch wohl selber nicht? schon heute habe ich ständig artikel in meiner beobachtungsliste wo nur in den PDs etwas ver- oder entlinkt wird, ein wort ausgeschrieben oder verkürzt oder sonstige inhaltslose bearbeitungen getätigt werden. Im Moment haben die PDs ja wohl nicht wirklich einen nutzen außer für ein paar weniger die hier und da mit den daten spielen. Dafür jetzt auch nocht neue "regeln" einzuführen halte ich für ziemlich überflüssig. Ggf. müssen halt die auswertungsprogrämmchen verbessert werden. ...Sicherlich ^Post 21:38, 19. Feb. 2008 (CET)

Ich sehe das nicht als neue Regeln, sondern nur als Präzisierung der bestehenden an und finde sie in sich schlüssig, auch wenn "New York City" im Deutschen (siehe Duden) immer noch New York heißt, aber das ist ein Fehler der Autoren des entsprechenden Beitrags. --Kolja21 22:36, 19. Feb. 2008 (CET)

Doch ich glaube an eine schleichende Verbesserung. Das ist ja gerade das Prinzip der Wikipedia. Und das hier nur sehr wenige mit den Daten rumspielen, obwohl sie Gold wert sind, hängt nach meiner Einschätzung mit der schwierigen automatisierten Auswertung zusammen. Wenn dagegen jedes Datenfeld nach klaren Regeln bestückt wird, dann lassen sich diese Regeln auch problemlos in eine Software gießen. Das derzeitige recht regellose Sammelsurium von Daten geht aber einfach mit heutiger Technik nicht wirklich effektiv auszuwerten. Ich bin deshalb für die, Zitat Kolja: "Präzisierung der bestehenden" Regeln. Nicht mehr und nicht weniger. -- sk 22:50, 19. Feb. 2008 (CET)

es sind neue regeln; etwas das zuvor nicht geregelt war mit regeln auszustatten ist die einführung einer neuen regel; was denn sonst? ... bzgl. der links ist es lustig. bis anfang des jahres waren wikilinks noch okay, jetzt sind sie böse. ... ich bin zu faul nachzugucken aber vermutlich wurden dieser text mal eingeführt weil damit zukünftig alles besser wird. Neue regeln einzuführen ohne überhaupt über "spielereien" Weniger hinausgehende anwendungen für die PD zu haben ist ziemlich unsinnig. Die PD wurden für die CD eingeführt. Dort werden sie nicht mehr genutzt aber sie werden weitergepflegt weil?! - wir das schon immer so gemacht haben; wenn die bearbeitungen und "korrekturen" dieser PDs nicht in der beobachtungsliste nerven würden könnte ich das ganze als lustig bezeichnen. So ist es nervig ..Sicherlich ^Post 22:51, 19. Feb. 2008 (CET)

Ich denke auch eher, dass die vielen Freiheiten/Unklarheiten die Ursache der vielen Fehler sind. Insofern fände ich es durchaus sinnvoll, die Regeln zu verschärfen. Immerhin sind die PD ja ein Datensatz und kein gestaltbarer Artikelteil. Das ist auch das Problem bei den vielen Einzeldaten, die in einem Artikel mit seinen vielen Freiheiten nur schwer zusammengesucht werden können und wo das noch viel fehleranfälliger ist. Dafür sind die PD (meinetwegen auch zukünftig) gut. Ich denke, einen Versuch ist es mal wert. Es geht ja auch nicht darum, dass jetzt plötzlich alles richtig wird, sondern darum, ein paar Prozent Verbesserung herauszuholen.

Frage: Dresden, Washington County, USA - oder - Dresden (Washington County), USA ?

oder anders: ist nur der Link auf den richtigen Artikel wichtig oder auch die spätere Darstellung? -- Harro von Wuff 22:55, 19. Feb. 2008 (CET)

Bei Freitextfeldern ist das aber generell problematisch. Soweit möglich sollte man die Kategorien nutzen, z.B. für die Nationalität. Welchen Sinn hat es, die zusätzlich in der Kurzbeschreibung zu erzwingen? --08-15 23:13, 19. Feb. 2008 (CET)

Weißt du, wieviele Möglichkeiten es bei Kategorien dafür gibt? Deutscher, Maler (Deutschland) - aber nicht Politiker (Deutschland)!-, Deutscher Architekt und bei doppelten Staatsbürgerschaften noch jede Menge Kombinationen. Dazu kommt unterschiedliche Handhabung bei mehreren Berufen. Wobei es ohnehin noch viele Ungereimtheiten bei der Kategorisierung gibt, über die schon ein Mensch stolpert und erst recht ein Programm. Die Auswertung dürfte eine komplizierte Angelegenheit werden. Und die Fehlerquote sehr hoch. Gerade da sind die PD viel praktischer. -- Harro von Wuff 23:51, 19. Feb. 2008 (CET)

Einige der Präzisierungen finde ich sinnvoll, andere nicht, andere sollten in anderer Form präzisiert werden. Ich will daher anregen, die neuen Regeln einzeln zu diskutieren. Gut finde ich z.B., dass immer alle Datenfelder vorhanden sein sollen (auch wenn leer) und keine Sprachvorlagen oder sowas enthalten sein sollten. Das betrifft auch wenige Artikel bisher. Dass keine Wikilinks in Geburtsdatum oder Kurzbeschreibung nötig sind ist jetzt schon so, sie zu verbieten halte ich für übertrieben - das ist für eine Auswertung nicht wichtig, sowas lässt sich durch das Auswertungstool machen. Und zu den Orten: Da haben wir schonmal diskutiert, und "New York City" geht einfach nicht, da komplett die deutsche, korrekt anzuzeigende Schreibung verloren geht, daher immer "New York" bzw. alternativ erlaubt: "New York, New York, USA". Aber auch hier sollte man sich Gedanken machen, wie man evtl. mit weiteren Regeln verhindern kann, dass zuviele Artikel geändert werden müssen, z.B. indem bei einzelnen Angaben ohne Verlinkung (Beispiel: "Berlin") angenommen wird, dass der verlinkte Name ("Berlin") gemeint ist. Grüße --APPER\^☺☹ 10:54, 20. Feb. 2008 (CET)

Bei den Ortsnamen möchte ich widersprechen: Wenn du der Meinung bist, dass das Lemma New York City falsch ist, verschiebe den Artikel. In den Personendaten sollte das Lemma verlinkt werden, mit Ausnahmen nur in Einzelfällen wie nach Umbenennung eines Ortes. --08-15 11:36, 20. Feb. 2008 (CET)

Dann lassen wir New York erstmal außen vor, aber auch Markersdorf (Sachsen) finde ich nicht passend: Verlinkt werden sollte so: Markersdorf. So haben wir einen korrekten Link und eine korrekte Anzeige. --APPER\^☺☹ 18:50, 20. Feb. 2008 (CET)

Schönes Beispiel. Noch besser: Kito Lorenc wurde 1938 in Schleife geboren. Der Artikel heißt Schleife (Sachsen), 1938 gehörte der Ort zur preußischen Provinz Schlesien. --32X 10:55, 21. Feb. 2008 (CET)

In dem Fall ist die abweichende Linkbeschriftung sinnvoll. Bei Markersdorf (Sachsen) sehe ich nicht ganz, was das Problem sein soll? --08-15 11:04, 21. Feb. 2008 (CET)

Das Problem ist, dass man aus unterschiedlichen Gründen einfach den korrekten Namen des Ortes haben will. Beispielsweise, weil man den in irgendeiner anderen Ortsdatenbank nachschlagen will oder was weiß ich (natürlich funktioniert das bei mehrdeutigen Titeln wieder nicht...). Ich fänd es einfach sinnvoll, den Namen, der auf dem Ortseingangsschild steht zu haben. Man weiß nicht, für was man es mal braucht. Und wenn man den Ort irgendwo mal anzeigt, dann soll das einheitlich sein und da soll nicht bei einem "Markersdorf (Sachsen)" stehen und beim anderen "Leipzig" (ohne Sachsen). Die Klammern sind in dem Fall halt zur Vermeidung doppelter Lemmata, aber nicht zur Anzeige... --APPER\^☺☹ 11:38, 21. Feb. 2008 (CET)

Nebenbemerkung: Ich will NYC nicht nach "New York" verschieben, da ich an dem Artikel nicht mitgearbeitet habe. Habe das Thema aber auf der dazugehörigen Disk. angestoßen: Diskussion:New York City#Lemma. --Kolja21 03:22, 21. Feb. 2008 (CET)

Was sehr hilfreich ist, weil jetzt mal wieder die Googlezähler in Erscheinung treten, die aber die Verlinkungen dann doch nicht überwachen. Vielen Dank für deine „konstruktive“ Hilfe. --Matthiasb 22:34, 21. Feb. 2008 (CET)

Gerne geschehen. Ich bevorzuge für Fragen der deutschen Rechtschreibung aber immer noch den Duden. --Kolja21 04:27, 22. Feb. 2008 (CET)

Ich halte APPERs Anregung, die Regeln einzeln zu diskutieren, für am besten geeignet, voranzukommen. (Daher zunächst der folgende Diskussionspunkt.) In einer Globaldiskussion gehen die einzelnen Anregungen und Argumente schnell unter. Nebenbei waren die Bemerkungen von Matthiasb zur Linkproblematik für mich wertvoll. Vielleicht auch für andere, die sie aber hier nicht finden werden... --Griot 14:26, 22. Feb. 2008 (CET)

Sehr gut! Ich bin auch für Einzeldiskussionen. Wollte oben nur das ganze mal zusammen runterschreiben. -- sk 18:41, 22. Feb. 2008 (CET)

Einzeldiskussion: Verlinkung des (bekannten) Geburts-/Sterbeorts

Dass dieser Ort zu verlinken ist, scheint Konsens zu sein. Die Behandlung, wenn ein Ortsartikel gleichen Namens bereits existiert, ebenso. (Der Fall, dass der Ort seinen Namen zwischenzeitlich geändert hat, wird hier noch nicht behandelt.) Schwierigere Fälle (möglicherweise unvollständig):

Situation 1: Ortsname 'Musterort', für den der entsprechende Ortsartikel bereits existiert.

Situation 1a: Der Ortsartikel trägt nicht den Namen 'Musterort', sondern z.B. 'Musterort (Konkretisierung)'.

Die Verlinkung sollte nicht in der Form [[Musterort (Konkretisierung)]], sondern in der Form [[Musterort (Konkretisierung)|Musterort]] erfolgen.

Beispiele:

• nicht [[Perm (Stadt)]], sondern [[Perm (Stadt)|Perm]]
• nicht [[Markersdorf (Sachsen)]], sondern [[Markersdorf (Sachsen)|Markersdorf]]

Begründung: s. APPERs Begründungen in Abschnitt "ungenauen Geburts-/Sterbeort verlinken?" und erneut in "Datenveredelung durch strengere Regeln".

Situation 1b: Der Ortsartikel trägt einen im Deutschen eher selten verwendeten Namen.

Die Verlinkung sollte nicht in der Form [[Musterort]], sondern in der Form [[Musterort|Musterorts üblicherweise verwendeter Name]] erfolgen.

• nicht [[New York City]], sondern [[New York City|New York]]

Dies könnte kontrovers sein - s. die Diskussion zwischen APPER, 08-15, Kolja21, Matthiasb am Ende von Abschnitt "Datenveredelung durch strengere Regeln". (Möglicherweise verstehe ich da aber etwas falsch.)

Situation 2: Ortsname 'Musterort', für den kein entsprechender Ortsartikel existiert, wohl aber für einen Ort 'Ueberort', in den Musterort inzwischen eingemeindet wurde.

Es sollte eine Weiterleitung von 'Musterort' nach 'Ueberort' angelegt werden (sofern nicht schon vorhanden). (In aller Regel dürfte aber die Form 'Musterort (Konkretisierung)' --> 'Ueberort' geeigneter sein.) Der Link bekäme dann die Form [[Musterort (Konkretisierung)|Musterort]].

Beispiel:

• nicht [[Rüdersdorf bei Berlin|Herzfelde]], sondern etwa [[Herzfelde (bei Berlin)|Herzfelde]] (mit Weiterleitung 'Herzfelde (bei Berlin)' nach 'Rüdersdorf bei Berlin')

Begründung: Wenn die Weiterleitung von 'Musterort' später durch einen Artikel ersetzt wird, brauchen die Links darauf nicht angepasst zu werden.

Situation 3: Ortsname 'Musterort', für den kein entsprechender Ortsartikel existiert (und auch nicht Situation 2 vorliegt).

In aller Regel wird es sich heute in diesem Fall um kleinere (oder nicht mehr existierende) Orte handeln. Der Link sollte daher i.d.R. besser [[Musterort (Konkretisierung)|Musterort]], statt [[Musterort]] heißen, um späteren Kollisionen möglichst vorzubeugen. (Ratschläge für die Wahl der 'Konkretisierung' wären hier nützlich, z.B. zeigt die Begriffsklärung Newtown, dass Newtown (Ohio) vielleicht ausreichen würde, nicht aber Newtown (Pennsylvania).) [Nebenbei: Der Wert solcher BKL-Seiten gerade für Ortsnamen ist kaum zu überschätzen. Werden sie zwischen den verschiedensprachigen wikipedias systematisch ausgetauscht?] --Griot 15:27, 23. Feb. 2008 (CET)

Ich würde das so verwenden:

1. Bei Wikipediainternen Konkretisierungen: [[Musterort (Wikipediakonkretisierung)]] -> [[Musterort (wikipediakonkretisierung)|Musterort]] zum Beispiel: [[Markersdorf (Sachsen)]] -> [[Markersdorf (Sachsen)|Markersdorf]]
2. Bei offizieller Klammerverwendung: [[Musterort (offizielle Konkretisierung)]] zum Beispiel: [[Halle (Saale)]]

Dies hat den Vorteil, das der Leser den gewohnten Namen vor sich hat, sollte irgendeine Datenbankabfrage nach Orten durchgeführt werden. --Ephraim33 17:19, 27. Feb. 2008 (CET)

Sicher nicht [[New York City|New York]], aber [[Ostrava|Mährisch Ostrau]] ist bezüglich der historisch korrekten Benennung von Ortsnamen durchaus angebracht. --Matthiasb 17:12, 1. Mär. 2008 (CET)

Ich kann mich hier eigentlich allem anschließen. Zur Ergänzung von Ephraim33: Ich denke, dass klar ist, dass die Klammerangabe nur weggelassen wird, wenn sie nicht Teil des Namens ist, z.B. [[Frankfurt (Oder)]], aber [[Markersdorf (Sachsen)|Markersdorf]]. Den Spezialfall New York sollten wir hier nicht ständig thematisieren, das ist vermutlich ne ganz eigene Diskussion. --APPER\^☺☹ 18:56, 1. Mär. 2008 (CET)

Ack, aber die Problematik der Ortsnamen in ehemals deutschsprachigen Gebieten ist brisant. --Matthiasb 20:30, 1. Mär. 2008 (CET)

Zu v. Chr. und anderen Abkürzungen

Hier sollte ein einheitliches Format verwendet werden, siehe z. B. auch Wikipedia_Diskussion:Formatvorlage_Biografie#.2A.E2.80.A0_ersetzen.3F --Habakuk <>< 17:24, 24. Feb. 2008 (CET)

Wieso sollte man eine umstrittene, zeitlich falsche, (ursprünglich) religiös motivierte Bezeichnung nehmen? Es gibt keinen logischen Grund, in einer wissenschaftlicher Enzyklopädie, wie wir sie eine sein wollen, eine unwissenschaftliche Bezeichnung zu werden, wo es doch eine wissenschaftliche(re) gibt, die neben dieser nach DIN genauso gestattet ist. Noch neutraler ist wohl v. d. Z. Deswegen die Artikel der Personen zu ändern, die aus Überzeugung ihr ganzes Leben lang in Klausuren und Arbeiten die gültige Abkürzung verwenden, finde ich in etwa so sinnvoll, wie posthum zu postum zu ändern. Ich hätte nicht gedacht, dass eine logisch und formal sinnvolle Änderung unter Verwendung von WP:SM Probleme bereiten würde – wenn es eine gültige (in meinen Augen sogar wissenschaftlich vorzuziehende) Alternative gibt, wieso sollte diese unterbunden werden? Grüße, —DerHexer (Disk., Bew.) 17:46, 24. Feb. 2008 (CET) P. S.: Zur Lektüre: v. Chr. und v. u. Z.

Weil das auch außerhalb der Wikipedia die übliche Konvention ist und die religiöse Bedeutung völlig in den Hintergrund getreten ist. --08-15 18:33, 24. Feb. 2008 (CET)

Und deswegen ist die andere richtige Abkürzung falsch? —DerHexer (Disk., Bew.) 18:35, 24. Feb. 2008 (CET)

Sie entspricht halt nicht der Festlegung für die Metadaten, genauso wenig wie z.B. die Monatsangabe "Jänner". "Jänner" ist deswegen auch nicht falsch, gehört aber nicht in die Metadaten, die für eine automatische Auswertung vorgesehen sind. --08-15 18:49, 24. Feb. 2008 (CET)

Ich denke, man sollte nicht Sprachen/Dialekte mit Form vermengen. Für die Computerauswertung ist nur eine Variante wahrscheinlich besser, aber inkonsequent. —DerHexer (Disk., Bew.) 19:01, 24. Feb. 2008 (CET)

(nach BK) Ich bin dafür nur v. Chr. zu verwenden. v. u. Z. beschreibt ja schön das Problem, es gibt noch v. d. Z., v. d. Chr., mit und ohne Leerzeichen oder mit geschütztem Leerzeichen. Diese Varianten zuzulassen, würde die Auswertung nur unnötigt verkomplizieren. Die meisten Artikel nutzen sowieso nur die Variante "v. Chr."
Es gibt schon gute Gründe, die Bezeichnung v. Chr. zu verwenden: Sie ist in weitem Gebrauch und auch den Laien bekannt. Und dabei spielt es keine Rolle, dass Dionysius Exiguus ein paar Jahre neben der tatsächlichen Geburt Christi lag und dass die Zeitrechnung ursprünglich religiös motiviert war.
Natürlich gibt es einige Historiker, die die andere Bezeichnung verwenden, aber zumindest für die Personendaten sollte wir nur eine Möglichkeit wählen. Die Personendaten sind ja nicht für unmittelbar für die Leser bestimmt, sondern sollen computerlesbar sein, um nützliche Abfragen zu ermöglichen. Lässt man zwei Varianten statt einer zu, verdoppelt das den Aufwand für Datenbankabfragen.
Keiner macht dir (DerHexer) Vorwürfe, dass du nach WP:SM gehandelt hast. Aber Personendaten sind für die Allgemeinheit sowieso unsichtbar, deshalb würde ich die Zulassung von mehr Möglichkeiten als unnötige Verkomplizierung der Auswertung bezeichnen. --Ephraim33 18:55, 24. Feb. 2008 (CET)

Dann ist es also konsequent, in seinem Artikel „v. u. Z.“ zu schreiben und in bei den PD „v. Chr.“? —DerHexer (Disk., Bew.) 19:00, 24. Feb. 2008 (CET)

Naja konsequent ist es nicht, aber es würde die Auswertung der Personendaten nicht beeinflussen. Bei dem von 08-15 gebrachten Beispiel ist das auch schon so: Im Artikeltext kann Jänner stehen, aber in den Personendaten steht immer Januar, ebenso Feber und Februar. Ich persönlich würde v. Chr. bevorzugen, aber das ist nur meine Sichtweise. Wäre das ein Kompromiss: "Im Artikel kannste schreiben waste willst, und in Personendaten steht v. Chr."? --Ephraim33 19:19, 24. Feb. 2008 (CET)

Wäre möglich, sollte aber irgendwie festgehalten werden. —DerHexer (Disk., Bew.) 19:28, 24. Feb. 2008 (CET)

Ich halte v. u. Z. neben den bereits genannten Gründen der Auswertung und Einheitlichkeit nicht für sinnvoll, da:

• die Abkürzung v. Chr. leichter zu lesen ist als v. u. Z.
• die Abkürzung v. Chr. weiter verbreitet ist und mehr Menschen bekannt ist
• sich vor unserer Zeitrechnung auch auf die Geburt von Jesus Christus bezieht (da das die Grundlage unserer Zeitrechnung ist), und damit auch nicht neutraler ist.

--Habakuk <>< 20:28, 24. Feb. 2008 (CET)

Zum Ersten: Es ist sogar ein Buchstabe mehr als bei v. u. Z., von der Zeichenzahl (ohne Leerzeichen) gleich. … Dass es weiter verbreitet ist, bedeutet nicht zwangsläufig, dass es formal besser wäre – ich frage mich wie der so kleine Anteil an Muslimen, Juden, Buddhisten, Hinduisten, Taoisten etc. pp. sich freuen würde, wenn man ihnen in jedem Dokument Christus vorsetzen würde – v. u. Z. bzw. v. d. Z. wäre da verständlicher. Des Weiteren finde ich das lächerlich, wenn man einer Person einer Zeit vor unserer Zeitrechnung sagen würde, dass er so und so viele hundert Jahre vor einer Person geboren worden ist – auch hier ist ein definierter Punkt erheblich logischer. … Und zum Dritten: Nein, das ist ein Trugschluss. Wann der reale Jesus (Christus heißt er ja verständlicherweise auch erst seit der viel späteren Salbung) geboren wurde, ist nicht genau bekannt: Die Zahlen schwanken zwischen sieben und vier v. u. Z. – hier wirkt „v. Chr.“ extrem lächerlich. Grüße, —DerHexer (Disk., Bew.) 21:14, 24. Feb. 2008 (CET)

Allgemeine Sprachgebrauch: Es ist völlig unüblich, vor unserer Zeitrechnung zu schreiben, dasselbe gilt für die Abkürzung v. u. Z. und es besteht kein Grund, von tausenden von Artikeln abzuweichen. (Es ist für die von dir genannten Gruppen genauso ungewöhnt, daß † für das Todesdatum steht, trotzdem ist es in deutschsprachigen Werken so üblich). Wortschatzlexikon Uni Leipzig zum Vergleich: v. Chr. -> HK 14; v. u. Z. -> ohne Ergebnis; vor unserer Zeitrechnung -> HK 19; vor Christus -> HK 14 --Matthiasb 20:29, 1. Mär. 2008 (CET)

Kurzbeschreibung Schweizer vs. schweizerisch

Bevor ich das als neuen Fehler in meine Fehlerliste aufnehmen wollte, möchte ich das hier kurz zur Diskussion stellen. Bei der Kurzbeschreibung steht meist Nationalität + Beruf (z.B. polnischer Politiker). Die Nationalität ist dabei u 99 Prozent mit dem Adjektiv in "-sch"-Form (deutsch, polnisch, russisch, ...) eingetragen. Sehr selten und daher unüblich findet man "Pole Politiker" oder "Italiener Politiker". Das macht es einfach die Daten maschinell auszuwerten und man kann solche unüblichen Fälle rausfiltern und anpassenen. Bei den Schweizern gibt es derzeit aber keine einheitliche Form. Es gibt "Schweizer Politiker" und "schweizerischer Politiker".

Um Wikipediaweit einheitlich zu arbeiten schlage ich deshalb vor nur noch die Version mit "schweizerisch" zu zulassen. Wir würden dadurch die Daten weiter vereinheitlichen. Knackpunkt dabei ist, dass derzeit "schweizerisch" nur 625 Mal und "Schweizer" gut 3628 verwendet wird. Ich weiß das Viele die Mühe scheuen werden, aber es muss ja nicht von heute auf morgen umgestellt werden. Es muss nur eine klare Regel gelten.

Vorteil der Aktion: Wenn man nur die Personendaten hat, kann man mit einer Liste der Adjektive sehr schnell alle einer Nationalität zuordnen. Wenn man nicht diese Vereinheitlichung durchführt braucht man zusätzlich noch eine Liste mit anderen Formen erstellen z.B. "Pole", "Polin", "Däne", "Dänin", "Japaner", "Japanerin" etc. -- sk 21:35, 26. Feb. 2008 (CET)

Äh... nein. Also es ist ein gewaltiger Unterschied zwischen "Japaner", "Pole" auf der einen Seite und "Schweizer" auf der anderen. Dazu der Duden:

¹ Schwei|zer (Bewohner der Schweiz; auch für Melker; landsch. für Küster in kath. Kirchen)

² Schwei|zer; Schweizer Bürger; Schweizer Jura (Gebirge), Schweizer Käse, Schweizer Land (schweizerisches Gebiet; vgl. aber Schweizerland)

In diesem Fall geht es um die zweite Bedeutung. Für die meisten anderen Länder gibt es nur die erste Bedeutung ("Pole", "Japaner" und auch "Deutscher" großgeschrieben), das Wort "Schweizer" ist eine Ausnahme und es wird adjektivisch gebraucht. In diesem Fall müssten also beide Formen zugelassen werden. --APPER\^☺☹ 22:03, 26. Feb. 2008 (CET)

Mir ist schon klar, dass beide Formen möglich sind, aber wir sollten uns auf eine beschränken. -- sk 22:05, 26. Feb. 2008 (CET)

Finde ich übertrieben. Es gibt genau ein Land, in dem zwei Formen möglich sind, das kann man einfach in die Liste aufnehmen. Einen wirklichen Grund, eine Form zu verbieten sehe ich nicht. Eigentlich bin ich ja auch immer für Vereinheitlichung, aber die werden wir in dem Fall nie erreichen... ansonsten tendier ich persönlich aber auch immer zu "schweizerisch".. --APPER\^☺☹ 22:39, 26. Feb. 2008 (CET)

Es gibt WP:NK/S und das ist da eindeutig. --Matthiasb 23:14, 26. Feb. 2008 (CET)

Naja, erstmal sollten wir uns aber um die vielen "Amerikaner" kümmern, bei denen unklar ist, ob nicht doch "US-Amerikaner" gemeint sind... --APPER\^☺☹ 23:47, 26. Feb. 2008 (CET)

Noch ein Minenfeld ;-) Bei NK/S wurde "amerikanisch" ausgewürfelt. Das steht wohl nur dort, weil kaum einer die Seite kennt. Und dass der Würfel bei "schweizerisch" liegengeblieben ist, halte ich auch nicht für verbindlich. Lemmata sind als Eigenbezeichnung mal so, mal so vorgegeben und auch im Fließtext ist es nicht einheitlich durchsetzbar, das ist illusorisch. Es gibt übrigenslich auch noch Liechtensteiner, Luxemburger, Malteser und Tiroler Persönlichkeiten. Das Problem ist, dass in der Einleitung oft genug Schweizer steht und die PD abkopiert werden. Also wenn sich eine Vereinheitlichung irgendwie vermeiden lässt ... -- Harro von Wuff 00:57, 27. Feb. 2008 (CET)

Danke für den Hinweis. Hatte die Luxemburger ganz vergessen, wo ich das Problem auch gesehen habe. Meiner Meinung nach sollte man nicht den Fließtext mit dem Datenfeld vergleichen. Wir wollen Daten anbieten, die für eine Datenbank hilfreich sind. Und oberstes Gebot in einer Datenbank sind einheitliche Datenformate. Deshalb bin ich für US-amerikanisch, luxemburgisch, schweizerisch und Co. -- sk 05:44, 27. Feb. 2008 (CET)

+ Liechtenstein, Liechtensteiner, liechtensteinisch --Matthiasb 20:32, 1. Mär. 2008 (CET)

Neue Fehlerliste

Ich hab mal eine neue Fehlerliste generiert. Wikipedia:Personendaten/Wartung/Fehlerliste Achtung, sie ist sehr groß!! 260 kB! Sie wird aber mit eurer Hilfe sehr schnell schrumpfen. Ich analysiere den Dump und checke dann auf dem Live-Artikel ob der Fehler noch da ist. Wenn ihr also die Fehler korrigiert wird die Liste immer kürzer. Ich hatte heute nicht mehr so viel Zeit, sie zu perfektionieren, aber ich wollte sie zumindestens schon mal online stellen, weil ich in der Woche sonst nicht wieder dazu kommen. Die Liste wird von mir dann in den nächsten Tagen vollautomatisch aktualisiert. Ich bin auch noch dabei sie weiter auszubauen. Hinweise und Anregungen nehme ich gerne entgegen. -- sk 22:52, 17. Feb. 2008 (CET)

Gut gemachte Liste: Klare Gliederung und hilfreiche Einleitung. --Kolja21 02:53, 18. Feb. 2008 (CET)

Kann mich da nur anschließen. Tolle Liste, Danke! Freue mich auf regelmäßige Aktualisierungen. --APPER\^☺☹ 03:21, 18. Feb. 2008 (CET)

Das Feld NAME dient zur alphabetischen Sortierung. Der erste Buchstabe sollte dort immer groß sein. ist aber falsch. Das gilt für Defaultsort, aber wer nach NAME sortieren will, muss das halt case-insensitive tun. Der Name soll dort in seiner korrekten Schreibweise angegeben werden. --08-15 03:47, 18. Feb. 2008 (CET)

In Anbetracht der Tatsache das von fast 200.000 Personendaten nur 598 Personen mit einem kleinen Buchstaben anfangen (also 0,3 Prozent) bin ich für eine Großschreibung dieser Namen, weil das dann einiges vereinfacht. -- sk 20:35, 18. Feb. 2008 (CET)

Das vereinfacht nicht viel, mit einem naiven Sortierverfahren scheiterst du dann spätestens an den Umlauten und sonstigen Sonderzeichen in den Namen. Wenn man das weiterdenkt, landet man beim "Defaultsort" und braucht NAME gar nicht mehr. - Es wäre auch schade, wenn solche (lösbaren) technischen Probleme die Möglichkeit zerstören, die angesetzte Namensform als Lemma zu verwenden, wie es z.B. bei der 1. Wikipedia-CD gemacht wurde. --08-15 20:52, 18. Feb. 2008 (CET)

Vor allem würde das jedes Mal neu verwirren, da man nicht weiß, ob der Name nun aus technischen Gründen groß geschrieben wurde oder ein Fehler vorliegt. --Kolja21 21:33, 18. Feb. 2008 (CET)

Hmm, dann gebt mir doch mal ein Beispiel. In den Beispielen unter der Rubrik Datenfelder stehen nur Beispiele, wo der erste Buchstabe groß geschrieben wird. Gibt es eine spezifizierbare Regel, wann etwas klein geschreiben werden muss? -- sk 21:38, 18. Feb. 2008 (CET)

Namen die mit van anfangen. --cwbm 21:41, 18. Feb. 2008 (CET)

Warum werden die anders behandelt als die "von"? -- sk 21:46, 18. Feb. 2008 (CET)

Verstehe ich nicht ganz. Wenn der Nachnahme mit von, van, de, del usw. anfängt, dann wird das klein geschrieben. Nach dem ersten überfliegen der Liste sind das die Mehrzahl der Fälle. Besonders verwirrend wird das ganze, weil bei der Anleitung zu den PD nichts von Großschreibung steht.--cwbm 21:52, 18. Feb. 2008 (CET)

"von" wird nicht zum Familiennamen gruppiert: Goethe, Johann Wolfgang von. Nach den Regeln für die alphabetische Katalogisierung wird bei ausländischen Namen aber u.a. anders verfahren, zum Beispiel bei belgischen. Ein anderes Beispiel ist der arabische Artikel al, siehe Wikipedia:Namenskonventionen/Arabisch --08-15 22:00, 18. Feb. 2008 (CET) Allerdings wird der Anfangsbuchstabe in den Beispielen in den RAK dann groß geschrieben. Hm. --08-15 22:05, 18. Feb. 2008 (CET)

Mir ist gerade noch aufgefallen, das mein Skript noch Probleme mit den Sprachvorlagen hat. Also wenn eine arabische oder russischer Name in den Personendaten mit den entsprechenden Rus, ar -Vorlagen eingebunden wird, hat mein Skript noch Probleme. Werde das bei Gelegenheit ändern. -- sk 21:48, 18. Feb. 2008 (CET)

Ich verstehe jetzt, was du meinst. „Johannes Diderik van der Waals“ wird zu „Waals, Johannes Diderik van der“ und nicht zu „ van der Waals, Johannes Diderik“, das ist der Fehler. Das sollte man aber auch besser so erläutern und nicht mit Großschreibung argumentieren.--cwbm 21:59, 18. Feb. 2008 (CET)

Prinzipiell sollte Kleinschreibung kein Problem sein, bei "von" oder so ists aber natürlich ein Fehler. Ich würd mich auf dafür einsetzen, dass weiterhin ar-Vorlage etc. als Fehler gewertet werden, man sollte für die PD-Auswertung keine weitere Vorlagenextraktion durchführen müssen... --APPER\^☺☹ 22:34, 18. Feb. 2008 (CET)

APPER, ich bin voll einer Meinung mit dir. Die Auswertung sollte so einfach wie möglich bleiben und die Vorlagenextraktion gehört nicht zu den einfachen Dingen in der Wikipedia. --sk 19:18, 19. Feb. 2008 (CET)

Danke, sk, für die Liste. Ihre Größe macht es allerdings schwer, sie zu bearbeiten. Vielleicht kannst Du bei den angekündigten Aktualisierungen mehrere kleinere Listen statt einer großen erzeugen?

(Bemerkung war nur meine Unkenntnis der Bearbeitungsfunktionen geschuldet. --Griot 17:50, 4. Mär. 2008 (CET))

Ein größerer Wunsch: könntest Du (oder APPER oder ...) eine Liste aller Personendaten produzieren? Oder eine Anleitung dafür? (Mir gelang nur eine Liste von 2000 PD.) Das würde gestatten, Probleme und Lösungen besser zu beurteilen.

Hat sich erledigt. Zur eigenen Überraschung: mein Rechner schafft's. Die Liste der Personendaten (Stand Dump vom 20. Februar, aber zur Beurteilung von Problemen/Vorschlägen immer noch ausreichend) hat gezippt 8 MB. Wenn ich wüsste, wo/wie, könnte ich sie zur Verfügung stellen. --Griot 17:50, 4. Mär. 2008 (CET)

Die Bearbeitung der fehler- oder zweifelhaften PD stößt allerdings schnell an eine Grenze, da Regeln für die Eintragungen fehlen oder unbefriedigend sind. Die von Dir im nächsten Abschnitt angestoßene Regelklärung sollte (dem Hauptteil) der Fehlerbearbeitung vorangehen. --Griot 00:46, 22. Feb. 2008 (CET)

Bleibt aktuell. --Griot 17:50, 4. Mär. 2008 (CET)

Einzeldiskussion: Alternativnamen

Zunächst eine Zusammenstellung bisheriger Aussagen:

Die Hilfeseite gibt für Alternativnamen nur zwei Beispiele an:

* Magalhães, Fernão de (portugiesisch); Magallanes, Fernando de (spanisch)

* Schmidt, Johann Kaspar (wirklicher Name)

Für Namen aus nichtlateinischen Schriften fehlt ein Beispiel. Im obigen Diskussionspunkt "Sprachkennzeichnung in Alternativnamen" begründet Matthiasb m.E. überzeugend, dass {{lang|ru|Волков, Фёдор Кондратьевич}} geschrieben werden muss, nicht Волков, Фёдор Кондратьевич.

Im obigen Diskussionspunkt "Neue Fehlerliste" plädieren APPER und sk jedoch gegen die Verwendung von Vorlagen in PD. Begründung: einfachere Auswertung. Dies würde nichtlateinische Schriften ganz ausschließen, nur Umschriften wären zulässig.

sk schlägt oben folgende Regeln für Alternativnamen vor:

(A) Keine Verlinkung erlaubt

(B) Es dürfen keine Vorlagen für Sprachen benutzt werden

(C) Es muss immer mit einem Semikolon getrennt werden

(D) Format: Sprachadjektiv: Nachname, Vorname (Anmerkung)

Bsp.:

o dänisch: Krug, Ute (Künstlername); russisch: Krugiulla (deutsch Polkakönigin)

o jamaikanisch: Reggyman (Pseudonym); ukrainisch: Uischalyr (Geburtsname)

Durchsicht der Wikipedia:Personendaten/Wartung/Fehlerliste von sk wie von 2000 PD ergab für mich keine bisher ungenannten Anforderungen. sk's vorgeschlagene Regeln scheinen den Problembereich mit zwei Ausnahmen (s.u.) abzudecken. Im einzelnen:

(A), (C), (D) - einverstanden (ausser zu den russisch/ukrainisch-Beispielen)

(B) - nicht einverstanden

zu (D): Dies ist zwar eine wesentliche Abweichung von den bisherigen Regeln, erfordert einige (wieviel ?) Überarbeitungen, es ist jedoch eine erhebliche Verbesserung, da Sprachbezeichnung und Anmerkung (meist: Namensart) nicht mehr durcheinandergeworfen werden. (Es sollte noch eine Liste empfohlener Anmerkungen erstellt werden. Ohne andere Anmerkungen zu verbieten.)

zu (B): Verzicht auf Sprachvorlagen bedeutet eine erhebliche Informationsverschlechterung - Umschriften sind i.d.R. nicht reversibel. Die dagegen eingewandte Auswertungserschwerung müsste schon sehr erheblich sein, um das zu rechtfertigen. (Sie scheint mir dagegen sehr gering - wenn Sprachvorlagen ausschließlich in der Form {{lang|ru|...}} vorkommen, kann ein Parser sie einfach ignorieren.) Ich hielte im Gegenteil eine Empfehlung für sinnvoll, den Namen in originaler Schreibweise aufzunehmen. Ein Beispiel wäre dann:

o russisch: {{lang|ru|Волков, Фёдор Кондратьевич}}

vielleicht sollte das aber noch mit einer Anmerkung "(originale Schreibweise)" versehen werden.

Die beiden von sk's Regeln nicht ausreichend abgedeckten Probleme:

• Sollen bei Namen aus nichtlateinischen Schriften Umschriften mit aufgenommen werden?

Ich wäre für den Verzicht auf Umschriften, sofern die originale Schreibweise angegeben ist. (Die Liste sollte nicht unnötig aufgebläht werden.) Ausnahmen wären sinnvoll, wenn Umschriften verbreitet sind, die nicht den heutigen Umschriftregeln entsprechen.

• chinesische Namen (und sonstige, bei denen 'Nachname Vorname' üblich ist)

Die technisch einfachste "Lösung" wäre der Verzicht auf das Komma. Dann sieht der ganze Name wie ein Nachname aus. Jeder Umgang mit dem Namen scheint korrekt zu erfolgen, außer: der Nachname kann nicht extrahiert werden.

Schwieriger, aber korrekter: auch hier wird das Komma gesetzt. Der Nachname kann also gewonnen werden. Software, welche die "übliche" Namensform erzeugen soll, muss jedoch erkennen, dass in diesen Fällen nicht in die Form "Vorname Nachname" umzustellen ist - das ist an Hand des vorangehenden Sprachadjektivs möglich.

Ich wäre für die zweite Lösung (die zudem genau sk's (D) entspricht).

--Griot 23:27, 22. Feb. 2008 (CET)

Volle Zustimmung, nur eine Anmerkung: Den Hinweis "originale Schreibweise" halte ich für überflüssig, das ergibt sich spätestens aus der lang-Vorlage. --08-15 00:04, 23. Feb. 2008 (CET)

Der Grund für mich, warum ich die Sprachvorlagen in der Personenvorlage nicht haben möchte ist die schwierige Auswertung.

• 1.Problem: Der Parser muss aus dem Volltext eine Vorlage mit dem Anfang {{Personendaten finden und soll dann das Ende der Personendaten finden. Er sucht einfach nach }} und findet es auch, das ist aber das Ende von der ersten Sprachvorlage. Ich will damit sagen, dass wir entweder das Ende der Personendaten anders gekennzeichnet wird (z.B: </Personendaten>) oder durch die Zulassung von Vorlagen in Vorlagen die Auswertung der Personendaten extrem komplex wird und nur noch von einigen wenigen Spezialisten umgesetzt werden kann. Das das machbar ist, zeigt das Wikipedia:WikiProjekt Vorlagenauswertung, wo sowas zu Hauf vorkommt (Fragt nicht wieviele Kopfschmerzen ich hatte!), aber wir wollen doch eine einfache und effizente Lösung. Es sollte auch für Nichtinformatiker möglich sein an die Personendaten mit vertrettbaren Aufwand heranzukommen.
• 2.Problem: Angenommen wir kriegen jetzt alle Personendaten komplett raus aus dem Volltext, dann muss man ja die Informationen aus den Sprachvorlagen auch irgendwie maschinell weiterverarbeiten. Das heißt ich muss für 129 Fremdsprachenvorlagen in der Kategorie:Vorlage:Fremdsprachenunterstützung eine Auswertmechanismus erstellen obwohl ich nicht weiß ob vielleicht schon in der nächsten Woche ein neuer dazukommt oder ein bestehender verändert wird. Das ganze ähnelt dann in etwa so dem Radio Eriwan-Spruch: "Dürfen wir die Personendaten nutzen? Imprinzip ja, aber ihr müsst vorher ein Informatik-Studium absolvieren und mindestens 129 Sprachvorlagen verstehen können." Mal abgesehen davon das man die Schriften entziffern können sollte.
• 3.Problem (Anmerkung): Fragen wir uns doch mal wozu die Alternativnamen da sind! Meiner Meinung nach sollen damit weitere Namen eingebaut werden, um in einer daraus generierten großen Namensliste alle Personen über Artikelname oder Alternativnamen zu finden. Nicht mehr und nicht weniger soll das Datenfeld leisten. Das heißt man braucht da keine große Wissenschaft draus zu machen. Wenn da ein Chinese mit seinen Chinesischen Zeichen rein soll, dann genau so wie man ihn auch in einem Chinesischen Lexikon suchen würde. Wenn die große Namensliste am Ende entsteht, dann muss ja so oder so lateinische und chinesische Namen in einen große Liste gebracht werden. Aber es ist egal ob das jetzt eine Transliteration oder Transkription ist oder nicht (zumindestens für mich Laien) hauptsache ich finde die Person. Alle genaueren Infos finde ich ja dann im Artikeltext. --sk 14:57, 23. Feb. 2008 (CET)

Ja, die Probleme existieren, aber sie sind (ohne "Informatik-Studium") lösbar:

• Zum 1.Problem: Sprachvorlagen sollten nur in Alternativnamen vorkommen. Es reicht daher aus, nach Erkennen des Anfangs "{{Personendaten" zunächst nach "GEBURTS" und dann nach dem abschließenden "}}" zu suchen. Dies setzt nur voraus, dass GEBURTSORT oder GEBURTSDATUM im Datensatz vorkommen und zwar beide hinter ALTERNATIVNAMEN. Wenn überhaupt, dürfte es wenige PD geben, die das nicht erfüllen - sie könnten geändert werden.
• Zum 2.Problem: Möglicherweise verstehe ich das Problem nicht? Solange nicht feststeht, wozu die Information genutzt werden soll, kann doch ein in einer Vorlage verpackter Name einfach als Zeichenkette behandelt werden - wo ist das Problem? Sobald die Nutzung aber feststeht (und die Abspeicherung damit auch als nützlich nachgewiesen, ohne sie wäre die Nutzung ja nicht möglich), hängt die Behandlung natürlich von der konkreten, jetzt noch unbekannten Nutzung ab. Und für einfache Verwendungen (Listen erzeugen, sortieren, etc.) reicht immer noch die Behandlung als Zeichenkette. Etwas komplizierter wird (wie oben bereits kurz besprochen) die Erzeugung der 'Normalform' des Namens, da 'Name Vorname' oder aber 'Vorname Name' gewählt werden muss.
• Zum 3.Problem: Dieses Problem ist grundsätzlicher Art. Wofür sollen die PD genutzt werden? Ich weiß es nicht wirklich und bin da wohl kaum der einzige. Diese Situation ist aber ganz normal, wenn Datenbanken (die PD können so interpretiert werden) erstellt werden! Man kennt vielleicht diese oder jene Verwendung, muss die Daten aber so strukturieren, dass noch unbekannte Anwendungen ebenfalls damit umgehen können. Das bedingt u.a., dass wesentliche Information (Originalschreibung!) gespeichert wird.

(Eine gute alternative Antwort auf die Radio Eriwan-Frage fällt mir leider nicht ein. Schande!) --Griot 21:25, 23. Feb. 2008 (CET)

Zu 1. das ist der Idealfall, aber der wird häufiger als gedacht nicht so eintretten. Z.B. Hawaii hab ich schon als Geburtsort mit HawaiVorlage:Okinai nowiki: Hawai{{Okina}}igefunden. Wem will man sowas verbieten, wenn man generell Vorlagen zulässt. Um halbwegs vernünftig mit den Daten zu arbeiten ziehe ich mir aus den 4,3 GB Dump-Daten immer erstmal nur die Vorlage Personendaten komplett raus und verarbeite die dann weiter. Ich schaue also erstmal überhaupt nicht nach dem Inhalt, weil es da viel zu viele Möglichkeiten gibt, die man programmtechnisch niemals abfangen kann. Im zweiten Schritt wird dann erst auf Konsistenz geprüft. Nun haben wir aber nicht 200 oder 20000 Datensätze sondern 200000 Datensätze. Die kann und will ich nicht von Hand überprüfen. Ich muss also nach Fehlerschemas suchen und die formulieren und dann fallen einige Daten immer über die Klippe, wenn ich nicht von vornherein sicherstelle, das ich zumindestens die komplette Personendaten-Vorlage ausgelesen habe. -- sk 23:36, 23. Feb. 2008 (CET)

(Okina - wieder was gelernt!) Einige Punkte:

• Ein Verbot "keine Vorlage außer in Alternativnamen" ist für den Benutzer nicht wesentlich schwerer als "keine Vorlage".
• Ein Verbot sichert nicht seine Einhaltung. Mit der Möglichkeit von Vorlagen in Vorlagen muss sowieso immer gerechnet werden. Wie auch mit sonstigen Fehlern und Absonderlichkeiten. Beispiele: Im Dump vom 20.2.:

• McCready, Mindy: nur ein "{" vor "Personendaten"
• Jakob I. von Aragon: abschließendes "}}" fehlt
• Matale, Joey: Zeilenwechsel zwischen "{{" und "Personendaten" (ist wohl nicht einmal unzulässig!)

• Natürlich legt das - schließlich völlig korrekte - Okina-Beispiel nahe, zu überlegen, ob es nicht ganz ohne solch Verbot geht.

--Griot 08:21, 27. Feb. 2008 (CET)

Statt "Sprachadjektiv: Nachname, Vorname (Anmerkung)" würde ich "Nachname, Vorname (Anmerkung)" verwenden, wobei die Anmerkung auch ein sprachadjektiv erhalten kann. Weil es genau so bisher auch ist und eine andere Regel in zehntausenden Änderungen resultieren würde. --Ephraim33 17:19, 27. Feb. 2008 (CET)

Dem schließ ich mich an. Dann lieber mehrere Anmerkungen in den Klammern zulassen, z.B. durch ; oder , getrennt. --APPER\^☺☹ 18:27, 1. Mär. 2008 (CET)

Eine grobe Zählung der Daten aus dem Dump vom 20.2. ergibt:

• knapp 51400 mit nichtleerem Alternativnamen
• davon nehmen höchstens 3260 irgendwie auf Sprache oder Schrift bezug
• davon sind weniger als 2300 zu den jetzigen Regeln konform (bei sehr großzügiger Auslegung der Regeln!)

Es wären also weniger als 2300 Änderungen dieses Feldes nötig, wobei sehr vielen davon auch aus anderen Gründen eine Überarbeitung gut täte. Sie macht allerdings erst Sinn, wenn die - deutlich wichtigere - Frage der Originalschreibweise geklärt ist. Kann hierzu vielleicht noch einmal ein Experte die Aussage von Matthiasb im Abschnitt "Sprachkennzeichnung in Alternativnamen" bestätigen: "die Verwendung von Фёдор Кондратьевич ohne Vorlage erzeugt einen nicht den HTML-Konventionen entsprechenden Code und führt zu fehlerhaften Suchergebnissen, etwa bei Google"? Wenn das - wie ich annehme - zutrifft, bedarf die Mehrzahl der genannten 2300 sowie einige Tausend weiterer Alternativnamen einer Änderung! Der völlige Wildwuchs, der bei den nichttrivialen Alternativnamen zur Zeit herrscht, zeigt die Dringlichkeit, hier festere Formen vorzugeben. Die von sk vorgeschlagene Regel "Sprachadjektiv: Nachname, Vorname (Anmerkung)" kann eine erste Ordnung hineinbringen, speziell wenn sie um (nicht geschlossenen) Listen vorgeschlagener Sprachadjektive sowie Anmerkungen (für die Standardsituationen) ergänzt wird.

Die wichtigste Frage bleibt: Originalschreibweise bei nichtlateinischen Schriften ja/nein? Ich plädiere erneut für ja. Das ist schließlich eine der wichtigsten Informationen überhaupt! Die Aufnahme so entscheidender Information kann nicht mit Verweis auf - durchaus mit mäßigem Aufwand beherrschbare - technische Probleme verworfen werden. (Übrigens dürfte sie nützlich (oder unverzichtbar?) sein, um die Interwiki-Verbindungen auszubauen.) Nebenbei: Sie zu verbieten bringt gar nichts. Die Benutzer tragen sie doch ein.

Die Fragen Umschrift ja/nein sowie Reihenfolge der Namenbestandteile - Komma ja/nein sind m.E. gegenüber den genannten zweitrangig. Jedoch sollte wenigstens zur Umschriftfrage eine Klärung erfolgen, bevor große Änderungen erfolgen. Sonst macht man's zweimal.

Ach ja, Okina: ist auch drin. Mehrmals. --Griot 15:46, 4. Mär. 2008 (CET)

Einzeldiskussion: Geburts- und Sterbedatum

Auf der Hilfeseite werden folgende Formen der Datumsangabe empfohlen ("Datumsangaben sollten wie folgt erfasst werden"):

• 12. Januar 1923
• 1512 oder 1515 oder 1520
• 11. September 1167 oder 12. September 1167
• zwischen 1570 und 1600
• (leeres Feld)
• 43 v. Chr.
• um 1460
• 20. November um 1921
• um 3. März 1416
• vor 10. Oktober 1533
• vor 1108
• nach 1245
• getauft 17. Mai 1705
• begraben 14. Juni 1635

(In einem Beispiel tritt auch noch "Frühjahr 1480" auf - offenbar versehentlich.)

Die von sk bereitgestellten Fehlerlisten scheinen mir aber darauf hinzuweisen, dass die empfohlenen Formen die praktischen Bedürfnisse nicht befriedigend abdecken.

Es scheint mir notwendig, die Angabe eines Jahrhunderts zuzulassen:

• 12. Jahrhundert

Es scheint mir sinnvoll, auch zuzulassen:

• Frühjahr 1480
• Ende 1480

Schließlich würde ich es für gut halten, eine Notation für "unsicher" einzuführen - "wahrscheinlich 1460", "vermutlich 1460", "wohl 1460", "angeblich 1460" können nicht korrekt mit "um 1460" wiedergegeben werden. Hierbei kann man unterschiedlich weit gehen.

Minimalvariante:

• 10. Oktober 1533 (unsicher)

Maximalvariante:

• 10.(?) Oktober 1533 -- Tag unsicher
• 10. Oktober(?) 1533 -- Monat unsicher
• 10. Oktober 1533(?) -- Jahr unsicher
• 10. Oktober 1533 (unsicher) -- ganzes Datum unsicher

Eine Verbesserung würde es m.E. auch sein, neben "getauft" und "begraben" weitere festgelegte "Kommentare" zuzulassen. Etwa:

• bezeugt 1108
• vermisst 1945
• verschollen 2007

---

Ein Versuch, die zur Zeit empfohlenen Formen syntaktisch zu beschreiben, ist:

tageszahl  := 1..31

monatsname := "Januar" | ...

jahreszahl := 1..9999

tagesangabe  := tageszahl "."

monatsangabe := monatsname

jahresangabe := jahreszahl [" v. Chr."]

sicheres_jahresdatum := [[tagesangabe " "] monatsangabe " "] jahresangabe

sicheres_datum := sicheres_jahresdatum

datum_jahr_unsicher := [[tagesangabe " "] monatsangabe " "] "um " jahresangabe

datum_tag_unsicher  := "um " tagesangabe " " monatsangabe " " jahresangabe

unsicheres_datum  := datum_jahr_unsicher | datum_tag_unsicher

datumsbereich_zwischen := "zwischen " sicheres_datum " und " sicheres_datum

datumsbereich_vor  := "vor " sicheres_datum

datumsbereich_nach  := "nach " sicheres_datum

datumsbereich := datumsbereich_zwischen | datumsbereich_vor | datumsbereich_nach

datum := sicheres_datum | unsicheres_datum | datumsbereich

evtl_kommentiertes_datum := [kommentar] datum

kommentar  := "getauft " | "begraben "

datum_mit_alternativen := evtl_kommentiertes_datum [" oder " evtl_kommentiertes_datum]...

datumsangabe := leer | datum_mit_alternativen

---

Die Zulassung von Jahrhundertangaben erfordert die neuen Regeln

jahrhundertzahl  := 1..31

jahrhundertangabe := jahrhundertzahl ". Jahrhundert" [" v. Chr."]

sicheres_jahrhundertdatum := jahrhundertangabe

datum_jahrhundert_unsicher  := "etwa " jahrhundertangabe

sowie zwei Regelersetzungen

sicheres_datum  := sicheres_jahresdatum | sicheres_jahrhundertdatum

unsicheres_datum := datum_jahr_unsicher | datum_tag_unsicher | datum_jahrhundert_unsicher

---

Der Wunsch nach einer "unsicher"-Notation wäre in der maximalvariante erfüllt durch:

tagesangabe  := tageszahl "."["(?)"]

monatsangabe := monatsname["(?)"]

jahresangabe := jahreszahl["(?)"] [" v. Chr."]

datum_in_gaenze_unsicher := sicheres_datum " (unsicher)"

unsicheres_datum  := datum_jahr_unsicher | datum_tag_unsicher | datum_in_gaenze_unsicher

(In der Minimalvariante reichen die beiden letzten Regeln.)

Der Wunsch nach "bezeugt" etc. erfordert nur die Erweiterung der kommentar-Regel. Der Wunsch nach "Frühjahr 1480", "Ende 1480", etc. erfordert mehr Änderungen, ich lasse sie erst einmal weg. (Die angegebenen Regeln lassen einige Kombinationen zu, die unerwünscht sind - etwa "zwischen 3. April 333 und 9. Jahrhundert" - das dürfte in der Praxis aber nicht stören.) --Griot 14:13, 22. Feb. 2008 (CET)

Tolle Vorarbeit. Das mit dem syntaktischem Teil ist mir zu komplex beim lesen. Lieber sollten wir eine Tabelle mit richtig und falsch aufbauen, da sieht jeder was erlaubt ist und was nicht. Jahrhundert kann meiner Meinung nach raus. Dafür haben wir "zwischen". Anfang, Mitte, Ende, Frühling, Sommer, Herbst, Winter finde ich problematisch, weil sie nicht konkret werden. Und dann will wieder jemand "Frühjahr" und vielleicht noch "Spätherbst". Deswegen gleich abblocken und wer will kann es mit "zwischen" entsprechend formulieren. -- sk 18:39, 22. Feb. 2008 (CET)

Ich will nochmal erwähnen, dass am wichtigsten ist, dass das ganze maschinell lesbar ist. Den Ansatz mit den (?) finde ich schlechter als das "um", was ja mit zwei Buchstaben sagt, das es nicht sicher ist. Wenn du jetzt an jeder Stelle des Datums das Fragezeichen einfügen möchtest (Maximalvariante), dann wird die maschinelle Lesbarkeit extrem erschwert. -- sk

Zu Deinen einzelnen Einwänden:

• Die Syntax ist natürlich nicht für eine Hilfeseite gedacht - dort sind Beispiele viel besser. Aber gerade für die von Dir hervorgehobene maschinelle Lesbarkeit ist eine exakte Syntax vorteilhaft bis notwendig.
• Die Möglichkeit der Angabe des Jahrhunderts erscheint mir zwingend nötig: Deine Fehlertabelle enthält 346 solche Angaben! Eine 'zwischen'-Formulierung stattdessen ist nicht gleichwertig und unpraktisch. Zudem zeigt mein Syntaxversuch, dass eine zusätzlich mögliche Jahrhundertangabe die Auswertung nur wenig komplizierter macht.
• Ob "Anfang", etc. wirklich notwendig ist, hängt stark davon ab, wie oft das bisher verwendet wird. Diese Daten fehlen mir. Eine vollständige Syntax, die dies zulässt, wird deutlich komplexer. Ein Parser jedoch, der all diese Wörter einfach ignoriert, wird nicht nennenswert komplizierter - das ist gewiss besser, als wenn diese genaueren Informationen unwiederbringlich gelöscht werden. (Übrigens argumentiert der Dir sicher bekannte Benutzer sk weiter oben "genauer Geburtsort von Karl Marx ist bekannt, kann also eingetragen werden; Wissen soll ja nicht unterschlagen werden"...)
• Die Maximalvariante mit den "(?)" ist gewiss zweifelhaft (obwohl für Parser unproblematisch). Nicht aber die Minimalvariante mit "(unsicher)". Dies kann nicht durch "um" ersetzt werden, die Bedeutung ist ja eine ganz andere. Todesdatum "um 340" heißt etwa "zwischen 335 und 345". Todesdatum "340 (unsicher)" kann dagegen (kontextabhängig) heißen "einige Quellen legen 340 nahe, es kann aber auch jeder Wert zwischen 330 und 390 sein".

--Griot 00:33, 23. Feb. 2008 (CET)

Das Jahrhundert, Anfang, Herbst etc. anzugeben ist schon praktischer für den Menschen, aber die Daten sollten ja maschinenlesbar sein. Das heißt es muss dann ein Skript her, dass all die Daten liest und entsprechende Informationen abgewinnen kann. Aus meinem Blickwinkel haben wir derzeit einen sehr guten Konsens gefunden. Wir lassen einen gewissen Grad an Flexibilität zu und zwingen aber gleichzeitig zu einem stark standardisiertem Datumsformat. Ich sehe deshalb um ehrlich zu sein dort überhaupt keinen Handlungsbedarf und hab mich gewundert, dass das die erste Detaildiskussion ist. Bei den Geschichte mit dem "unsicher" reicht meiner Meinung das "um" auch aus. Die tausend anderen möglichen Fälle will ich überhaupt nicht maschinell in einer Datenbank erfassen. Sonst müsste man ja noch Quellenangaben und Kommentare in dem Datumsfeld zulassen, was meiner Meinung nach über das Ziel hinausschießt. "um 12. März 456 oder um 13. Februar 457" ist völlig ausreichend an Informationen. Man kann die Datumsangabe nutzen oder man lässt es sein, weil man ja aus dem "um" schon sieht, dass es unsicher ist. Was braucht man mehr? -- sk

Es geht um mehrere Punkte unterschiedlicher (Reihenfolge: größere -> geringere) Wichtigkeit :

• 'Unsicher' vers. 'um': Unzweifelhaft sind wir einig, dass es unzulässig ist, bewußt falsche Informationen in die PD einzutragen. Wie kann es dann aber an dieser Stelle Differenzen geben? Eine Vermutung drängt sich auf: Wir verwenden 'um' (mit Zahlen, konkret Zeiten) verschieden. Vielleicht durch verschiedene Herkunftsregion (Mecklenburg/Lausitz) bedingt? Für mich jedenfalls hat 'um' sehr wenig mit 'unsicher' zu tun, dafür sehr viel mit 'ungenau'. Ich könnte also nie eine Angabe 'wohl 475' in 'um 475' ändern - das hielte ich für Eintragung einer falschen Information. (Ohne eine Notation für 'unsicher' könnte ich eine solche PD nicht bearbeiten, in eigenen Artikeln müsste ich das Feld frei lassen.)
• 'Jahrhundert' ja/nein: Gewiss, es geht ohne. Zwar ist 'zwischen 1400 und 1500' schlechter als '15. Jahrhundert', da eine nicht vorhandene Genauigkeit vorgegaukelt wird - aber es ist nicht direkt falsch. Wenn aber in Deinen Fehlerlisten 346 mal die Jahrhundert-Angabe genutzt wird, so müssen m.E. sehr starke Argumente gegen die Zulassung vorgebracht werden, um sie abzulehnen. Die maschinelle Auswertung wird durch die Jahrhundertangabe wenig erschwert. (Mein Syntaxversuch versucht bereits, das zu berücksichtigen: 'jahrhundertzahl := 1..31'. Wenn in der Syntax "Jahrhundert" formal als Monatsname behandelt wird, zudem

jahresangabe := jahreszahl [" v. Chr."]

ersetzt wird durch

jahresangabe := [jahreszahl] [" v. Chr."]

und 'etwa 4. Jahrhundert' durch das stilistisch schlechtere 'um 4. Jahrhundert', kann von erschwerter Auswertung wohl gar nicht mehr die Rede sein.)

• 'Anfang', 'Herbst' etc.: Zwingend ist der Wunsch hiernach nicht. Ich plädiere jedoch dafür, potentiell wertvolle Information nicht ohne guten Grund zu löschen. Information zu löschen ist leicht, sie wiederherzustellen schwer. Solange diese Information nicht benötigt wird, kann ein Parser einfach Wörter aus einer vorgegebenen Liste ('Anfang', 'Herbst', etc.) als zu ignorierenden Kommentar behandeln.

--Griot 18:59, 23. Feb. 2008 (CET)

Nur damit wir mal über konkrete Zahlen reden können, habe ich mal die Sachen gezählt. Die Zahlen zeigen eigentlich das es sich nur bei "Jahrhundert" überhaupt lohnt zu diskutieren. Alles andere kann problemlos gestrichen werden.

      Notiz                   Anzahl  Prozent
 1    Gesamtzahl              196950  100
 4    Datum mit Jahrhundert      630    0,32
 5    Datum mit Anfang            36    0,02
 5    Datum mit Ende              33    0,02
 5    Datum mit Mitte              7    0
 6    Datum mit Frühling           2    0
 6    Datum mit Herbst            16    0,01
 6    Datum mit Sommer            16    0,01
 6    Datum mit Winter             4    0
 7    Datum mit Früh               2    0
 7    Datum mit Spät               1    0 

Zu "Jahrhundert" ist meine Meinung: "Keine Ausnahme vom bisherigen Format". -- sk 21:14, 26. Feb. 2008 (CET)

Zu 'Anfang', ... 'Spät': vermutlich richtig. Meine Daten sind bis zum 28.2. fertg. Dann weiteres. --Griot 07:52, 27. Feb. 2008 (CET)

Ich setze die Diskussion unten im Abschnitt "Datum" fort. --Griot 01:50, 6. Mär. 2008 (CET)

Einzeldiskussion: Name

Ich muss hier nochmal eine kleine Diskussion anstoßen. Ich glaube wir sollten ein paar mehr Beispiele auf der Hilfeseite für dieses extrem wichtige Feld angeben. Ich fang mal hier eine Tabelle an, die einige problematische Artikel enthält und die wir am Ende auf die Hilfeseite als Beispiel kopieren können. Ich versuche dabei alle auftretenden Problemfelder anzuschneiden. Aus Erfahrung mit den Daten weiß ich, dass es unendlich viele Möglichkeiten gibt, einen Namen zu schreiben und dabei nicht der korrekten Lösung zu entsprechen. Sollten euch weitere Problemefälle einfallen ergänzt bitte die Tabelle. Falls ihr Fehler findet korrigiert diese bitte. -- sk 07:08, 27. Feb. 2008 (CET)

Typ	Artikellema	Datenfeld NAME (Falsch)	Datenfeld NAME (Richtig)	Datenfeld ALTERNATIVNAME
Normalfall	Ferdinand Magellan		Magellan, Ferdinand
Zweiter Vorname	Karl Heinz Burmeister	Burmeister, Karl Burmeister, Heinz	Burmeister, Karl Heinz
Zweiter Familienname	Francisco Colorado	Hernández, Francisco Colorado	Colorado, Francisco	Colorado Hernández, Francisco
Geburtsnamen	Maria Janitschek		Janitschek, Maria	Tölk, Maria (Geburtsname); Stein, Marius (Pseudonym)
Bekannter Name	Steffi Graf		Graf, Steffi	Graf, Stefanie Maria (voller Name)
Adelsprädikat	Annette von Droste-Hülshoff	Droste, Annette von Hülshoff, Annette von	Droste-Hülshoff, Annette von
Präposition (de)	Charles de Gaulle	Charles de Gaulle De Gaulle, Charles	Gaulle, Charles de
Artikel romanischen Ursprungs (Le, La)	Pierre L’Enfant	Enfant, Pierre L'	L’Enfant, Pierre
Präposition und Artikel	Michel de l’Hôpital	de L’Hôpital, Michel De L’Hôpital, Michel	L’Hôpital, Michel de
Präpositionen (mehrere)	Constantijn Theodoor van Lynden van Sandenburg		Lynden van Sandenburg, Constantijn Theodoor van	Sandenburg, Constantijn Theodoor van Lynden van
Adelsprädikat (mehrere)	Clemens von Brentano di Tremezzo		Brentano di Tremezzo, Clemens von
Adelsprädikat (mehrere)	Maria Anna von und zu Dalberg		Dalberg, Maria Anna von und zu
Präposition (niederländisch)	Jan ter Borch	ter Borch, Jan Ter Borch, Jan	Borch, Jan ter
Präposition und Artikel (niederländisch)	Jan van Ruysbroeck	van Ruysbroeck, Jan	Ruysbroeck, Jan van
Namenszusatz (belgisch)	Jean-Claude Van Damme	Damme, Jean-Claude Van	Van Damme, Jean-Claude
Namenszusatz (englischsprachig)	William Van Horn	Horn, William Van	Van Horn, William
Adelsprädikat	Alphonse d'Ornano		?
Adelsprädikat (Earl)	Edward Geoffrey Smith Stanley, 14. Earl of Derby		Stanley, Edward Geoffrey Smith	Derby, 14. Earl of
Adelsprädikat (Sir)	Thomas Beecham	Sir Thomas Beecham	Beecham, Thomas	Beecham, Sir Thomas
Mittelalterlicher Name	Wolfram von Eschenbach	von Eschenbach, Wolfram Eschenbach, Wolfram von	Wolfram von Eschenbach
Künstlernamen	Heino	Heinz Georg Kramm	Heino	Kramm, Heinz Georg (eigentlicher Name)
Künstlernamen	E.K.R.	Thomas Bollinger Bollinger, Thomas	E.K.R.	Bollinger, Thomas (eigentlicher Name)
Künstlernamen	50 Cent	Jackson, Curtis Cent, 50	50 Cent	Jackson, Curtis (eigentlicher Name)
Klammerausdruck	Culen (Schottland)	Culen (Schottland)	Culen
Klammerausdruck	Griot (Rapper)	Griot (Rapper)	Griot
Klammerausdruck	Jan Marek (1947)	Jan Marek Marek, Jan (1947) Marek (1947), Jan	Marek, Jan
römische Ziffern	Chosrau IV.	Chosrau IV., Chosrau	Chosrau IV.
römische Ziffern und Klammer	Harald II. (England)	II., Harald (England) II. (England), Harald Harald II. (England)	Harald II.
Sonderzeichen	Fûzulî	Fuzuli	Fûzulî
Namenszusatz Junior/Senior	Larry Mullen Junior	Mullen, Larry, Junior Mullen Junior, Larry	Mullen, Larry Junior
Namenszusatz der Jüngere/der Ältere	Lucas Cranach der Jüngere	Cranach der Jüngere, Lucas	Cranach, Lucas der Jüngere
Namenszusatz (Akademischer Grad)	Rupert Scholz	Scholz, Prof. Dr. Rupert Prof. Dr. Scholz, Rupert Scholz, Rupert (Prof. Dr.)	Scholz, Rupert
Namenszusatz (Mandatskürzel)	Guido Westerwelle	Westerwelle, Guido MdB Westerwelle MdB, Guido MdB Westerwelle, Guido	Westerwelle, Guido
asiatische Namen (Familienname zuerst)	Deng Pufang	Pufang, Deng	Deng Pufang
Arabischer Name	Abraham ibn Daud		Daud, Abraham ibn
Arabischer Name	Abd al-Mumin		Al-Mumin, Abd
Arabischer Name	Al-Arqam ibn Abi 'l-Arqam		?

Einige Verbesserungsvorschläge:

• Bei mehreren Adelsprädikat würde ich so vorgehen:
  • Constantijn Theodoor van Lynden van Sandenburg -> Lynden van Sandenburg, Constantijn Theodoor van
  • Clemens von Brentano di Tremezzo -> Brentano di Tremezzo, Clemens von
  • Maria Anna von und zu Dalberg -> Dalberg, Maria Anna von und zu
• van:
  • Jan van Ruysbroeck -> Ruysbroeck, Jan van
  • Ludwig van Beethoven -> Beethoven, Ludwig van (Man sagt "Beethoven komponierte dies und jenes." nicht "Van Beethoven komponierte ...")
  • aber: Jean-Claude Van Damme -> Van Damme, Jean-Claude (Man sagt "Van Damme spiele in diesem oder jenem Film." nicht "Damme spielte in diesem oder jenem Film." Der Unterschied wird auch in der Großschreibung des Van deutlich. Dann ist das Van Teil des Familiennamens (hauptsächlich bei Belgiern), ansonsten Adelsprädikat oder zeigt örtliche Herkunft an.)
• Klammerausdrücke würde ich nie in die Personendaten schreiben, wenn der Klammernausdruck Teil der Wikipediaspezifikation sind, weil die kein Namensbestandteil sind. Falls es doch mal vorkommen sollte, dass jemand einen Namen/Künstlernamen/Notnamen mit Klammer hat (wofür mir kaum Beispiele einfallen, nur An(jotef) und (.)p(...)nin), kann die Klammer natürlich verwendet werden.
• Namenszusatz Junior/Senior: ist kein Bestandteil des Familiennamens, ähnlich wie "der Ältere" und "der Jüngere", deshalb: Larry Mullen Junior -> Mullen, Larry Junior; Lucas Cranach der Ältere -> Cranach, Lucas der Ältere

--Ephraim33 17:19, 27. Feb. 2008 (CET)

Die Regelung zu Adelsprädikaten laut RAK [1] ist: Namen nicht regierender Fürsten usw. der Neuzeit werden wie moderne Familiennamen behandelt. Das ist auch sonst üblich. Warum soll hier davon abgewichen werden?

Außerdem sind hier Namensteile als Adelsprädikat angeführt, die keine sind: De Gaulle: Sein Familienname enthält zwar kein Adelsprädikat, aber einen Formdialekt des Artikels. Adelsprädikat: Niederländische Namensbestandteile wie van („von“), de („der“), ter („zur“), usw. deuten nicht auf Adel hin. Das Prädikat für den untitulierten Adel ist das dem Vornamen vorangestellte Jonkheer, z. B. jhr. Marinus van der Goes van Nater. --08-15 21:32, 29. Feb. 2008 (CET)

Hallo 08-15, genau weil ich bei einigen nicht weiß wie es genau korrekt gemacht wird, hab ich diese Tabelle aufgestellt. Da sollen Leute die Ahnung haben die Namen korrekt eintragen. Bitte korrigiere die Tabelle. Ich glaube nicht nur mir sondern auch einer ganzen Reihe weiterer Leute wäre damit sehr geholfen. Die jetzigen Beispiele auf der Projektseite reichen bei weitem nicht aus. -- sk 09:07, 1. Mär. 2008 (CET)

Ich habe einige korrigiert. --08-15 10:26, 1. Mär. 2008 (CET)

Anmerkungen: 1. verstehe ich nicht, wieso Klammern aus Lemmata in das Namensfeld aufgenommen werden sollten. Culen (Schottland) heißt halt Culen, gleiches gilt für den Rapper in der Liste. Das finde ich so nicht in Ordnung. 2. Bei den Beispielen wird fast nie eine Erläuterung zum Alternativnamen angegeben. Diese sollte meiner Meinung nach so oft wie möglich auftauchen (sollte aber auch keine Sache sein, die Pflicht ist, aber in den Beispielen sollten wir das angeben). Also: "Graf, Stefanie Maria (voller Name)" oder "Kramm, Heinz Georg (echter Name)". Über empfohlene Erläuterungen sollten wir uns noch Gedanken machen. --APPER\^☺☹ 19:03, 1. Mär. 2008 (CET)

Auch an dich APPER die Einladung: Ändere so viel wie du möchtest, damit wir uns da mal auf einige Regel einigen. Die Überlegung zu den Klammerwerten war einfach die, dass man später mal in einer Liste 20x "Friedrich I." hat und dann es vielleicht zusätzlich informativ wär direkt noch die Klammerangabe zu haben "Friedrich I. (Dänemark)". - Das mit der Standardisierung der Klammerausdrücke (Pseuydonym etc.) finde ich auch super. Wir sollten mal eine Liste aller Varianten aufbauen. -- sk 22:21, 1. Mär. 2008 (CET)

Okay, ich hab mal einige Klammerzusätze ergänzt. Die Klammerzusätze "Rapper", "Dänemark" etc. kann ich jedoch nicht gutheißen. Zur Unterscheidung mehrerer Friedrichs (die einfach so hießen!) gibts dann das Feld Kurzbeschreibung. Wenn man eindeutige Unterscheidungen will, dann nimmt man halt evtl. Klammerzusätze aus dem Lemma dazu. Im Namensfeld spreche ich mich strikt dagegen aus. --APPER\^☺☹ 12:25, 2. Mär. 2008 (CET)

Ich habe die Klammerzusätze, die keine Namensbestandteile waren, aus dem Namensfeld entfernt. Außerdem das Junior nicht mehr zum Familiennamen gezählt und einen Vorschlag für "Edward Geoffrey Smith Stanley, 14. Earl of Derby" gemacht. --Ephraim33 19:26, 7. Mär. 2008 (CET)

Wie ist es denn bei Alphonse d'Ornano: Sollte eigentlich analog zu Charles de Gaulle gehen, weil ebenso Präposition (nur wegen des vokalischen Anlautes verkürzt), so dass im Namensfeld Ornano, Alphonse d’ richtig wäre. Aber ist das so gewollt? Bei mir sträubt sich da was. Joyborg 10:06, 10. Mär. 2008 (CET)

Viel Arbeit, aber extrem wichtig

Ok, meine Fehlerliste erfreut sich ja großer Beliebtheit und es sind schon Hunderte von Artikeln korrigiert worden. Besten Dank an alle Helfer. Nun kommt aber ein dicker Brocken Arbeit auf uns zu. Ich habe bei den Datumsangaben 4484 Personen gefunden die z.B. nur ein Jahreszahl z.B. "1789" oder einen Tag und Monat z.B. "18. Februar" in den Datumsfeldern stehen haben, aber im Artikeltext sich eindeutig vor den Jahrszahlen Monate bzw. nach den Monaten Zahlen befinden. Hier wurden also extrem wichtige Datumsinformationen unterschlagen. Ihr findet die vollständige Liste hier Wikipedia:Personendaten/Wartung/Fehlerliste2. Bitte helft alle mit die Daten zu ergänzen und löscht erledigtes aus der Liste. Diese Liste wird von mir nicht automatisch aktualisiert (zu hoher Zeitaufwand). Erst wenn sie abgearbeitet ist, werde ich sie wieder in die automatisch aktualisierte Liste mit aufnehmen. -- sk 23:10, 9. Mär. 2008 (CET)

Wo wir grad dabei sind: Ich weiß nicht, ob ihr meine Kategorien-Fehlerliste schon entdeckt habt: Hilfe:Personendaten/Wartung/Kategorien. Dort wurde abgeglichen, ob das Geburts- bzw. Sterbejahr der Personendaten mit dem entsprechenden Geburts- und Sterbejahr der Kategorien übereinstimmt (nur einseitig: fehlen die Kategorien gibts keinen Fehler, gibt es jedoch bspw. eine Gestorben-Kategorie aber keine entsprechende Angabe in den Personendaten ist das ein Fehler). Leider sind das auch über 2600 Fälle. Nachdem ich jetzt so 200 abgearbeitet hab lässt sich sagen: rund die Hälfte sind Kategorienfehler, die andere Hälfte Personendaten-Fehler. Gefixt werden sollte es so oder so. Also falls ihr Abwechslung braucht ;). Die Abarbeitung geht relativ schnell und ist relativ einfach, da es wenig komplizierte Fälle gibt... --APPER\^☺☹ 23:30, 9. Mär. 2008 (CET)

Achja und Danke an Stefan. Solch eine Prüfung wäre meine nächste Aktion nach der Abarbeitung der Kategorien-Fehler gewesen ;). Du hast mir also 'ne Menge Arbeit erspart ;) --APPER\^☺☹ 23:31, 9. Mär. 2008 (CET)

Die Idee mit den Kategorien ist nicht schlecht. Mein nächster Schritt sollte eigentlich die Ortschaften sein. Ich wollte Prüfen ob die im Text vorhanden sind oder nicht. Ich denke da sind auch noch eine Menge Fehler enthalten. Aber gemeinsam werden wir die Daten schon hinbekommen. Das mit den Kategorien werde ich mir jetzt mal überlegen, wie man da mein Skript erweitern kann. Mir schwebt auch ein Test vorhandener Kategorien vor, ob da noch Personen sind, die überhaupt keine Personendaten haben. Denn diese Fallen derzeit bei uns noch total durch das Raster. -- sk 21:00, 10. Mär. 2008 (CET)

Ich glaube, es gibt auch eine nicht kleine Anzahl (Schätzung: rund 800), die Personendaten aber keine Kat:Mann/Kat:Frau haben. Zu den fehlenden Personendaten: es gibt ja seit inzwischen über 3 Jahren mein Vorschlagsscript, das derzeit noch über 600 Personen-Artikel ohne PD mit Personendaten-Vorschlag liefern kann. Also ich glaube an der Stelle fehlt es derzeit einfach an "Personal", sprich Leuten, die das einfach mal tun. Auf lange Sicht werden wir das schon gebacken kriegen, auch wenn ich dank deiner Fehlerlisten langsam Bedenken hab, die Qualität dauerhaft hoch halten zu können ;). Aber wir haben auch erst sehr spät mit der Qualitätssicherung angefangen, aber dank Dir scheint sie ja jetzt zu laufen :) --APPER\^☺☹ 00:03, 11. Mär. 2008 (CET)

Kurzbeschreibung bei Lebenden und Toten, Aktiven und Ruheständlern

Z. B. Bernhard Mende. Der Mann ist zur Zeit schon tot; in seiner Kurzbeschreibung steht "General a.D. und ehemaliger Inspekteur der Luftwaffe". Bei Gaius Iulius Caesar, schon deutlich länger tot, steht aber "römischer Staatsmann, Feldherr und Autor", nix von "ehemaliger" oder "a.D."

Ich sehe drei typische Fälle:

• Noch lebend und aktiv: "Eishockeyspieler"
• Noch lebend und nicht mehr aktiv oder im Ruhestand: "ehemaliger Eishockeyspieler"
• Schon tot und nicht mehr aktiv: "Eishockeypieler"

Statt "Eishockeyspieler" kann man sich natürlich auch "Politiker", "Manager", "Inspekteur der Luftwaffe" oder "Richter am Bundesgerichtshof" denken.

Oder sollen wir einfach in allen drei Fällen jeweils nur "Eishockeyspieler" schreiben, jedenfalls wenn das die markanteste Beschreibung ist?

Gibt's hierzu einen (bekannten) Konsens?

--Frank C. Müller 20:28, 10. Mär. 2008 (CET)

Soweit ich weiß, haben wir da noch nicht drüber diskutiert. Ich bin der Meinung, dass wir alle Wort wie "ehemalig" entfernen sollten. Gagarin ist zwar ein ehemaliger Kosmonat, aber niemand würde das so schreiben. Außerdem müssten wir ständig die Kurzbeschreibung überall anpassen. Wenn man wirklich möchte, dass das ehemalig mit drin auftaucht, dann so: Gerhard Schröder = "deutscher Politiker (SPD) und Bundeskanzler (1998 - 2005)". Andere Meinungen? -- sk 21:05, 10. Mär. 2008 (CET)

Ich hatte mich das auch schon gefragt und nichts gefunden, was FÜR das ehemalig spricht. Es ist entscheidend wodurch jemand bekannt geworden ist, nicht ob er/sie das aktuell noch ausübt. Aber ein entscheidendes Argument DAGEGEN wäre die Aktualisierungsarbeit (incl. der Frage, wann genau jemand ehemalig etwas war). Ich habe die "Ehehemaligs" daher bisher immer rausgeworfen, wenn sie mir begegnet sind. Joyborg 22:16, 10. Mär. 2008 (CET)

Ich habe genau die Meinung meiner Vorredner in den letzten Jahren immer als de-facto-Standard gesehen und "ehemalige" immer entfernt. Grüße --APPER\^☺☹ 00:04, 11. Mär. 2008 (CET)

Datum

In den Feldern GEBURTSDATUM und STERBEDATUM wird das Datum wie in der Wikipedia üblich wie 12. Januar 1323 eingetragen und nicht TT.MM.JJJJ (z. B. 12. 01. 1923). Ist nicht das volle Datum bekannt, sind auch die Angaben März 1323, nur 1323 oder gar 14. Jahrhundert korrekt.

Siehe auch: Datumskonventionen

Spezielle Regeln, vor allem für ungenaue Datumsangaben, nennt folgende Tabelle:

falsch	richtig	Bedeutung & Bemerkungen
[[3. April]] [[1940]]	3. April 1940	Datumsfelder sollten nicht verlinkt sein. Ein Artikel sollte aber nicht geändert werden, nur um einen solchen Link zu tilgen. Die Beseitigung ist jedoch erwünscht, wenn ein Artikel ohnehin verändert wird.
4. Jänner 1234 4. 1. 1234 04. Januar 1234	4. Januar 1234	einheitliche Schreibweise, um automatische Auswertung zu erleichtern
123 v. u. Z. 123 v. d. Z.. 123 v.Chr.	123 v. Chr.	dito
123 n. Chr. 123 u. Z.	123	dito
333/32 v. Chr.	333/332 v. Chr.	ein Jahr einer anderen Zeitrechnung (griechisch/islamisch/iranisch/etc.), welches durch zwei aufeinanderfolgende julianische oder gregorianische Jahre, - durch "/" getrennt - wiedergegeben wird; nicht gemeint ist: '333 v. Chr. oder 332 v. Chr.'; neben dem "/" sollte kein Leerzeichen stehen
3./4. Mai 567	3. Mai 567 oder 4. Mai 567
2. Hälfte des 9. Jh. Ende des 9. Jahrhunderts	9. Jahrhundert	Vergröberung, um automatische Auswertung zu erleichtern
Frühjahr 43 v. Chr. 2. Hälfte 43 v. Chr. Spätsommer 43 v. Chr.	43 v. Chr.	dito
lebte im späten 9. und frühen 10. Jahrhundert	9. Jahrhundert 10. Jahrhundert	für GEBURTSDATUM für STERBEDATUM
	vor 837 vor 18. Juli 837	'vor' schließt hier immer das angegebene Datum mit ein
	nach 837 nach 18. Juli 837	'nach' schließt hier immer das angegebene Datum mit ein
837-843 nach 3. Mai 93 und vor 5. Mai 103	zwischen 837 und 843 zwischen 3. Mai 93 und 5. Mai 103	'zwischen' schließt hier immer beide angegebenen Daten mit ein
gegen 837 etwa 837 circa 837 ~837	um 837 um 8. Juli 837	(kleines) Intervall um das angegebene Datum
	6. Mai vor 987 6. Mai nach 987 6. Mai zwischen 987 und 993 6. Mai um 987	der Tag ist bekannt, das Jahr nicht genau
um 872/5	um 872/875	gemeint ist: 'um den Zeitraum 872-875'; dies sollte ausschließlich nach 'um' verwendet werden, für andere Fälle ist 'zwischen' richtig; neben dem "/" sollte kein Leerzeichen stehen
940 od. 945 3. oder 9. April 940 3. April oder Mai 940 3./4. Jahrhundert	940 oder 945 3. April 940 oder 9. April 940 3. April 940 oder 3. Mai 940 3. Jahrhundert oder 4. Jahrhundert	'oder' soll nur zwischen vollständigen Daten stehen, nicht zwischen Tagen oder Monatsnamen; mehr als zwei Alternativen sind zulässig
dokumentiert 1108 bezeugt 1108 erwähnt 1108 nachweisbar seit 1108	vor 1108	(für GEBURTSDATUM:) nur die Angabe 'getauft' ist hier vorgesehen.
verschollen 1245 vermisst 1245	nach 1245	(für STERBEDATUM:) nur die Angabe 'begraben' ist hier vorgesehen.
geboren Mai 1705 und getauft 17. Mai 1705 17. Mai 1705 (Taufe)	getauft 17. Mai 1705	'getauft' bezieht sich auf die gesamte Datumsangabe, es kann nur am Anfang stehen
beerdigt 14. Juni 1705 14. Juni 1705 (Beerdigung) 14. Juni 1705 (Begräbnis)	begraben 14. Juni 1705	entsprechend
wahrscheinlich 1460 vermutlich 1460 wohl 1460 1460(?)	1460 (unsicher)	'(unsicher)' bezieht sich auf die gesamte Datumsangabe, es kann nur am Ende stehen
3.(?) März 1460 3. März(?) 1460 3. März 1460(?)	3. März 1460 (unsicher)	dito

Bis 1918 galt in Russland der Julianische Kalender. In den Personendaten sollte ausschließlich das Datum nach dem Gregorianischen Kalender verwendet werden. Im Artikel selbst können beide Datumsangaben stehen. Siehe hierzu: Umrechnung zwischen Julianischem und Gregorianischem Kalender und Vorlage:JULGREGDATUM. --Griot 22:45, 9. Mär. 2008 (CET)

Was mache ich denn mit dem Geburtsdatum "16. Februar 19xx" im Artikel Sakura Tsukuba? -- Harro von Wuff 01:36, 10. Mär. 2008 (CET)

Etwa "16. Februar zwischen 1900 und 1999". Wenn man den Text durchliest, kann das z.B. auf - sehr vorsichtig - "16. Februar zwischen 1920 und 1980" verbessert werden. Gewiss rechtfertigt dieser sehr seltene Fall keine zusätzliche Notationsform. Natürlich können sich aber noch Lücken zeigen. --Griot 07:16, 10. Mär. 2008 (CET)

Da keine weiteren Bemerkungen kamen, habe ich den (nur unwesentlich geänderten) Text in die Personendaten-Beschreibung übertragen. Eine Zusatzbemerkung folgt in einem neuen Abschnitt. --Griot 10:56, 12. Mär. 2008 (CET)

Soll-Bestimmung: gregorianisches Datum

Die Forderung ist leichter gestellt, als erfüllt. Es fehlen einige Hilfsmittel. Speziell: eine Liste, wann in welchen Territorien Deutschlands, Österreichs und der Schweiz (und möglichst auch anderer Länder) der greg. Kalender eingeführt wurde. Z.Zt. findet man in der Wikipedia nur Formulierungen wie "beispielsweise", "in vielen", etc. Vielleicht könnte sie irgendwo (wo?) angelegt werden? (Natürlich heißt 'Einführung' noch nicht 'Benutzung', aber das ist ein anderes [komplizierteres] Thema.) --Griot 11:57, 12. Mär. 2008 (CET)

Hier mal ein Link wann wo der Gregorianische Kalender eingeführt wurde [2].--
--Randalf _Post ^{Wertung Vertrauen} 20:17, 23. Sep. 2008 (CEST)

Wahrscheinlich muss man über die Person selbst herausfinden, ob gregorianischer oder julianischer Kalender benutzt wurde, d.h. die Quellen des Artikels auswerten. --Ephraim33 16:04, 12. Mär. 2008 (CET)

Ja. Um das zu können, wäre eine solche Liste nützlich. Vermutlich findet sich aus jedem der damals vielen Stücke Deutschlands jemand, der diese Daten besitzt und eingeben könnte. Oder einfacher: irgendwo existiert solche Liste bereits. --Griot 18:00, 12. Mär. 2008 (CET)

Evtl. notwendige Erweiterungen

Es sollte mit notwendigen Erweiterungen des Formats gerechnet werden. Das betrifft vor allem:

• die Einleitung mit z.Zt. "getauft"/"begraben": dies ist offensichtlich zu stark auf eine christliche Kultur zugeschnitten
• den Abschluss mit '(unsicher)': wenn - wie zu befürchten - nicht selten nicht feststellbar ist, ob ein vorliegendes Datum julianisch oder gregorianisch ist, böte sich ein alternative Angabe an: '(julianisch oder gregorianisch)'. Denkbar wäre auch, in eine solche Klammer einen Hinweis auf die Zeitrechnung ('griechisch', etc.) aufzunehmen.

Da beide genannten potentiellen Erweiterungen im Datum lokal begrenzt sind, kann auswertende Software sich gewiss bereits darauf einstellen.

Es scheint jedoch angebracht zu sein, zunächst mit der jetzigen Form Erfahrungen zu sammeln. --Griot 11:57, 12. Mär. 2008 (CET)

Schon das "(unsicher)" finde ich überflüssig. Noch mehr lokal begrenze Klammerzusätze zu erlauben, halte ich für wenig sinnvoll. --Ephraim33 16:04, 12. Mär. 2008 (CET)

Zu "(unsicher)" s. meine Antwort auf Deiner Diskussionsseite (oder die Diskussionen in früheren Abschnitten). Das übrige sollte - wie gesagt - vorerst nicht geschehen. Es ist aber gut, gerade für Softwareentwicklung, eventuelle Weiterentwicklungen abschätzen zu können. --Griot 18:05, 12. Mär. 2008 (CET)

Vergröberung der Daten

Da einige Daten - "Sommer", "Anfang", etc. - gegenüber bisherigem Gebrauch (nicht: gegenüber bisherigen Regeln) wegfallen, könnte es Sinn machen, sie in einem Kommentar standardisierter Form hinter (NICHT: in) den Personendaten für eventuelle künftige Nutzung aufzubewahren. Entsprechend könnte mit Zusatzbemerkungen zu anderen Feldern der PD verfahren werden. --Griot 11:57, 12. Mär. 2008 (CET)

Auch das halte ich nicht für sinnvoll. Im Fließtext steht die Information. Und ich glaube auch kaum, dass jemand den Aufwand der Programmierung unternimmt, die Kommentare zu prüfen, nur um zu wissen, dass jemand "Anfang 1423" geboren wurde, wenn er aus den Personendaten schon "1423" frei Haus geliefert bekommt. --Ephraim33 16:04, 12. Mär. 2008 (CET)

Nun, es geht ja nur um Kommentar. Solange die aufbewahrte Information nicht genutzt wird, schadet sie jedenfalls nicht. Wer weiß schon, ob man sie in 10 Jahren nicht doch gern hätte. Aber wichtig ist dieser Punkt natürlich nicht. --Griot 18:09, 12. Mär. 2008 (CET)

Kurzbeschreibung bei deutschen Politikern

Hallo,

wir haben eine Unmenge deutscher Politiker (bzw. das trifft auch auf andere Nationalitäten zu), die Kurzbeschreibung ist aber oft unterschiedlich. Um genau zu sein gibt es drei Varianten:

• deutscher Politiker
• deutscher Politiker (SPD)
• deutscher Politiker der SPD

Ich denke, dass die Angabe der Partei nicht schaden kann, auch wenn man dies sicher nicht immer machen kann (Parteiwechsel etc.). Die erste Variante wird also sicher immer erhalten bleiben. Ich würde nur gerne eine der anderen Varianten langfristig entfernen. Ich tendiere zur Klammerschreibung, wollte dies aber hier erstmal kurz diskutieren. Was sagt ihr dazu? Sprich: falsch: "deutscher Politiker der SPD", richtig: "deutscher Politiker (SPD)". --APPER\^☺☹ 18:11, 9. Mär. 2008 (CET)

Klingt sinnvoll. Schon allein deshalb, weil so ein Klammerlemma nicht notwendigerweise eine Mitgliedschaft bedeuten muss, daher also vielseitiger einsetzbar ist. -- Perrak 18:16, 9. Mär. 2008 (CET)

• Amerikanischer Politiker (Republikaner)
• Amerikanischer Politiker (Demokraten)
• Otto Schily?

fragt --Matthiasb 18:19, 9. Mär. 2008 (CET)

Hee super Klasse!!! Ich wollte das auch vorschlagen. Mein Favorit ist die Klammer. Schilly = deutscher Politiker (Grünen, SPD). Diese Variante mit Komma haben wir schon mehrfach. US-Amerikanische Politiker würde ich auch so verarzten. Ich unterstütze den Vorschlag total. -- sk 23:04, 9. Mär. 2008 (CET)

Also:

• US-amerikanischer Politiker (Republikaner)
• deutscher Politiker (Grüne, SPD)

--APPER\^☺☹ 23:09, 9. Mär. 2008 (CET)

Seltsam, ich schreibe immer und überall SPD-Politiker, alles andere ist nicht sonderlich gebräuchlich. Da Schily nicht beides gleichzeitig ist/war, ist er auch SPD- (wie in der Einleitung) oder neutral nur "Politiker". Politiker der xxx(-Partei) ist noch akzeptabel, z.B. bei US, Klammern sind aber immer ungut, die Lesen sich nämlich unnatürlich. Auch wenn es hier nur um einen Datensatz geht, die direkte Beziehung zur Einleitung ist ja gegeben. -- Harro von Wuff 23:31, 9. Mär. 2008 (CET)

Zur Information: Ich hab mal nach "-Politiker" und nach "Politiker (" gesucht. Ersteres wird nur ca 350 Mal gefunden letzteres ca 4000 Mal. -- sk 22:54, 14. Mär. 2008 (CET)

ALTERNATIVNAMEN - Sprachkennzeichnung

Die Durchsicht der ALTERNATIVNAMEN der Personendaten ergibt (Stand: Dump vom 20.2.2008) die nachfolgend dargestellte Situation für die verwendeten Sprach- und Schriftbezeichnungen. Die bisherige Verwendung ist jedoch unregelmäßig - es werden Sprachnamen und Sprachadjektive, Vollformen und unterschiedliche Abkürzungen verwendet.

Ein guter Bezugspunkt für eine Regelung könnte die Liste der Sprachen in Wikipedia:Sprachen#Alle_Wikipedias - im weiteren 'wiki-Liste' - sein. Grundregel evtl.: Namen aus dieser Liste, aber in adjektivischer Form, keine Abkürzungen. Abweichungen sind aber notwendig - s. unten.

Folgende Sprachen der wiki-Liste werden z.Zt. in ALTERNATIVNAMEN genannt (der Sprachname ist hier, wo möglich, durch das Sprachadjektiv ersetzt):

abchasisch	albanisch	altgriechisch	arabisch	aragonesisch	armenisch	aserbaidschanisch	baskisch
bengalisch	birmanisch	bulgarisch	chinesisch	dänisch	deutsch	englisch	estnisch
färöisch	finnisch	französisch	galicisch	georgisch	griechisch	hebräisch	Hindi
irisch	isländisch	italienisch	japanisch	jiddisch	Kannada	kantonesisch	kasachisch
katalanisch	kirgisisch	koreanisch	korsisch	kroatisch	kurdisch	Latein	lettisch
litauisch	marathi	mazedonisch	mongolisch	niederländisch	norwegisch	ossetisch	persisch
polnisch	portugiesisch	Quechua	rumänisch	russisch	schottisch-gälisch	schwedisch	serbisch
singhalesisch	sizilianisch	slowakisch	slowenisch	Somali	spanisch	Tamil	tatarisch
thailändisch	tibetisch	tonganisch	tschechisch	türkisch	uigurisch	ukrainisch	ungarisch
Urdu	walisisch	weißrussisch

Bei folgenden Sprachen der wiki-Liste wäre es vielleicht sinnvoll, eine alternative Schreibweise - die bereits verwendet wird - zu respektieren:

wiki-Name	Alternative
Latein	lateinisch
schottisch-gälisch	schottisch
Somali	somalisch
Tamil	tamilisch
uigurisch	uighurisch

In folgenden Fällen werden Sprachpräzisierungen angegeben, die sicher auch sinnvoll sind:

• arabisch-sudanesisch
• russisch-kirchenslawisch

Dies ist gewiss noch für viele andere Fällen angemessen, z.B. für:

• norwegisch-Bokmål
• norwegisch-Nynorsk

Folgende lebende Sprachen fehlen in der wiki-Liste, werden aber bereits verwendet, sollten wohl möglich sein:

• flämisch
• gascognisch
• lothringisch
• sorbisch

Alte Sprachen, bereits verwendet, die anzugeben möglich sein muss:

• akkadisch
• altägyptisch
• altpersisch
• babylonisch
• elamisch
• koptisch
• langobardisch
• medisch

Sprachanpassungen, bereits verwendet, die wohl ebenfalls benötigt werden:

• anglisiert
• eingedeutscht
• gräzisiert
• latinisiert

Unklaren Status hat (sollte man es zulassen, wenn die genaue Sprache unbekannt ist?):

• äthiopisch

Bei einer Reihe von Sprachen sind in gewissen Fällen Zusatzangaben vorteilhaft, diese betreffen:

• traditionelle/moderne Schreibweisen
• das verwendete Schriftsystem
• die Lesung (für japanisch)

Folgende Schriftsysteme werden bisher in den ALTERNATIVNAMEN genannt:

• armenische Schrift
• arabische Schrift
• japanische Schrift
• koreanische Schrift
• kyrillische Schrift
• lateinische Schrift
• thailändische Schrift

Wo die Sprache das verwendete Schriftsystem festlegt, ist die zusätzliche Angabe des Schriftsystems kaum nötig, sollte aber wohl toleriert werden. Die Angabe des Schriftsystems kann ebenfalls unterbleiben, wenn sie in der verwendeten Sprachvorlage codiert ist, wie für Chinesisch bei der Vorlage zh.

Sehe ich recht. dass für Japanisch keine Angabe des Schriftsystems notwendig ist, da alle Teilsysteme (Kanji, Hiragana, Katakana, Rōmaji) gemischt verwendet werden? Die Zeichen identifizieren dann selbst das System, dem sie angehören. Wohl aber wird in den ALTERNATIVNAMEN zwischen On-Lesung und Kun-Lesung unterschieden, was notwendig sein dürfte.

Konkret kommen bereits folgende Fälle vor:

Sprache	Schriftsystem	alternative Schreibweise alternative Lesung	Vorschlag zur Notation
armenisch		traditionell	armenisch-traditionell
chinesisch		traditionell	chinesisch-traditionell
		vereinfacht	chinesisch-vereinfacht
	Pinyin		chinesisch-Pinyin
	Wade-Giles		chinesisch-Wade-Giles
japanisch		On-Lesung	japanisch-On-Lesung
		Kun-Lesung	japanisch-Kun-Lesung
koreanisch	Hangeul		koreanisch-Hangeul
	Hanja		koreanisch-Hanja
kasachisch	kyrillisch		kasachisch-kyrillisch
	lateinisch		kasachisch-lateinisch
serbisch	kyrillisch		serbisch-kyrillisch
	lateinisch		serbisch-lateinisch

Natürlich sind andere Bezeichnungen möglich. 'Kurzzeichen'/'Langzeichen' für Chinesisch hätten allerdings einen Nachteil: es sind keine Adjektive. Dagegen ginge '-kurz'/'-lang' auch gut.

Die 'Normalform' der Sprach- & Schriftangabe wäre also:

Notation	Beispiel
sprache	französisch
sprache-schriftsystem	chinesisch-vereinfacht
mit den Sonderfällen
sprache-sprachpräzisierung	arabisch-sudanesisch
sprache-sprachpräzisierung-schriftsystem	(kommt bisher nicht vor)
und - nur notfalls, wenn die Sprache nicht bekannt ist -
schriftsystem	Devanāgarī

Die Vorschläge orientieren sich offensichtlich an den ISO-Kürzeln ('zh-Hans', etc.), sind allerdings nicht in dem Maße festgelegt. Die Kürzel selbst statt ausgeschriebener Sprachbezeichnungen vorzuschreiben, hielte ich nicht für gut. --Griot 11:39, 17. Mär. 2008 (CET)

Japanische Namen haben eine eindeutige Aussprache. Ob das die on- oder die kun-Lesung ist oder eine Kombination interessiert in den Personendaten ganz sicher nicht. --08-15 12:07, 17. Mär. 2008 (CET)

Mag sein, ich kenne mich hier ungenügend aus. In existierenden PD erscheinen die Lesungsangaben auch nur bei den lateinischen Umschriften - vielleicht gehört das Thema eher zum Komplex Transliteration/Transkription, das ich hier noch ausgeklammert hatte? Zur Beurteilung der Fälle zunächst die 6 PD mit Angabe 'On-Lesung' (Stand: Dump vom 20.2.):

Yoshida, Mitsuyoshi    吉田 光由 (jap.); Yoshida Kōyū (On-Lesung); Yoshida Koyu    Autor eines japanischen Rechenbuches    1598    <>    1672    <>
Seki, Takakazu    関 孝和 (japanisch); Seki Kōwa (On-Lesung); Seki Kowa    japanischer Mathematiker    1637 oder 1642    Fujioka    24. Oktober 1708    <>
Ajima, Naonobu    安島 直円 (jap.); Ajima Chokuen (On-Lesung); Ajima Chokuyen (On-Lesung, veraltet)    japanischer Mathematiker    1732    <>    1798    <>
Wada, Yasushi    和田 寧 (jap.); Wada Nei (On-Lesung); Wada Yenzō Nei; Wada Enzō Nei; Kōyama Naoaki (Geburtsname)    japanischer Mathematiker    1787    Yedo, Provinz Harima    1840    <>
Aida, Yasuaki    会田 安明 (jap.); Aida Ammei (On-Lesung); Aida Anmei (On-Lesung)    japanischer Mathematiker    10. Februar 1747    <>    26. Oktober 1817    <>
Takebe, Katahiro    建部 賢弘 (jap.); Takebe Kenkō (On-Lesung); Takebe Kenko    japanischer Mathematiker    1664    <>    1739    <>

sowie der einzige Fall mit Angabe 'Kun-Lesung':

Maki, Yuko    槇 有恒 (jap.); Maki Yūkō; Maki Aritsune (Kun-Lesung)    japanischer Bergsteiger    5. Februar 1894    Sendai    2. Mai 1989    Tokio

--Griot 13:36, 17. Mär. 2008 (CET)

Das sind Fälle, in denen wohl tatsächlich mehrere unterschiedliche Aussprachen gebräuchlich sind. Das Angabe on/kun ist trotzdem nicht besonders sinnvoll, zumal es ja für viele Namen eine ganze Reihe von on-Lesungen gibt. --08-15 14:24, 17. Mär. 2008 (CET)

Vermute ich richtig, dass bei heutigen Namen jeweils nur eine Lesung üblich ist (out of topic: weiß der Japaner bei einem unbekannten Namen, welche?), dass aber bei historischen Namen Kun- und On-Lesung vorkommen können (oder u.U. gar mehrere On-Lesungen, wie bei Aida Yasuaki) - sei es, dass damals beide gebräuchlich waren, sei es, dass man nicht mehr weiß, welche benutzt wurde, sei es, dass damals zwar die eine, heute aber die andere Lesung üblich ist? Solange kein Vorlesesystem entwickelt werden soll, ist für den Namen in japanischer Schrift die Angabe On/Kun wohl tatsächlich unnötig. Für die Rōmaji-Wiedergabe scheint sie mir aber sinnvoll zu sein, da für nicht des Japanischen Mächtige sonst verborgen bleibt, dass dieselbe Namensform vorliegt, nur in anderer Aussprache. Da diese Aussprache daneben angegeben wird, ist eine Differenzierung verschiedener On-Lesungen aber wohl nicht erforderlich, oder? --Griot 19:01, 17. Mär. 2008 (CET)

Pflicht, das Feld NAME identisch mit Artikeltitel

Ich möchte hier eine einfache aber wirkungsvolle Regel vorschlagen. Da ich im Feld Name immer alle möglichen anderen Schreibweisen finde, die nicht mit dem Artikeltitel übereinstimmen, kam mir der Gedanke, dass das klar geregelt werden muss. Deshalb

• Alle Bestandteile im Artikeltitel müssen genauso mit der gleichen Schreibweise im Feld Namen auftauchen
• Alle Klammerausdrücke werden nicht eingetragen.
• Alle anderen Schreibweisen, 2. Vornamen oder andere Namen gehören in das Feld ALTERNATIVNAMEN.

Demnach wäre

• Heino
  • richtig: NAME=Heino
  • falsch: NAME=Kramm, Heinz Georg (wirklicher Name)
• Andreas Müller (Fußball)
  • richtig: NAME=Müller, Andreas
  • falsch: NAME=Mueller, Andreas
  • falsch: NAME=Müller, Andreas (Fußball)
• Hans Adolf Krebs
  • richtig: NAME=Krebs, Hans Adolf
  • falsch: NAME=Krebs, Hans Adolf Joachim Günther
  • falsch: NAME=Krebs, Hans

Der Vorteil davon wäre, dass das Feld automatisiert auf Richtigkeit überprüft werden kann. Problemfälle wären Leute wie Will.i.am die aus die wegen der Großschreibungspflicht der Artikeltitel nicht korrekt eingetragen werden können. Aber das ist nur eine sehr geringe Anzahl von Leuten der Fall. Bei solchen Leuten würde ich auf weitere Großschreibung im Feld Name pochen und zusätzlich noch die Kleinschreibung in Alternativnamen einbringen. Meinungen? -- sk 11:37, 21. Mär. 2008 (CET)

Und das Bispiel für Hans Adolf Krebs soll dann heissen dass Krebs, Hans Adolf Joachim Günther unter ALTERNATIVNAMEN hingehört ? Das Widerspricht aber der Regel "Bitte nicht sämtliche Vornamen als Alternativnamen aufführen, sondern nur jene, die, wie z. B. abweichende Familiennamen und Pseudonyme, von besonderer Bedeutung sind." aus Hilfe:Personendaten#Alternativnamen, und unvollständige Personendaten welche Vornamen unterschlägt kann imo nicht Sinn der Sache sein. --Ilion 14:29, 21. Mär. 2008 (CET)

Wenn der Artikeltitel eine bestimmte Schreibweise hat, dann ist das sehr wahrscheinlich die am häufigsten benutzte Form. Ich bin der Meinung das das Feld NAME eine höhere Priorität hat als ALTERNATIVNAMEN. Deshalb möchte ich diese Feld möglichst fehlerfrei haben. Um diese Fehlerfreiheit irgendwie automatisiert überprüfen zu können hab ich diese Regel vorgeschlagen. Die Regel für die Alternativnamen kannte ich bis dato noch nicht, aber ich sehe sie nicht als Hindernis. Meiner Meinung nach gehört die genaue Schreibweise des Titels in das Feld NAME, dafür sind ja die Personendaten eingeführt worden. Alle anderen Schreibweisen darf man getrost in das ALTERNATIVNAMEN-Feld einbauen, was auch schon seit Ewigkeiten so gemacht wird. (nicht signierter Beitrag von Stefan Kühn (Diskussion | Beiträge) )

Und was ist bei Lemmas mit Klammerschreibweise wie z. B. Georg Meier (Schachspieler) ? Klappt da auch eine automatisierte Überprüfung auf Richtigkeit ? --Ilion 20:50, 21. Mär. 2008 (CET)

Ja, der Klammerwert wird weggelöscht und dann werden alle Wortbestandteile überprüft. -- sk 22:30, 21. Mär. 2008 (CET)

Die Regel, die du vorschlaegst, ist doch laengst ueblich - oder? --Kolja21 21:25, 21. Mär. 2008 (CET)

Nein, leider nicht. Zumindest hält sich nicht jeder dran. Und bevor wir Editwars anzetteln, sollten wir eine klare Regel festlegen. Zahlreiche Beispiele für Nichteinhaltung findest du hier. --sk 22:30, 21. Mär. 2008 (CET)

Ich stimme zu, dass diese Regel eingefügt werden sollte, ich habe sowas in letzter Zeit auch schon öfter korrigiert (vor allem zusätzliche Vornamen in ALTERNATIVNAMEN mit Klammerzusatz "voller Name"). Aber nochmals: Bitte weg von "Das Feld muss mit einem Großbuchstaben beginnen". Das Feld muss so beginnen, wie der Name korrekt ist. Also: "NAME=will.i.am" und "al-Mumin, Abd". Daher bitte ich dich nochmals die Liste "NAME erster Buchstabe ist klein" aus der Fehlerseite zu entfernen. Zur Sortierung gibts DEFAULTSORT/Sortierung der Kat:Mann. Das Feld Name zeigt den korrekten Namen an. --APPER\^☺☹ 00:47, 22. Mär. 2008 (CET)

Danke für die klaren Worte. Damit kann ich leben. Werde das anpassen. -- sk 10:17, 22. Mär. 2008 (CET)

Verlinkung in der Kurzbeschreibung

Falsch oder richtig? --Pelz 18:17, 24. Mär. 2008 (CET)

Weder noch. Ich kenne bisher keinen Einsatzzweck, weshalb sie ruhig weggelassen werden kann. Es schadet aber auch nicht wirklich. Da aber die Verlinkungen zum sehr überwiegenden Teil sinnlos sind (USA, Deutschland, Sänger...) sollte man es vermutlich weglassen. --APPER\^☺☹ 19:29, 24. Mär. 2008 (CET)

ok, es wäre aber imho hilfreich, wenn wir eine Festlegung treffen würden, damit nicht irgendein Konfliktpotenzial entsteht. Gruss --Pelz 19:58, 24. Mär. 2008 (CET)

Lustig

In Autogas hab ich Personendaten gefunden :-) und gelöscht (Siehe hier . -- sk 21:30, 1. Apr. 2008 (CEST)

Sehr schön ;). Von einem Administrator eingefügt ([3]) ;) --APPER\^☺☹ 22:02, 1. Apr. 2008 (CEST)

Artikelnamen mit Zusatz

• Francesco d'Ubertino, genannt Bachiacca
• Fulvia, Geliebte des Quintus Curius
• Kaiserinwitwe Cixi

Sollten solche Artikelnamen nicht eigentlich verboten sein? Wir schreiben ja auch nicht Nobelpreisträger Einstein, Juri, Erster Astronaut. Haben wir irgendwo eine Richtlinie dafür? -- sk 17:45, 5. Apr. 2008 (CEST)

Da schließ ich mich an, wenn dann Cixi (Kaiserinwitwe) etc. --APPER\^☺☹ 18:07, 5. Apr. 2008 (CEST) Achso PS: Juri war nie Astronaut, nur Kosmonaut ;) --APPER\^☺☹ 18:08, 5. Apr. 2008 (CEST)

(nach BK)Ich würde vorschlagen zu verschieben auf

• Francesco Ubertini (so in DNB) oder Bachiacca
• Fulvia (Geliebte des Quintus Curius)
• Cixi (Kaiserinwitwe)

Aber bei "... genannt ..." muss man aufpassen, manchmal ist das der Familienname, so wie hier: Schmoll genannt Eisenwerth, Schutzbar genannt Milchling oder Von der Hoven genannt Pampus. In diesen Fällen sollte man nicht unbedingt verschieben. --Ephraim33 18:16, 5. Apr. 2008 (CEST)

automatische Entfernung von Links in den Feldern GEBURTSDATUM und STERBEDATUM

Da wir uns ja nun schon eine ganze Weile einig sind, dass Links in diesen Feldern nichts verloren haben, habe ich ein kleines Script geschrieben, das eckige Klammern aus den Feldern automatisch entfernt, wenn ein Artikel bearbeitet wird. Hilft vielleicht allen, die öfter Personenartikel bearbeiten. Zu finden in meiner monobook.js. Einfach in die eigene kopieren und los gehts ;) --APPER\^☺☹ 20:20, 9. Apr. 2008 (CEST)

Zur leichteren Wartbarkeit hab ich das mal noch schnell ausgelagert. Folgendes in die monobook.js einfügen:

// Entfernung von Links aus Personendaten-Feldern mit Datum
document.write('<SCRIPT SRC="http://de.wiki.x.io/w/index.php?title=Benutzer:APPER/removeLinksInPdDates&action=raw&ctype=text/javascript"><\/SCRIPT>');

Ich werde wohl demnächst nochmal rübergucken und dafür sorgen, dass wirklich alle links verschwinden... bei [[test|test2]] bleibt derzeit test|test2 übrig. Sollte in den Feldern egal sein, aber besser ist natürlich schon, wenn nur test2 übrig bleibt ;) --APPER\^☺☹ 20:25, 9. Apr. 2008 (CEST)

Datum

Ich finde einige der Vorgaben ehrlich gesagt daneben. Mal abgesehen von der Regulierungswut ist "zwischen 1350 und 1400" eben nicht identisch mit "2. Hälfte des 14. Jh.". Während die erste Angabe recht bestimmt ist, ist die zweite Angabe auch wenn sie denselben Zeitraum meint viel unbestimmter. Und es hat seine Gründe, wenn man eine solche Datierung verwendet. Und "Ende des 16. Jahrhunderts" ist in keiner Weise identisch mit einer Angabe wie "zwischen 1570 und 1600". Auch sehe ich nicht ein, daß Angaben wie "Frühjahr 43 v. Chr." falsch, die ungenauere Angabe "43 v. Chr." richtiger sein soll, wo man doch im idealfall das korrekte Datum möchte. Und die Änderung von Daten des antiken griechischen Kalenders die beispielsweise mit "450/49 v. Chr." angegeben wird, ist eben nicht "450 oder 449 v. Chr.". Denn das bezeichnet einen recht exakten Zeitraum innerhalb eines Jahres, das aber nicht unserem heutigen Kalender enstspricht. Wenn wir heute ein Bild in das Jahr 1749 datieren, weil wir das genaue Entstehungsdatum nicht kennen, ist diese Angabe genauso exakt wie die Angabe "450/49 v. Chr." - das bedeutet nämlich grob gesagt die zweite Hälfte 450 und die erste Hälfte 449 v. Chr. Es ist nur nicht möglich, diese umgerechneten antiken Daten genauer umzurechnen. Es kann einfach nicht sein, daß faktisch richtige Angaben für eine Vereinheitlichung verfälscht wird. Marcus Cyron in memoriam Dieter Noll 22:07, 1. Mär. 2008 (CET)

Ich sehe das anders. Alle Angaben die nicht "Tag. Monat Jahr" entsprechen werden von mir als de facto ungenau angenommen. Ich sehe auch keinen Sinn darin, die Daten anders als in dem vorgegeben standardisierten Format einzufügen. Wenn wir von so einem Standard weg zu "schreibt rein was ihr wollt" geht, können wir auch gleich die Personendaten abschaffen. Die Datumsfelder in der jetzigen Form lassen sich gut verarbeiten. Welchen Mehrwert hat die Zulassung von "Frühjahr 43 v. Chr." gegen über dem Zwischen-Format? Meiner Meinung nach: keinen. -- sk 22:17, 1. Mär. 2008 (CET)

Frühjahr ist nicht Sommer, Herbst oder Winter. Zudem geht es mit vor allem um die Angabe antiker griechischer Daten mit "/", auf die du hier nicht eingehst. Eine Veränderung in "oder" ist ein faktischer Fehler. Dann bin ich eher fürs Abschaffen als für die faktisch falsche Darstellung. Zudem - wo ist eigentlich die Auswertung, die es schon seit mehr als drei Jahren geben sollte? Marcus Cyron in memoriam Dieter Noll 11:50, 2. Mär. 2008 (CET)

Was für eine Auswertung wünschst du dir denn? Kennst du meine Personensuche? Über Fehlerlisten konnten zudem auch viele Kategorien korrigiert werden oder falsche Geburtsdaten (29. Februar in Nicht-Schaltjahren) gefunden werden. Ich finde diese Dinge und vor allem die Personensuche sehr praktisch. --APPER\^☺☹ 12:20, 2. Mär. 2008 (CET)

Was ist "2. Hälfte des 14. Jh.", wenn nicht "zwischen 1350 und 1400"? Wenn man nicht weiß, ob es zwischen 1350 und 1400 war, darf man auch nicht "2. Hälfte des 14. Jh." schreiben. --08-15 11:54, 2. Mär. 2008 (CET)

@Marcus: Das Datum soll im gregorianischen Kalender angegeben werden. Das mit den griechischen Datum ist mir neu. Kannst du mir einen Artikel empfehlen, wo die Problematik genau beschrieben wird? Sowas wie "450/49 v. Chr." muss sich doch eigentlich umrechnen lassen. Spätestens mit Astronomischen Ereignissen (z.B. Sonnenfinsternis) sollte sich doch auch so ein Kalender an den gregorianischen Kalender anknüpfen lassen. -- sk 12:58, 2. Mär. 2008 (CET)

Ich kann dir jetzt auf die Schnelle nichts empfehlen, habe derzeit auch I-Net-Probleme und nicht viel Zeit dazu. Du lernst es schlichtweg, wenn du irgendein Fach in dieser Richtung studierst. Das sind ja schon Daten, die in gregorianische Zeit umgerechnet sind. Marcus Cyron in memoriam Erwin Geschonneck 10:33, 13. Mär. 2008 (CET)

Zum Retrieval kann "2. Hälfte des 14. Jh." ja intern nach "zwischen 1350 und 1400" umgewandelt werden, aber es ist nicht das gleiche. Bei "zwischen 1350 und 1400" gibt anscheinend verlässliche Quellen, die das präzise ausschließen (z.B. ist bekannt, dass die Person 1349 noch lebte und 1401 schon tot war), bei "2. Hälfte des 14. Jh." wird vermutet, dass das Datum in diesen Zeitraum fällt (Fuzzy logic) - es ist also nicht das selbe. -- Nichtich 15:20, 3. Mär. 2008 (CET)

sk begann oben (Abschnitt "Einzeldiskussion: Geburts- und Sterbedatum") bereits verdienstvollerweise damit, Daten als Basis der Diskussion vorzulegen. Die von ihm angegebenen und weitere (s.u.) führen m.E. zu folgenden Schlussfolgerungen:

• Die Tilgung von "Anfang", "Ende", "Mitte", "Sommer", ... "Früh", "Spät" führt nicht zu erheblichen Informationsverlusten (insgesamt nur 117 Angaben). Sie ist daher vernünftig.
• Die Einführung von Angaben wie "verschollen", "vermisst" (nur je einmal) ist nicht gerechtfertigt.
• Die Zulassung von Jahrhundertangaben (630 laut sk, ich zähle mit Abkürzungen 649) ist notwendig. Sie werden benötigt, der Benutzer trägt sie deshalb auch ein, wenn die Vorschriften das nicht gestatten.
• Eine Notation für 'unsicher' (NICHT: für 'ungefähr', dafür haben wir "um") fehlt zur Zeit. Ergebnis: Der Benutzer trägt - da er auf eine solche Notation nicht verzichten kann - sie in einer von ihm beliebig gewählten Form ein. Zur Zeit 139 mal:

• 8 mal: ? oder ?? oder unsicher
• 5 mal: wahrscheinlich
• 3 mal: wohl
• 4 mal: angeblich
• 119 mal: vermutlich

Ergebnis: es ist notwendig, eine solche Angabe zu ermöglichen und eine empfohlene Form dafür vorzugeben. Es nicht zu tun, erzeugt gerade das Chaos, welches doch vermieden werden soll.

• Marcus Cyron weist oben darauf hin, dass 450/49 v. Chr. nicht in eine oder-Konstruktion aufgelöst werden kann. Zwar gibt es nur 31 Fälle der Form jahr/jahr v. Chr. (sowie 189 Fälle n. Chr.), da hier aber eine oder-Form nicht nur eine Vergröberung, sondern eine Verfälschung der Information wäre, teile ich die Position von Benutzer:Marcus Cyron, dass diese Notation zugelassen werden muss. (sk plädiert oben für "Datenveredlung". Genau, das muss Aufgabe sein.)

--Griot 01:48, 6. Mär. 2008 (CET)

Also, jetzt ganz konkret, mein Vorschlag:

 datumsfeld = [spezifikator] zeitangabe ["(unsicher)"]
 Bsp: getauft 11. Januar 1111 (unsicher)

Die 'unsicher'-Angabe bezieht sich immer auf das gesamte Datumsfeld, nie nur auf Teile. Zulässige Spezifikatoren sind "getauft" bei GEBURTSDATUM, "begraben" bei STERBEDATUM.

Die Zeitangabe kann eine "oder"-Konstruktion sein:

 zeitangabe = zeitbereich ["oder" zeitbereich]...
 Bsp: 1234 oder 1236 oder 1. April 1237

Nur gesamte Zeitbereiche können mit "oder" verknüpft werden, keine Teile.

Der Zeitbereich kann folgende Formen haben:

 datum
 "um" datum
 "vor" datum
 "nach" datum
 "zwischen" datum "und" datum

"vor", "nach", "zwischen" sind als die angegebenen Daten mit einschließend zu interpretieren.

Das Datum hat folgende Formen:

 tageszahl"." monat jahresangabe [v. Chr.]
 tageszahl"." monat "um" jahresangabe [v. Chr.]
              monat jahresangabe [v. Chr.]
                    jahresangabe [v. Chr.]
 jahrhundertzahl"." "Jahrhundert" [v. Chr.]

Für die Jahresangabe gibt es zwei Formen:

 jahr
 jahr/jahr

In der zweiten Form sind Leerzeichen neben dem "/" unzulässig. Ebenso muss die Differenz beider Jahre je nach v./n. Chr. 1 oder -1 sein. Abkürzungen wie 534/3 v. Chr. sind unzulässig.

Schließlich:

 tageszahl       = 1..31           -- ohne führende Null
 jahrhundertzahl = 1..31
 monat           = "Januar", ...   -- kein "Jänner"
 jahr            = 1..2024

Die beiden '31' ermöglichen einen simplem Parser, der "Jahrhundert" wie einen 13. Monat behandelt.

Sage noch jemand, das sei zu schwer für einen Parser.

(Soweit ich sehe, erfasst das sämtliche bisher in PD vorkommenden Datumsformen außer

 tag monat "nach" jahr

Diese Form kommt 13 mal vor. Ließe man für 'datum' [ohne erhebliche Erschwernis] auch zu:

 tageszahl"." monat "vor" jahresangabe [v. Chr.]
 tageszahl"." monat "nach" jahresangabe [v. Chr.]

würden sämtliche bisherigen PD - Datumsformen im wesentlichen darstellbar sein.) --Griot 17:44, 6. Mär. 2008 (CET)

Sehr gute Vorarbeite! Danke Griot. Geht auch "8. März zwischen 1945 und 1950" ? Ansonsten eigentlich von meiner Seite volle Zustimmung. Einzig und Allein die "Jahr/Jahr" Form müsste noch eingeschränkt werden. Für welche Zeiträume darf das angegeben werden nur für vor 100 v.Chr. (also irgendwann bei den alten Griechen) oder auch nach 1900? -- sk 20:36, 6. Mär. 2008 (CET)

Arrgh, habe ich übersehen. Diese '8.März'-Form kommt 9 oder 10 mal vor (ein Fall ist mehrdeutig). Natürlich habe ich nichts dagegen, sie noch aufzunehmen. Die Jahr/Jahr-Form zeitlich zu beschränken, wäre natürlich möglich. Wie das aussehen müsste, können natürlich nur Experten wie Marcus Cyron festlegen. Bis zum Ende von Byzanz? Ich hielte eine solche Einschränkung aber nicht für gut, da dasselbe Problem ja auch bei der Umrechnung aus anderen Kalendersystemen auftritt, sagen wir, wenn nur die Information 'Jahr 1400 nach der Hidschra' vorliegt.

(Nicht absolut verlässliche) Daten hierzu: Notationen Jahr/Folgejahr kommen in den PD wie folgt vor (gleiche Kombinationen jeweils nur einmal gezählt!):

13. Jh. v. Chr.:  1 mal
 6. Jh. v. Chr.:  1
 5. Jh. v. Chr.:  2
 4. Jh. v. Chr.:  4
 3. Jh. v. Chr.:  3
 2. Jh. v. Chr.:  5
 1. Jh. v. Chr.:  9

 1. Jh.:  4
 2. Jh.:  1
 3. Jh.:  1
 4. Jh.:  4
 5. Jh.:  6
 6. Jh.:  1
 7. Jh.:  4
 8. Jh.:  3
 9. Jh.:  5
10. Jh.:  8
11. Jh.:  1
12. Jh.:  6
13. Jh.:  8
14. Jh.:  8
15. Jh.: 10
16. Jh.: 14
17. Jh.:  7
18. Jh.:  6
19. Jh.:  2
20. Jh.:  8

--Griot 00:09, 7. Mär. 2008 (CET)

Die Bearbeitung einer Reihe von PD zeigte, dass obiger Vorschlag noch (mindestens) eine Lücke hat. Für einen bisherigen Eintrag "um 1730/1740" bietet er keine vernünftige Alternative. Diese Notation sollte daher zusätzlich gestattet werden. Die oben vorgeschlagene Syntax bleibt davon unberührt. Nur die Beschränkung, dass "jahr/jahr" nur für aufeinanderfolgende Jahre erlaubt ist, entfiele hinter "um". Ein Vorschlag für einen Text, der den bisher für "Datum" in der Hilfe angegebenen ersetzen könnte, folgt in einem neuen Abschnitt. --Griot 22:40, 9. Mär. 2008 (CET)

Mein Problem ist hier, daß zugunsten einer leichteren statistischen Auswertbarkeit und einer Vereinheitlichung die Richtigkeit auf der Strecke bleiben könnte. Das ist natürlich so nicht akzeptael. Es müssen sich einfach bessere Regelungen finden lassen. Marcus Cyron in memoriam Erwin Geschonneck 20:52, 13. Mär. 2008 (CET)

Wo siehst Du beim obigen Vorschlag Probleme mit der Richtigkeit? --Griot 02:04, 15. Mär. 2008 (CET)

Mir reicht es jetzt. Schon wieder wurden richtige "/"-Datumsangaben durch "zwischen"-Schwachsinn ersetzt. Passiert das nocheinmal - es ist faktisch falsch und damit nach all der hier vorgebrachten Argumente aus dem Arbeitsbereich Antike als Vandalismus zu betrachten, behalte ich mir Schritte wie Artikel- oder Benutzersperren vor. Kann doch wohl nicht wahr sein1 Marcus Cyron in memoriam Richard Widmark 12:55, 14. Apr. 2008 (CEST)

A. R. Penck oder Penck, A. R.?

Ist die Einordnung des Künstlernamens A. R. Penck als Penck, A. R. richtig? Immerhin gibt es keine ausgeschriebene Namensform. --32X 20:47, 16. Apr. 2008 (CEST)

Ich würde trotzdem Penck, A. R. wählen, denn so macht es auch die DNB: Link. Und nach der DNB gibt es auch eine ausgeschriebene Namensform. --Ephraim33 21:20, 16. Apr. 2008 (CEST)

Die Frage ist: Wie werden die "Vornamen" von Pseudonymen behandelt. Ältere Lexika ordnen Mark Twain unter dem Buchstaben "M" ein, Wikipedia (und die DNB) akzeptieren "Twain" als Nachnamen. Daher: "Penck, A. R." Allerding, wie das mit Beispielen so ist (Vorführeffekt), hat jemand in der betreffenden PD "Mark Twain (Künstlername)" eingetragen. --Kolja21 22:22, 16. Apr. 2008 (CEST)

Ich schlage vor, den Abschnitt "Name" entsprechend zu ergänzen:

Im Feld NAME wird der Name, unter dem die Person bekannt ist (das Lemma), in Ansetzungsform nach RAK eingetragen, also Nachname Komma Vorname. Dies ist nicht zwangsläufig der echte Name der Person, sondern sollte immer der bekannteste Name sein (z. B. „Heino“). Pseudonyme werden wie bürgerliche Namen behandelt (z.B. „Twain, Mark“). Bei Unsicherheit hilft beispielsweise ein Blick in die Deutsche Nationalbibliografie unter http://dnb.d-nb.de.

--Kolja21 22:27, 16. Apr. 2008 (CEST)

Nicht gut. Dann bekommen wir lauter Einträge wie Daddy, Puff und Cent, 50. --08-15 23:15, 16. Apr. 2008 (CEST)

"Cent, 50" wäre wirklich peinlich. Nur wie sollen wir das Problem lösen? Die DNB hat sich auf jeden Fall für "Twain, Mark" entschieden. Und das Lemma ist ja zum Glück nicht betroffen. (Es bleibt bei der Weiterleitung "Puff Daddy" auf Sean Combs, egal was in den Metadaten steht.) --Kolja21 23:23, 16. Apr. 2008 (CEST)

Die Regel aus [4] wäre vielleicht sinnvoll: Pseudonyme, die als moderne Namen mit Vor- und Familiennamen aufgefasst werden können, werden unter dem scheinbaren Familiennamen angesetzt. Können sie nicht als moderne Namen mit Vor- und Familiennamen aufgefasst werden, werden sie in der Form der Vorlage angesetzt. --08-15 23:35, 16. Apr. 2008 (CEST)

Gut, das wäre eine weitere Präzisierung, die Fälle wie "Cent, 50" ausschließt. Formulierungsvorschlag:

Im Feld NAME wird der Name, unter dem die Person bekannt ist (das Lemma), in Ansetzungsform nach RAK eingetragen, also Nachname Komma Vorname. Dies ist nicht zwangsläufig der echte Name der Person, sondern sollte immer der bekannteste Name sein (z. B. „Heino“). Pseudonyme, die als moderne Namen mit Vor- und Familiennamen aufgefasst werden können, werden unter dem scheinbaren Familiennamen angesetzt (z.B. „Twain, Mark“). Trifft das nicht zu, werden sie in der Form der Vorlage angesetzt (z.B. „50 Cent“). In Zweifelsfällen hilft beispielsweise ein Blick in die Deutsche Nationalbibliografie unter http://dnb.d-nb.de.

--Kolja21 03:15, 17. Apr. 2008 (CEST)

Da hab ich ja was losgetreten … Da ich nun Klarheit über das Problem habe, soll's mich nicht weiter stören. :) --32X 14:04, 17. Apr. 2008 (CEST)

Hilfe beim extrahieren der Vornamen und Namen

Hallo,

ich bin eigentlich hauptsächlich auf der englischen WP aktiv. Ich habe eine Datenbank geschrieben, die Informationen zu Büchern usw. enthalten soll. Ich will diese mit den Referenzinformationen, die in WP-Artikeln vorkommen, füllen. Dazu ist es für mich nötig, die Autorenstrings zu parsen, was manchmal erfordert, daß man weiß (d.h. ohne manuelle Einflussnahme), ob ein gewisses Wort ein Vorname ist oder nicht (z.B. um "Burger, Carl, Smith, John" von "Burger, Lefschetz, Smith" zu unterscheiden usw). Ich habe gesehen, daß die Daten im Prinzip alle vorliegen, bin aber nicht so ein Experte mit diesen Perl Scripts usw. Könnte mir jemand von Euch eine Datenbank (am besten SQL) erstellen, die die Vornamen (ganz einfach eine dumme Liste) enthält, und das gleiche auch nochmal mit den Nachnamen. Die Häufigkeiten der Vornamen sind auch wichtig, also bitte keine Duplikate löschen (oder ggf. in einer Extraspalte mitzählen).

Vielen herzlichen Dank für die Hilfe. Ihr erreicht mich am besten auf meiner englischen Seite en.User_talk:Jakob.scholbach, dort auch per email. Jakob.scholbach 13:28, 1. Mai 2008 (CEST)

Ach so, ich vergaß, wenn es Euch interessiert, die Datenbank ist unter zeteo.info und enthält bisher die Referenzen aus den englischen Mathe- und Physikartikeln (ugf. 10000). Jakob.scholbach 13:31, 1. Mai 2008 (CEST)

Unter [5] kannst du dir die Personendaten runterladen, wenn ich das richtig sehe. Die Listen die du haben möchtest musst du dir dann daraus selber generieren. Aber ich wäre vorsichtig, weil man nicht immer zwischen Vornamen und Nachnamen unterscheiden kann. Es gibt viele Namen die beides sein können. -- sk 15:49, 1. Mai 2008 (CEST)

Aha, danke. Welche Datei ist es, die ich da brauche? Jakob.scholbach 10:45, 2. Mai 2008 (CEST)

Nimm einfach eine von 20051002-extract.tab, 20051020-extract.tab, 20051020-full.tab und schau sie dir im Texteditor an. -- sk 13:42, 10. Mai 2008 (CEST)

Nation

Wäre es nicht interessant die Nationalität der einzelnen Personen in der Box anzugeben ? --Newme 00:35, 14. Mai 2008 (CEST)

Das wird in der Kurzbeschreibung normalerweise gemacht; außerdem gibt es dafür eine Kategorie. --08-15 00:52, 14. Mai 2008 (CEST)

gut stimmt ;) --Newme 01:00, 14. Mai 2008 (CEST)

Die Nationalität(en) lässt/lassen sich gut über die Kategorien ermitteln. Für meine Personensuche mach ich ja genau das. Von den inzwischen 210.000 Personen lassen sich für über 192.000 so Nationalitäten zuweisen. Mit einer "Qualitätsoffensive" an dieser Stelle könnte man sicher auch noch mehr rausholen. --APPER\^☺☹ 01:01, 14. Mai 2008 (CEST)

Wow geniales Tool, so kommt man um 1 noch zu guten Sachen ! --Newme 01:03, 14. Mai 2008 (CEST)

Pseudonyme

Wie schauts bei offensichtlichen Pseudonymen aus? Ich beziehe mich da auf die Änderung Diamond, King von heute. --Gripweed 18:18, 26. Mai 2008 (CEST)

Siehe drei Abschnitte weiter oben. --08-15 18:46, 26. Mai 2008 (CEST)

Bei einem offensichtlichen Pseudonym wäre die Schreibweise "King Diamond", so wie es zzt. in den Personendaten steht. Die Sortierreihenfolge (DEFAULTSORT) sieht dagegen "Diamond" als Familiennamen an. Laut Telefonbuch ist der Nachname rund 70x in Deutschland vorhanden, es könnte sich also durchaus um den Familiennamen eines Musikers handeln, der mit Spitznamen "King" genannt wird. Es ist ein Grenzfall, in dem beide Auffassungen vertretbar sind, man muss sich aber auf eine Schreibweise für PD und DEFAULTSORT einigen. --Kolja21 22:53, 26. Mai 2008 (CEST)

Mhm, aber er heißt ja nicht mit Familiennamen Diamond und noch weniger ist sein Spitzname King, der gute Kim Bendix Petersen. Ehrlich, ich mein das ist nicht der König, Christian, sondern der König Diamant... Die en machts zwar auch so (also Diamant, König) aber das erscheint mir irgendwie...nun ja... dümmlich... Eben wie Cent, 50... Hatte die Disku oben nicht gesehen, wollte nur schnell Klärung... Für diesen Spezialfall dann Diskussion:King Diamond --Gripweed 09:24, 27. Mai 2008 (CEST)

nochmal Personendaten - Datum

Über drei der von Benutzer:Griot vorgeschlagenen Schreibweisen, die ich wieder von der Hilfseite entfernt hatte, sieht er noch Diskussionsbedarf. 1. "(vermutlich)", 2. "Jahr/Folgejahr" und 3. "um 330/340". Ich hatte auf meiner Diskussionsseite schon dagegen argumentiert, hier eine kurze_sorry Zusammenfassung.
zu 1. Da haben wird schon die Notation mit "um", die praktisch das selbe ausdrückt, nämlich, dass die Angabe nicht genau ist. Natürlich hat die deutsche Sprache mehr Möglichkeiten Ungenauigkeit auszudrücken. Genau dafür ist der Fließtext da. In den Personendaten sollten aber nur Angaben stehen, die einfach auszuwerten sind. Lassen wir mehr Möglichkeiten zu, Ungenauigkeiten in den Personendaten darzustellen, machen wir uns (und zukünftigen Programmierern, die die Personendaten nutzen wollen) das Leben nur unnötig schwer. (Und etwas ganz anderes - wie Griot behauptete - ist es auch nicht. Nur der Fehler ist größer anzusetzen. "ca. 847" ist vielleicht ± 5 Jahre, "vermutlich 847" vielleicht ± 15 Jahre. Die Abweichung kann aber nicht zu groß sein, sonst passte das Jahr nicht mehr zur Person, die zum Beispiel 890 Fürst von irgendwas war.) Da man aber sowieso nicht wissen kann, welche Ungenauigkeit der Artikelautor mit "ca. 847" oder mit "vermutlich 847" ursprünglich gemeint hat, muss man alle solche Daten als unsicher annehmen.
zu 2. Die Notation "332/31 v. Chr." ist schwer auszuwerten. Für sieben Leutchen, die solche Angaben haben, lohnt es sich nicht, eine praktisch (computer)unlesbare Abgabe zuzulassen. Zumal "332 v. Chr. oder 331 v. Chr." fast das gleiche bedeutet. Dass das Intervall um einen Faktor zwei länger ist, würde ich in diesem Fall in Kauf nehmen. Für viele Griechen lassen sich zudem genaue Jahre angeben. Bei den Griechen heißt, wie weiter oben erläutert wurde, "450/49 v. Chr." grob zweite Hälfte 450 und die erste Hälfte 449 v. Chr. Bei Umrechnungen von anderen Kalendersystemen (zum Beispiel beim Islamischen Kalender, wo die Jahre "wandern") kann es aber etwas ganz anderes bedeuten: mal drei Viertel des einen Jahres und ein Viertel des nächsten oder umgekehrt. Außerdem handhaben wir die Vergröberung um den Faktor zwei auch schon bei neuzeitlichen Personen so, die zum Beispiel Alexander Lerner gestorben am 5. Juli 2004 im Alter von 90 Jahren. Dann steht in den Personendaten bei Geboren 1913 oder 1914. Natürlich könnte man es etwas genauer machen: "zwischen 6. Juli 1913 und 5. Juli 1914". Aber diese Möglichkeit hat man bei der Kalenderumrechnung auch. Dann braucht man kein "Jahr/Folgejahr" zulassen und muss auch keine Vergröberung durchführen: Man kommt mit "zwischen" aus.
zu 3. Zu "um 330/340": Das Wort "um" zeigt ja die Ungenauigkeit schon an, sodass es im Prinzip egal ist, ob man die Angabe durch "um 330" oder "um 340" ersetzt. Solchen Angaben sind eh nur Schätzwerte, die bei verschiedenen Autoren erheblich differieren können.
zu allen drei: Sie würden "(" und ")" und "/" in den Personendaten erlauben, die sonst nicht vorkommen können. Damit hätte man eine einfache Möglichkeit der Wartung verloren: Bisher kann man mit der Vorlagenauswertung nach Klammern und Schrägstrichen in dem Feld suchen und weiß, dass man eine ungültige Formulierung vor sich hat. Würde die neue Regel festgeschrieben, müsste man jeweils genau prüfen, ob man einen von den Spezialfällen vor sich hat, was nur unnötig Zeit kostet. Damit erschweren die drei Spezialfälle nicht nur die Auswertung und Programmierung sondern auch die Wartung.
Frage: Was denkt ihr denn über die Notwendigkeit der drei Spezialfälle? --Ephraim33 20:55, 14. Apr. 2008 (CEST)

Ich ergänze nur um Verweise auf die Stellen, wo die Frage bereits diskutiert wurde:

• Oben in Geburts- und Sterbedatum, es reicht aus, die Absätze anzusehen, die mit "Die Maximalvariante mit den" bzw. "'Unsicher' vers. 'um'" beginnen.

• Oben in Datum, zwei Texte von Marcus Cyron sowie der mit "Eine Notation für 'unsicher'" beginnende Absatz.
• Ephraims Diskussionsseite, Archiv, Nr. 291 "Personendaten - Datum", wobei ich besonderen Wert auf den Absatz "Viel schlimmer noch" lege.

Schließlich verweise ich darauf, dass Marcus Cyron bereits mindestens dreimal (das letzte Mal s. oben. unmittelbar vor Kurzbeschreibung ...) um die griechischen Jahreszahlen kämpfen musste. --Griot 22:03, 14. Apr. 2008 (CEST)

zu 1.: wie bereits mehrfach diskutiert, sollten wir hier wohl neben "um" eine zweite Variante für unsichere Daten hinzufügen. Ungenaue Daten ("um...") sind nicht unbedingt unsicher. Möglich wäre "wohl 1230" bzw. evtl. lässt man die Kombination zu: "wohl um 1230". So hat man einen Indikator für die Unsicherheit und einen für die Ungenauigkeit.

zu 2.: Schweres Thema voller Emotionen ;). Ich denke, wir sollten erstmal ein Parsing sehen, das diese Daten nutzt. Alle mir bekannten Parser interpretieren das Feld entweder gar nicht oder es wird das zweite Jahr genommen (und das als ungenau angesehen). Letzteres macht z.B. mein Parser für die Personensuche. Insofern bin ich sehr dafür statt "332/31 v. Chr." zumindest "332/331. v. Chr." zu schreiben, ich hoffe, dass das nicht plötzlich auch total falsch ist... Mir ist kein Parser bekannt, der irgendwas mit Daten wie "zwischen 1230 und 1235" oder "12. Februar 1846 oder 12. Februar 1847" anfangen kann.

Da mir nicht klar ist, wie ein Parser überhaupt solche Daten nutzen kann bzw. für welche Zwecke, sollten wir die relativ wenigen Spezialfälle mit griechischem Datum einfach erstmal so belassen (evtl. ohne sie aber explizit in die "richtigen" Formen aufzunehmen), bis es irgendeinen Einsatzzweck gibt, für den das genau analysiert werden kann/muss. --APPER\^☺☹ 22:28, 14. Apr. 2008 (CEST)

Eine Diskussion mit Ephraim33 (per Email) führte zu etwa folgendem Vorschlag (in meiner Interpretation, ohne Ephraim33 vorzugreifen):

1. Eine Notation für unsichere Daten sollte eingeführt werden. Die Form könnte sein: "unsicher: datum", wo sich "unsicher auf das gesamte Datum bezieht. Beispiele:

• unsicher: 1. März 1111
• unsicher: begraben 1.März 1111
• unsicher: um 1111
• unsicher: 1. März 1111 oder 1. April 1111

(Die unsicher-Kennzeichnung kommt an den Anfang, um ihre maschinelle Erkennung zu erleichtern. Das Wort "unsicher" wird vorgeschlagen, weil es anders als etwa "wohl" oder "wahrscheinlich" keinen Hinweis auf die Wahrscheinlichkeit enthält, daher allgemeiner verwendbar ist.)

2. APPERs Vorschlag wird aufgegriffen, den umstrittenen jahr/jahr-Formen einen Status der Art "bis zur Klärung vorläufig toleriert" zu geben. Das könnte etwa folgende Form haben:

Die folgenden Formen werden vorläufig zugelassen:

• jahr/folgejahr [v. Chr.]
• um jahr/jahr [v. Chr.]

also konkret zum Beispiel

333/332 v. Chr.

um 330/340

In der Erläuterung wäre anzugeben, dass die Form jahr/folgejahr nicht statt einer oder-Konstruktion verwendet werden soll, sondern ausschließlich, wenn die Quelle eine konkrete Jahreszahl nennt, welche jedoch weder eine julianische, noch eine gregorianische ist, vielmehr ein Jahr beschreibt, welches aus einem jul./greg. Jahr bis in das nächste reicht. (Abkürzungen wie 333/32 v. Chr. sind unzulässig.)

Die Form "um jahr/jahr" kann verwendet werden, wenn die Quelle eben das aussagt.

In einer Fußnote könnten Hinweise zur Verwendung von "um" vers. "unsicher" angegeben werden, die im Kern aussagen könnten:

• Vertraue der Quelle - nimm die dort angegebene Form (evtl. leicht vergröbert: "wohl" --> "unsicher")
• Wo - meist kontextabhängig - beide Angaben möglich sind, nimm diejenige, welche informationsreicher ist

3. (Das folgende gehört nicht mehr zum Notationsvorschlag! Die Details sind nicht mit Ephraim33 abgestimmt.) Zu APPERs Vorschlag, über die Nutzung ungenauer/unsicherer Daten nachzudenken: Zunächst könnten die Daten durch Streichung von Tag und Monar vergröbert werden. Wenn dann neben den sicheren (sagen wir Geburts-)Jahren eine Klasse "möglicher Geburtsjahre" eingeführt wird (in einem Tool, wie APPER es bereitstellt, könnte man mit einem Zusatzschalter wählen, ob man auch diese ausgewählt haben will), wäre eine Zuordnung folgender Art möglich (a, b: Jahreszahlen) [Dies bitte als grobe erste Vorstellungen betrachten!]:

• a oder b --> a und b werden mögliche Jahre
• zwischen a und b --> jedes Jahr des Intervalls wird als mögliches Jahr interpretiert
• nach a --> Jahre des Intervalls <a, a+10(?)> werden mögliche Jahre (in der Regel Sterbedatum, meist nach den "aktiven" Jahren, deshalb kein zu langes Intervall)
• vor a --> Jahre des Intervalls <a-20(?), a> werden mögliche Jahre (in der Regel Geburtsdatum, meist deutlich vor den "aktiven" Jahren, deshalb ein längeres Intervall)
• um a: die Jahre eines gewissen Intervalls um a (welches bei durch 5 teilbarem a größer sein sollte, als sonst) werden mögliche Jahre
• unsicher: a --> a wird mögliches Jahr
• unsicher: sonstige_beliebige_angabe --> wie sonstige_beliebige_angabe (über andere Jahre weiß man nichts, behandelt sie daher wie "unbekannt")
• um a/b: die Jahre eines gewissen vergrößerten Intervalls (Länge vielleicht das 1,2-fache der Intervallänge, aber nicht kleiner als bei "um a", "um b") werden mögliche Jahre
• jahr/folgejahr --> wie "jahr oder folgejahr"

Eine ausgefeiltere Realisierung könnte den "möglichen Jahren" noch Wahrscheinlichkeiten zuweisen, nach denen sie z.B. sortiert werden könnten. Eine unterschiedliche Behandlung von "vor" und "nach" bei Geburts- bzw. Sterbedaten wäre vorzuziehen. --Griot 09:16, 30. Mai 2008 (CEST)

Paul Arthurs

Diese Weiterleitung auf Oasis hat Kats und Personendaten. Ich würde die löschen. Meinung??--Pelz 22:06, 29. Mai 2008 (CEST)

Es gibt inzwischen so einige Personenweiterleitungen mit Kategorien und Personendaten. Ich finde das in Ordnung und würde es nicht löschen. --APPER\^☺☹ 23:40, 29. Mai 2008 (CEST)

Dass Weiterleitungen kategorisiert werden dürfen, wurde schon geklärt. (Der Hinweis müsste irgendwo bei Kat oder Redirects stehen.) --Kolja21 05:03, 30. Mai 2008 (CEST)

Britisch oder was?

Man trifft immer wieder auf Kurzbeschreibungen wie: "walisischer Maler", "schottischer Fußballer", "englischer Biologe" und "britischer Mathematiker". Bei historischen Personen sehe ich das ja ein, aber bei modernen Menschen, also alle die spätestens nach 1945 geboren sind sollte das doch "britisch" heißen. Oder sehe ich das falsch. Ich meine bei den Deutschen oder Franzosen machen wir doch auch nicht solche Unterschiede. Gibt es ein Geburtsdatum ab dem alle als "britisch" bezeichnet werden können? -- sk 15:13, 31. Mai 2008 (CEST)

Also "britischer Fußballer" geht gar nicht, das sind separate Verbände. Außerdem werden Engländer, Waliser etc. offenbar als echte Unterkategorien von Brite verwendet, jedenfalls ist nichts Gegenteiliges vermerkt. Und ich würde auch "sächsischer Ministerpräsident" oder "pfälzischer Mundartdichter" schreiben, also hätte ich kein Problem damit, wenn das Herkunftsadjektiv nicht mit der Nationalitätskategorie übereinstimmt. Es soll schließlich eine aussagekräftige Kurzbeschreibung und keine Standardkategorisierung sein. -- Harro von Wuff 18:01, 31. Mai 2008 (CEST)

Volle Zustimmung zu Harro van Wuff. --APPER\^☺☹ 18:19, 31. Mai 2008 (CEST)

Wir würden doch aber hier sicherlich "deutscher Politiker (CDU), Ministerpräsident von Sachsen" schreiben. Ich bin der Auffassung das in der Kurzbeschreibung am Anfang schon die Nationalität eingetragen werden sollte. -- sk 18:25, 31. Mai 2008 (CEST)

Dann doch lieber "sächsischer Ministerpräsident der CDU". Und "deutscher Schriftsteller, pfälzischer Mundartdichter" oder was auch immer kann ich mir gar nicht vorstellen. -- Harro von Wuff 18:53, 31. Mai 2008 (CEST)

beim deutschen Politiker kann ich mir das noch vorstellen, aber es gibt keine Regel, die vorschreibt, dass die Nationalität am Anfang stehen muss. Für die Nationalitäten gibts die Kategorien, die für 195.000 Personen funktionieren. also "pfälzischer Mundartdichter". Und "sächsischer Ministerpräsident (CDU)" find ich auch in Ordnung. --APPER\^☺☹ 18:57, 31. Mai 2008 (CEST)

Ich sehe das anders. Nicht jeder der die PD´s nutzen möchte wird auch die Kategorien mit auslesen. Bzw. wenn die PD´s ohne Kategorien in Umlauf kommen, dann ist die Nationalität in der Kurzbeschreibung sehr schön. Die andere Infos sollen ja nicht verschwinden nur erst eben an zweiter Stelle stehen. Dadurch kann man auch mal problemlos alle Personen nach der Kurzbeschreibung sortieren. -- sk 22:25, 31. Mai 2008 (CEST)

Man muss die Personendaten in Kombination mit den Kategorien sehen. Ohne funktionieren sie nicht, da sie ja beispielsweise nichtmal das geschlecht liefern. Und man wird wohl immer häufiger solche Infos aus Kategorien ziehen können als aus den Personendaten und die Auswertung der Kategorien ist nun wirklich nicht sonderlich schwierig, da ja die categorylinks auch zum Download angeboten werden. Ich finde diese Auswertungsmöglichkeit sogar einfacher. --APPER\^☺☹ 02:21, 1. Jun. 2008 (CEST)

Wir haben doch die ganzen Tages-/Jahresartikel und Begriffsklärungen als Beispiel, wie Kurzbeschreibungen aussehen sollen. Dieses Vorlagenfeld als Kategorieersatz zu führen ist auch praktisch nicht sinnvoll. Bei einem Textfeld hat man unendliche Freiheiten etwas einzutragen. Man sieht ja schon bei den einfacheren Feldern, wie man da hinterherräumen darf, bei sinntragenden Formulierungen grüßt Sisyphos. Das erinnert mich an die Anmerkung aus der PD-Löschdiskussion, ob wir nicht zu viel für den Computer arbeiten, statt der Computer für uns. Kategorien sind eindeutig bezeichnet und strukturiert und für das, was du meinst, erste Wahl. Umgekehrt eignen die sich wiederum nicht für Kurzbeschreibungen. Soll heißen: Jedes nur dafür verwenden, wofür es optimal taugt. -- Harro von Wuff 12:23, 1. Jun. 2008 (CEST)

(Pseudonym)

Wenn jemand mehrere Pseudonyme hat, soll dann bei Alternativnamen "(Pseudonym)" hinter jedem Pseudonym stehen oder nur einmal "(Pseudonyme)" hinter allen? (Bezug). --Ephraim33 15:18, 5. Jun. 2008 (CEST)

"Pseudonym" hinter jedem, weil die Angaben für automatische Auswertung bestimmt sind. --08-15 15:34, 5. Jun. 2008 (CEST)

Personendaten: Deutsche Nachnamen mit ehemaligen Adelstiteln als Nachnamensbestandteil

Hallo zusammen,

ich bin auf ein Problem gestoßen und würde gerne Eure Meinung dazu hören.

Es gibt in Deutschland seit 1919 keinen Adel und somit auch keine Adelstitel mehr. Das hat dazu geführt, daß die ehemaligen Adelstitel, sofern diese keine Herrschertitel waren, nach 1919 im bürgerlichen Nachnamen als normaler Nachnamensbestandteil geführt werden. So hieß es vor 1919 beispielsweise "Freiherr Max von Mustermann" und wurde entsprechend RAK §326.1 "Mustermann, Max Freiherr von" kategorisiert. Nach 1919 heißt es jedoch "Max Freiherr von Mustermann" und müßte entsprechend "Freiherr von Mustermann, Max" kategorisiert werden.

Nun finde ich aber bei etlichen Personen, die diese ehemaligen Adelstitel als bürgerlichen Nachnamensbestandteil führen, die alte und in meinen Augen nicht korrekte Kategorisierung bei den Personendaten.

Da sich lt. Wiki-Konventionen die Angabe der Personendaten nach den RAK richtet und dort §326.1 lediglich von Adelstiteln spricht (Adelstitel werden bei der Ansetzung der Namen nicht berücksichtigt), müssen nach meinem Verständnis die ganz normalen, bürgerlichen Nachnamen seit 1919, die ja gerade keine Adelstitel mehr sind, entsprechend anders kategorisiert werden. "Max Freiherr von Mustermann" heißt eben mit Nachnamen "Freiherr von Mustermann", eine wie auch immer geartete Auftrennung dieses zusammengesetzten Nachnamens ist namensrechtlich nicht möglich.

Grüße,Polycrux 12:29, 6. Jun. 2008 (CEST)

Die RAK-Ansetzung lautet in jedem Fall „Mustermann, Max von“. Das lässt sich in der Personennamendatei nachvollziehen:

• Burghard Freiherr von Schorlemer-Alst (1825–1895) = Schorlemer-Alst, Burghard von
• Otto Freiherr Kreß von Kressenstein (1850–1929) = Kress von Kressenstein, Otto
• Marion Gräfin Dönhoff (1909–2002) = Dönhoff, Marion
• Günter Freiherr von Gravenreuth (* 1948) = Gravenreuth, Günter von

Es spielt keine Rolle, ob es bis 1919 ein Adelstitel oder ab 1919 ein Namensbestandteil ist. Nach RAK bleiben die Dinger immer weg. --Entlinkt 12:51, 6. Jun. 2008 (CEST)

(BK) Wikipedia richtet sich da nicht nach Namensrecht und sollte das meiner Meinung nach auch nicht tun, sondern sinnvollerweise nach dem Namen, unter dem ein Mensch bekannt ist. Otto Graf Lambsdorff zum Beispiel, der frühere BRD-Wirtschaftsminister, ist sinnvollerweise als "Lambsdorff, Otto Graf" kategorisiert und steht so auch in den PD. Das "Graf" ist zwar rechtlich Teil seines Namens, wird aber im täglichen Gebrauch meist weggelassen.

Die aus den früheren Adelstiteln gebildeten Namen sind eben keine "ganz normalen" bürgerliechen Nachnamen, auch wenn sie das im rechtlichen Sinne sind. Umgekehrt wird Otto Habsburg meist als Otto von Habsburg bezeichnet, obwohl Österreich die Adelstitel 1919 ganz abgeschafft hat, diese also auch als Namensbestandteil nicht mehr existieren.

Nochmal zu Lambsdorff: Nur durch den WP-Artikel, den ich gerade geöffnet hatte, weiß ich, dass er eigentlich "von der Wenge Graf Lambsdorff" mit Nachnamen heißt - sollte man den jetzt unter "von", unter "der" oder unter "Wenge" einsortieren? Da würde wohl kaum jemand ihn suchen, die Sortierung unter "Lambsdorff" dürfte die sinnvollste und leserfreundlichste sein. Kategorien sollten in erster Linie die Benutzung erleichtern. -- Perrak 12:54, 6. Jun. 2008 (CEST)

Daß Personen, die unter einem anderen als ihrem bürgerlichen Namen bekannt sind, unter diesem geläufigeren Namen zumindest als Haupt-Lemma erscheinen, stelle ich ja nicht infrage (siehe beispielsweise auch "Richard von Weizsäcker").

Was ich jedoch anzweifle - und das zeigen auch die neuen, noch in Bearbeitung befindlichen RAK-Versionen ebenso - ist die bisherige Verfahrensweise, auch den bürgerlichen Nachnamen, der einen ehemaligen Adelstitel enthält, aufzutrennen.

Mir schwebt als Lösung vor, das Feld "ALTERNATIVNAMEN" mit dem gängigen Namen (also z. B. "Weizsäcker, Richard von") zu belegen, das Feld "NAME" jedoch mit der korrekten Version (also "Freiherr von Weizsäcker, Richard Karl").

Nach meinem Verständnis ist nämlich genau das die Funktion des Feldes "ALTERNATIVNAMEN". Grüße,Polycrux 13:13, 6. Jun. 2008 (CEST)

Willst du dann auch alle Namen mit "von" ohne weitere Zusätze alphabetisch unter "v" einordnen? --08-15 12:03, 7. Jun. 2008 (CEST)

Die Frage, ob die ehemaligen Adelstitel als Namensbestandtteile aufzufassen sind (das sind sie auf jedenfall), und die Frage, wo Nachnamen, die solche Namensbestandteile enthalten, alphabetisch einzuordnen sind (und wie sie folglich in den Personendaten zu formatieren sind), sind imho zwei verschiedene Fragen. Es scheint allgemeiner Usus zu sein, die Namen von Personen, deren Nachname einen ehemaligen Adelstitel als Namensbestandteil enthält, unter dem Anfangsbuchstaben des auf diesen Namensbestandteil folgenden Wortes alphabetisch einzuordnen, und von diesem Usus sollten wir auch hier nicht abweichen, da alles andere nur zu Verwirrung führt. -- 1001 02:38, 7. Jun. 2008 (CEST)

Klar, hier geht es nicht um die Lemmata, da besteht wohl Einigkeit, sondern um die PD. Meiner Beobachtung nach ist es zur Zeit eher üblich, den vollen "bürgerlichen" Namen als Alternativnamen einzutragen, die geläufige Form unter Name. Könnte man natürlich auch drehen. Aber da auch die PD eher dafür gedacht sind, eine enzyklopädische Sortierung zu ermöglichen als ein Adressbuch der Personalausweisdaten, scheint es mir sinnvoller, die lange (korrekte) Form bei der Alternative unterzubringen. -- Perrak 09:27, 7. Jun. 2008 (CEST)

Genau um den momentanen Usus bei der Verschlagwortung der Personendaten geht es mir: es herrscht nämlich keine ersichtliche Einheitlichkeit - und genau diese würde ich gerne schaffen. Ob nun das Feld NAME mit dem Nachnamen ohne den ehemaligen Adelstitel oder das Feld ALTERNATIVNAMEN dafür genommen wird, ist mir nicht sonderlich wichtig. Vielmehr würde ich es begrüßen, wenn die entsprechenden Richtlinien diesbezüglich konkretisiert werden, damit wir eine einheitliche Verfahrensweise, an der sich jeder orientieren kann, bekommen. Daß auch die Lemmata vieler dieser Personen nicht korrekt angegeben sind, steht auf einem anderen Blatt und gehört hier nicht her.

Folgenden Vorschlag hätte ich daher für die Verwendung der entsprechenden Felder der Personendaten zu machen:

• Einigung auf Feld NAME oder ALTERNATIVNAMEN als Träger des namensrechtlich korrekten Nachnamens
• Aufnahme der entsprechenden Bearbeitungshinweise hier in die Hilfeseite

Grüße,Polycrux 12:20, 7. Jun. 2008 (CEST)

Nochmal: Wie würdest du den Namen Achim von Borries einsortieren wollen? Wie Anne von der Heiden? --08-15 12:32, 7. Jun. 2008 (CEST)

Bei diesem Herren stellt sich ja nicht die eingangs formulierte Problematik, da er keinen ehemaligen Adelstitel im Nachnamen hat.

Ich würde ihn, sofern kein anderer Name bekannt ist, unter "von Borries, Achim" im Feld NAME und "Borries, Achim von" im Feld ALTERNATIVNAMEN verschlagworten (oder umgekehrt, je nach Gusto).

Grüße,Polycrux 12:52, 7. Jun. 2008 (CEST)

Alternativnamen

Bisher herrscht totales Chaos bei den Alternativnamen. Da müssen wir mal mit dem großen Besen durch die Personendaten durchgehen. Bevor ich auf der Fehlerliste neue Fehlermeldungen integriere, möchte ich das mit euch kurz besprechen. Unser Ziel sollte sein, dass die Alternativnamen für eine große Namensliste nutzbar gemacht werden. Diese Namensliste sollte in einer einheitlichen Schreibweise alle Namen der Personen beinhalten. Wir sollten uns auf einige einfach einzuhaltende Regeln einigen. Ich schlage mal folgende zur Diskussion vor.

1. Alle Namen, die vom Artikeltitel abweichen, gehören in die ALTERNATIVNAMEN. Daraus folgt, das im Datenfeld NAME nur die genauen Worte aus dem Titel stehen dürfen. Der Name ist für die alphabetische Sortierung entsprechend umgestellt.

• Begründung: Einfachere automatischer Überprüfung auf Korrektheit des Datenfeld NAME.
• Titel="Gabi Meier"
  • falsch NAME="Meier, Gabriele"
  • richtig NAME="Meier, Gabi" und ALTERNATIVNAMEN="Meier, Gabriele (Geburtsname)"
• Titel="Johnny Campbell (Fußballspieler, 1870)"
  • falsch NAME="Campbell, John Middleton"
  • richtig NAME="Campbell, Johnny" und ALTERNATIVNAMEN="Campbell, John Middleton (Geburtsname)"

2. Alle Namen in ALTERNATIVNAMEN werden per Semikolon getrennt und jeweils für die Sortierung umgestellt.

• Begründgung: Einfachere Trennung aller Namen.
• richtig ALTERNATIVNAMEN="Meier, Gabriele; Mei, Gabi (Pseudonym); M. Gabi (Kurzform); MG (Pseudonym); Schulz, Gabriele (Ehename)"
• falsch ALTERNATIVNAMEN="Gabriele Meier, Pseudonym: Gabi Mai / MG, verheitetet: Gabriele Schulz, bekannt als Gabi M."

3. Es dürfen keine Links im Feld NAME und ALTERNATIVNAME enthalten sein.

• Begründung: Alle Verlinkungen gehören in den Artikel und nicht in das Datenfeld. Vereinfacht automatische Überprüfung enorm!
• richtig "Henning von Putbus"
• falsch "Henning von Putbus"
• richtig "Benedikt Dürlich (deutsch)"
• falsch "Benedikt Dürlich (deutsch)"

4. Alle weiterführenden Informationen zu einem Namen im Feld NAME bzw. ALTERNATIVNAME werden nach dem Namen in Klammer gestellt. Dabei sind nur Nameninformationen gemeint, keine Klammerwerte wie "Johnny Campbell (Fußballspieler, 1870)", die zur Unterscheidung mehrere Personen dienen.

• Begründung: Klare Trennung zwischen Name und Informationen
• richtig ALTERNATIVNAMEN="Meier, Gabriele; Mei, Gabi (Pseudonym); M. Gabi (Kurzform); MG (Pseudonym); Schulz, Gabriele (Ehename)"
• falsch ALTERNATIVNAMEN="russisch: Igor Walidy" richtig "Walidy, Igor (russisch)"
• falsch ALTERNATIVNAMEN="Künstlername von: Elisabeth Comber, gebürtig: Maria Guanghu" richtig ALTERNATIVNAMEN="Comber, Elisabeth (Künstlername); Guanghu, Maria (Geburtsname)"

5. Die Inhalte der Klammern werden auf wenige Wortgruppen beschränkt. Dazu gehören die Gruppe der Namen (Geburtsname, Ehename, Künstlername, Pseudonym, Spitzname ...), Sprachadjektive (russisch, finnisch,...), Schrifthinweise ( Kyrillisch, vereinfachtes Chinesisch,...) und Transliterationshinweise (wissenschaftliche Transliteration, ...). Den genauen Umfang der Gruppen sollten die Fachleute unter uns ausarbeiten.

• Begründung: Klare Reglung für Schreibweisen vereinfacht Auswertung enorm.
• falsch: "Parker, Charles Christopher (geb.)"
• falsch: "Parker, Charles Christopher (geboren als)"
• falsch: "Parker, Charles Christopher (gebürtig)"
• falsch: "Parker, Charles Christopher (voller Name)"
• falsch: "Parker, Charles Christopher (Taufname)"
• richtig: "Parker, Charles Christopher (Geburtsname)"

Wenn wir uns auf solch ein Regelwerk einigen, was ja im Prinzip mit den Beispielen auf WP:PD schon besteht, grundsätzlich einigen können wäre das sehr schön. Die Umsetzung ist zwar viel Arbeit, aber es wird zu einer wesentlich besseren Nutzbarkeit der Daten führen. Ich würde dann Schritt für Schritt die Fehlermeldungen bei der Fehlerliste integrieren. Anmerkungen, Kommentare, Kritiken? -- sk 20:15, 29. Mai 2008 (CEST)

Kurzer Nachtrag jeweils mit Anzahl

• Liste möglicher Namenszusätze
  • Geburtsname (1779)
  • Pseudonym (711)
  • Ehename (16)
  • Spitzname (171)
  • Künstlername (175)

Sollen diese Namen erlaubt sein?

• Ordensname (9)
• Ehrenname (2)
• Eigenname (60)
• Thronname (32)
• Rufname (10)
• Kurzform (8)
• Kurzname (14)
• bürgerlicher Name (602)
• Deckname (14)

---

Ich finde ein solches Regelwerk gut!

• Zusätzliche Regel: Wenn es mehrere bekannte Vornamen gibt, dann in ALTERNATIVNAMEN immer alle auflisten.
• Zu "M. Gabi (Kurzform)": Das würde ich weglassen, sonst können wir zu jedem Namen alle möglichen Abkürzungen und ihre Kombinationen hinzunehmen. Und wenn doch (wenn etwa der Kurzname sehr bekannt ist), dann würde ich ein Komma einfügen, also: "M., Gabi (Kurzname)".

Die Namenszusätze sollten wir in der Hilfe definieren.

• Z.B. "bürgerlicher Name" kann der Geburts- oder der Ehename sein, im Zweifel sollte die genaueste bekannte Bezeichnung gewählt werden.
• Ich würde "Kurzform" und "Kurzname" zu "Kurzname" zusammenfassen.
• Was soll man sich unter "Eigenname" vorstellen?
• Ich würde "Taufname" erlauben, wenn er vom (bürgerlichen) Geburtsnamen abweicht.

--Frank C. Müller 21:19, 29. Mai 2008 (CEST)

Eigenname, Beispiel Go-Nara. - Die Kurzform würde ich auch rauswerfen. Hab sie nur für das Klammerbeispiel mit eingebaut. --sk 21:53, 29. Mai 2008 (CEST)

---

Schade finde ich, wenn wir z.B. den Künstlernamen als NAME eintragen und den bürgerlichen Namen als ALTERNATIVNAMEN, dass wir dann die Information "(Künstlername)" nicht mehr unterbringen können, weil wir solche Zusätze in NAME nicht erlauben. Mir fällt aber keine gute Lösung dazu ein. --Frank C. Müller 08:12, 30. Mai 2008 (CEST)

Eine Lösung dafür scheint mir aber erforderlich. Da die Eintragung dieser Information im Feld NAME wohl nicht glücklich ist (oder?), bleibt nur das ALTERNATIVNAMEN-Feld. Vorschlag: Dieses Feld darf mit "* (namenszusaetze)" beginnen, das sind dann die unter NAME fehlenden Angaben. (Ein Künstler, der sich den Künstlernamen "*" zulegt, wird aus der Wikipedia verbannt!) --Griot 09:25, 30. Mai 2008 (CEST)

---

a) Ich unterstütze voll das Anliegen von sk und Frank C. Müller und teile sks Einschätzung "totales Chaos".

b) Da hier wirklich eine Umarbeitung vieler PD erforderlich ist, wäre das auch noch eine Gelegenheit, vielleicht die letzte, ohne erheblichen Mehraufwand eine grundlegende Änderung vorzunehmen: die Trennung von Sprach-/Schriftangaben von der Charakterisierung der Namen. Es sollte noch einmal überlegt werden, den früheren Vorschlag von sk aufzugreifen, die Form

• [sprachadjektiv:] name [(namenscharakterisierung)]

in Betracht zu ziehen. Ein primäres Erfordernis ist dies ist allerdings nicht. Wird diese Form nicht akzeptiert, wären eine Reihenfolge und Trennzeichen festzulegen, etwa:

• name ([sprachadjektiv[;]] namenscharakterisierung)

c) Gefährlich ist die zu starre Festlegung auf die Eignung zur Erzeugung einer Namensliste (die natürlich gegeben sein sollte). Aber andere Verwendungen ebenfalls - Beispiel: Vornamensextraktion, wie einige Absätze vorher gewünscht. Es sollten die grundlegenden Informationen in maschinell auswertbarer Form angegeben werden, während auf ableitbare verzichtet wird. Zum Beispiel kann auf wissenschaftliche Transliteration verzichtet werden, wenn der Originalname vorhanden ist. Ebenso unterstütze ich den Vorschlag, alle Vornamen anzugeben, und zwar möglichst ohne Abkürzung. Abkürzen kann man maschinell. (Eventuell wird eine Markierung selten verwendeter Vornamen aber vorteilhaft sein.)

d) Ich stimme sks Punkten 1., 2., 3., 4. (abgesehen von meinem Vorschlag b)) zu. Zu 5., siehe f).

e) Notwendig sind darüber hinaus Festlegungen zu Namen, die im Original in nicht-lateinischer Schrift vorliegen. Sie müssen m.E. unbedingt in dieser Form in das ALTERNATIVNAMEN-Feld - dies ist schließlich die Basisinformation. Wie Matthiasb in inzwischen archivierten Beiträgen feststellte, ist es dafür zwingend erforderlich, dies mittels Vorlage zu tun, also z.B.

• {{lang|ru|Волков, Фёдор Кондратьевич}}
• {{zh|kurz=|c=育德}}

zu schreiben. (Außer 'lang' ist mir hier nur 'zh' als zu berücksichtigende Vorlage bekannt. Es können aber noch weitere hinzukommen, etwa für indische Schriften. Bei zh scheint es möglich zu sein, den Parameter 'kurz=' für PD zwingend vorzuschreiben.) Festzulegen wäre hier noch, ob die Sprache zusätzlich angegeben werden sollte. Ich tendiere zu 'ja'.

f) Jetzt zum Entscheidenden - wichtiger als a) bis e) zusammen: bitte auf gar keinen Fall "Die Inhalte der Klammern ... auf wenige Wortgruppen" beschränken! (Es geht jetzt nur um die Namenscharakterisierungen.) Oder fragen "Sollen diese Namen erlaubt sein?", weil es um weniger häufig vorkommende geht. Die möglichen Angaben müssen sich nach den realen Verhältnissen richten, und die sind eben nicht mit wenigen Wortgruppen abzudecken. Viele Vorbilder kann man sich wählen, aber muss es ausgerechnet Prokrustes sein? Wenn auch nur für einen Namen einer einzigen Person eine gewisse Charakterisierung des Namens die gegebene ist, die nicht durch andere ausdrückbar ist, dann muss diese Angabe möglich sein. Beschränkungen auf wenige Wortgruppen zerstören das Feld ALTERNATIVNAMEN.

Dies bedeutet nicht, dass man nicht Formulierungen vereinheitlichen sollte, wo sie (evtl. auch nur fast) dasselbe bedeuten. Aber eben auch nur dann. Ebenso kann und sollte man versuchen, auch freie Angaben in eine möglichst einheitliche Form zu bringen. Diese ist aber aus den realen Bedürfnissen abzuleiten. Und diese wiederum kann aus der bisherigen Verwendung erschlossen werden. Es folgt eine notwendigerweise etwas längerere Liste von Formen, die geeignet wäre, die in der WP zur Zeit (genauer: im Februar) benutzten Namenscharakterisierungen darzustellen. Sie wurde aus den benutzten Formen abgeleitet. Bitte berücksichtigen, es ist eine Skizze. Das entscheidende ist, dass ein recht reichhaltiges Spektrum von Angaben notwendig ist. Es folgt die Liste:

---

Die Sicherheit der Zuordnung bezeichnet:

• vermutlich identisch (Bsp.: "Publius Annius Florus")

Auf die Form bezogene Angaben:

• Akronym
• Anagram

Kurze Formen für Standardfälle decken ab:

• verheiratete(r)
• geborene(r)
• genannt
• abgekürzt
• vereinfacht
• übersetzt
• umgangssprachlich

Fehlerhafte/abgekürzte/vereinfachte Alternativnamen beschreiben Kombinationen aus folgenden Bestandteilen:

• falsche ...
• abgekürzte ...
• vereinfachte ...

gefolgt von:

• ... Schreibweise ...
• ... Lesung ...

gefolgt evtl. von:

• ... in <region>
• ... laut <quelle>

Kompliziertere Beschreibungen können durch Kombination folgender Bestandteile gebildet werden:

• wahrscheinliche(r/s) ...
• vermutete(r/s) ...

gefolgt evtl. von:

• ... vollständige(r/s) ...

gefolgt evtl. von:

• ... bürgerlicher ...
• ... gesetzlicher ...
• ... offizieller ...
• ... persönlicher ...
• ... eigentlicher ...
• ... wirklicher ...
• ... weltlicher ...
• ... militärischer ...
• ... literarische(r/s) ...
• ... populäre(r/s) ...
• ... posthume(r/s) ...
• ... umgangssprachliche(r/s) ...
• ... ursprüngliche(r/s) ...
• ... angenommener ...
• ... von der Leihmutter gegebener ...
• ... frühere(r/s) ...
• ... ehemalige(r/s) ...
• ... spätere(r/s) ...
• ... heutige(r/s) ...
• ... veraltete(r/s) ...
• ... nicht zeitgenössischer ...
• ... heidnischer ...
• ... häufiger(r/s) ...
• ... falsche(r/s) ...

gefolgt von:

• ... Name ...
• ... Vorname ...
• ... Geburtsname ...
• ... Familienname ...
• ... Mädchenname ...
• ... Titel ...
• ... Name mit Titel ...
• ... Ehrenname ...
• ... Ehrentitel ...
• ... Künstlername ...
• ... Kindheitsname ...
• ... Name nach der Heirat ...
• ... Name in der Ehe ...
• ... Name nach der Ehe ...
• ... Name in 1. Ehe ...
• ... Name in 2. Ehe ...
• ... Name seit 3. Ehe ...
• ... Name nach 4. Ehe ...
• ... Nickname ...
• ... Parteiname ...
• ... Pfadfindername ...
• ... populärer Name ...
• ... Spielername ...
• ... Spitzname ...
• ... Nom de guerre ...
• ... Kampfname ...
• ... Taufname ...
• ... Kosename ...
• ... Rufname ...
• ... Beiname ...
• ... Codename ...
• ... Deckname ...
• ... Horusname ...
• ... Tempelname ...
• ... Thronname ...
• ... Goldname ...
• ... Hofname ...
• ... Autorenname ...
• ... Ordensname ...
• ... Papstname ...
• ... Äraname ... (oder Ärabezeichnung)
• ... Prinzenname ...
• ... Kurzname ...
• ... Pseudonym ...
• ... Kollektivpseudonym mit <name> ...
• ... Lesung ...

gefolgt von:

• ... vor <nowiki><jahr></nowiki>
• ... bis <jahr>
• ... seit <jahr>
• ... seit etwa <jahr>
• ... von <jahr> bis <jahr>
• ... als <funktion etc.> Bsp.: König, Mönch, Buddhist
• ... als <beruf etc.> Bsp.: Boxer, Erpresser
• ... beim <taetigkeit> Bsp.: Wrestling
• ... bei <quelle/organisation> Bsp.: Manetho, DSB, FIDE, FIFA, UEFA
• ... in/im <quelle> Bsp.: Meyers, Thieme-Becker, DNB, NDB, AKL, Königsliste von Abydos, Nibelungenlied, Zeitschrift SCHACH
• ... in/im <region> Bsp.: Flandern, französischen Sprachraum
• ... unter/in <menschengruppe> Bsp.: seinen Anhängern
• ... in/vor/nach <lebensabschnitt> Bsp.: [der] Jugendzeit
• ... in/vor/nach <situation> Bsp.: [der] Illegalität, [der] Emigration, [dem] Krieg
• ... vor/nach <ereignis> Bsp.: [der] Adoption, [der] Scheidung der Eltern, [der] erneute(r/n) Heirat der Mutter

--Griot 18:09, 30. Mai 2008 (CEST)

Oje, Griot. Da hast so ein tolles Talent aus einer kleinen Sache eine riesige Theorie abzuleiten. Das ist mir schon bei der Datumsdiskussion aufgefallen. Leider ist dann immer keiner mehr gewillt das technisch umzusetzen. :-) - Ok, also eigentlich sollten APPER und ich die Grundform ausarbeiten, weil wir ja wirklich dann mit den Daten zurecht kommen müssen. Zu e) Oben wurde schon mal angesprochen das Vorlagen (lang, zh,...) auf gar keinen Fall in den Personendaten eingebaut werden sollten. Das verkompliziert die Herausfilterung der PD´s aus dem Artikel enorm und die Auswertung auch. Zu f) Wenn wir das so machen wie du vorschlägst, dann kommen wir auf keinen grünen Zweig, weil jeder seine 3 Personen mit irgeneiner Spezialform durchsetzen möchte. Ich würde vorschlagen wir bauen ganz wenige Wortgruppen, die vielleicht später mal erweitert werden können. - Generell: Die Namensliste ist der Hauptzweck der Personendaten bei der Einführung gewesen und nach meiner Meinung auch immer noch einer der wichtigsten Aufgaben. Deshalb sollen auch alle Namensinformationen in Klammern. nix davor oder sonstwo, sondern einfach nur in Klammern. Was in der Klammer steht kann später standardisiert werden, aber erstmal müssen wir die Namen von den Infos trennen. --sk 22:10, 30. Mai 2008 (CEST)

So, dann will ich mich auch mal melden, wenn mein Name hier schon fällt ;). Also zunächst mal mein persönlicher Eindruck von dieser Diskussion: wir sind uns alle einig, dass das Feld Aufmerksamkeit braucht und da einiges zu tun ist. Wir sollten aber die Personendaten nicht überregulieren. Wir müssen bedenken, dass sie der Großteil der aktiven Wikipedianer halbwegs durchschauen sollte und nicht am Ende eine Handvoll Leute übrig bleibt, die wissen, was korrekt ist.

Und vorm eigentlichen Inhalt noch ein Einwurf: Wir (in dem Fall vor allem Stefan und ich, also die, die bisher die Daten benutzen) sollten mal eine Seite anlegen, auf der die Auswertung dokumentiert wird. Welcher reguläre Ausdruck muss auf die Personendaten matchen? Welche genauen Schritte muss man machen um Vornamen zu extrahieren (1. Alternativnamen bei ";" trennen; 2. bei jedem einzelnen Klammerzusätze entfernen; 3. Wenn Komma vorhanden: danach Vornamen...)? Nur wenn das Ganze nutzbar ist, werden die Daten auch genutzt. Z.B. fehlt mir noch geeigneter Code, Zeiträume in Datumsfeldern zu erkennen ganz abgesehen davon, dass ich nicht weiß, wie man diese Daten am besten ablegt und nutzt. Früher oder später werde ich mich auf die Auswertung der Ortsfelder stürzen, spätestens da werden wir mit so wenigen Regeln wie bisher nicht mehr klarkommen.

Zu den Alternativnamen: wir sind uns zunächst einig, dass es sich dabei um eine Auflistung mehrerer Namen handelt. Jeder einzelne ist durch ein Semikolon getrennt. Ich halte die Regelung am besten, sämtliche Nicht-Namen-Zusätze in Klammern aufzunehmen, wo wiederum mehrere Attribute mit Semikolons getrennt abgelegt werden können. Soweit sind wir uns denke ich ziemlich einig. Einigkeit herrscht auch weitgehend bei der Nennung der Namen. Im Feld NAME sollte der Hauptname wie im Lemma stehen. Ob bestimmte Kurzformen in die Alternativnamen aufgenommen werden oder nicht sollte im Einzelfall geklärt werden und gehört wohl nicht wirklich in die Regeln. Die Frage ist noch, wie der Zusatz "Pseudonym" beispielsweise für das Feld "NAME" hinzugefügt werden kann. Die Lösung mit "* (Pseudonym)" finde ich nicht sonderlich gut, da das ganze neuen Syntax mit sich bringt, den dann wieder kaum jemand kennt. Entweder man beginnt einfach nur mit den Klammern "(Pseudonym); Meier, Gabi (wirklicher Name)". Der Vorteil wäre, dass man zur Erstellung von Namenslisten nur die beiden Felder aneinanderklatschen müsste und mit dem gleichen Algorithmus die Daten extrahieren könnte ohne irgendeine Extrabehandlung. Der erste Name ist dann einfach der Hauptname. Eine der Lösungen wird es wohl machen.

Diskussionsbedarf gibt es wohl noch beim Inhalt der Klammern. Dort gibt es wohl zwei Arten von Informationen: Sprachinformationen und solche zum Inhalt. Für die Sprachinfos kann wohl eine Liste angelegt werden, wobei diese nicht starr sein sollte sondern im Bedarfsfall erweitert werden kann. Die Liste sollte dafür irgendwo im Wiki abgelegt sein. Bei den Inhaltsinformationen darf es meiner Meinung nach keine starre Regelung geben. Dort gibt es einfach zu viele Sachen, auch wenn die Auswertbarkeit dann natürlich leidet. Wir können uns darauf einige, überall "Pseudonym" zu schreiben statt "Künstlername", aber ich glaube ganz ehrlich, dass das zuviel Aufwand bringt. Sinnvoll ist dort wohl wieder eine Tabelle im Wiki, die angibt, dass "Künstername" gleich "Pseudonym" ausgewertet werden soll, entdeckte seltene Formen oder Abkürzungen wie "Pseud." werden aber korrigiert. Mir ist bewusst, dass dies keine einfache Fehlerliste zulässt, wie sie bisher angelegt werden, aber ich glaube wir brauchen an der Stelle die Freiheit. Vielleicht sollte man mal mit einer Liste aller bisher in Klammern vorkommenden Terme anfangen und schauen, was gewollt ist und was nicht. Daraus lassen sich dann Regeln ableiten, die aber nie so starr sein können, wie hier teilweise gefordert.

Zur Vorlage:lang. Ich weiß noch immer nicht, ob ich die Vorlage gutfinden soll oder nicht. Solange sie nicht im letzten Feld (Sterbeort) auftaucht, ist sie für die Auswertung kein wirkliches Problem, macht nur zusätzlichen Aufwand. Natürlich gehts selbst im letzten Datenfeld, da macht sie aber sehr viel mehr Aufwand ;). Sie bringt halt Arbeit aber auch Zusatzinformationen. Ich glaube, das sollten wir bei Gelegenheit nochmal ausführlich diskutieren. --APPER\^☺☹ 02:18, 31. Mai 2008 (CEST)

Zum größten Teil volle Zustimmung. Anmerkung: Was hindert uns daran bei Madonna im Datenfeld NAME=Madonna (Künstlername) zu schreiben? Das versteht jeder, hat bisher nur keiner gemacht. Damit hätten wir alle anderen Wege umschifft. -- sk 11:28, 31. Mai 2008 (CEST)

Wir scheinen uns ja einem Konsens zu nähern. (Vorbemerkung: Im Abschnitt nochmal Personendaten_-_Datum stehen Ergebnisse (aus meiner Sicht) einer Diskussion mit Ephraim33 zu den offenen Punkten bei 'Datum'. Bitte auch diese durchsehen. (Ein neuer Abschnitt wäre besser gewesen.)) Zum Feld ALTERNATIVNAMEN, im Einzelnen:

• Wenn ich es auch nicht für ideal halte - alles in eine Klammer geht natürlich.
• Meinen Vorschlag "* (...)" ziehe ich zurück, APPERs Gegenargumente sind überzeugend. Wichtig ist, eine Form zur Angabe dieser Information zu finden. Welche Form, ist zweitrangig. sk's Vorschlag, dies mit ins Namensfeld aufzunehmen, wäre an sich die logischste. Allerdings müsste sie sehr gut überlegt werden: Es müssten nicht nur alle bisherigen Klammern aus diesem Feld entfernt werden, man würde sich auch "für alle Zeit" der Möglichkeit berauben, in diesem Feld Zusätze unterzubringen, um zwischen Personen gleichen Namens zu unterscheiden. APPERs Vorschlag ist zwar weniger logisch, scheint mir aber vorsichtiger zu sein. (Eine andere Möglichkeit wäre übrigens, den ganzen Namen im ALTERN.-Feld zu wiederholen, wenn eine Zusatzangabe zum Namen gemacht werden soll. Kosten: Ein zusätzlicher Vergleich des Namens in NAME mit dem ersten in ALTERN., Gewinn: keine neuen oder verwirrenden Formen.)
• Zur Sprachinformation ist, wie APPER schon schrieb, eine nicht abgeschlossene Liste sinnvoll. Man kann sie abkürzen, wenn man sie als Erweiterung einer bereits existierenden definiert, das könnte die Liste in in Wikipedia:Sprachen#Alle_Wikipedias sein (ich hatte das im archivierten Beitrag [6] bereits vorgeschlagen, zusammen mit einer Liste zusätzlich wohl notwendiger/sinnvoller Sprachadjektive).
• Entscheidend ist, dass für die Angaben zur Namenskennzeichnung eine erhebliche Freiheit nötig ist. Nicht so groß, wie bei KURZBESCHREIBUNG, aber doch eine relativ große. APPERs Wunsch nach einer Liste der vorkommenden Formen erfüllt meine obige Zusammenstellung bereits im Kern - es ist der Extrakt der (im Februar) vorkommenden Angaben. (Die natürlich in den verschiedensten Formen vorkommen. Und ich kann natürlich bei der Bearbeitung doch ein paar übersehen haben.) Da diese Angaben bisher frei eingetragen werden konnten, darf vermutet werden, dass die vorgefundenen Formen das Benötigte bereits in hohem Maße abdecken. Keine der vorgefundenen Angaben halte ich für a priori unwichtig (im Einzelfall kann das natürlich der Fall sein, das zu sehen, müsste aber der ganze Artikel berücksichtigt werden, was offenbar ausscheidet). Es ist fast verwunderlich, dass es doch möglich ist, mit relativ wenigen grammatischen Strukturen die vorgefundenen Angaben zu erfassen. Wenn auf der Hilfeseite neben Vorgaben für die Standardsituationen ein paar komplexere Angaben als Beispiel gezeigt werden, hätte ich Hoffnung, dass auch relativ einheitlich geformte Angaben eingetragen werden. Da der Strukturreichtum nicht ganz klein, aber doch noch übersichtlich ist, sollte (sicher nicht im ersten Ansatz) auch eine maschinelle Kontrolle möglich sein, welche den Großteil der Angaben als korrekt/inkorrekt erkennt und den Rest für manuelle Kontrolle anzeigt.
• Wie schon gesagt, halte ich es für unverzichtbar, Namen, die im Original in nicht-lateinischer Schrift vorliegen, in dieser Form anzugeben. (APPER schlug eine Extradiskussion dazu vor - gut.) Man könnte überlegen, ob das Vorlagenproblem umgangen werden kann. Matthiasb' Aussage, dass das innerhalb der Vorlage 'lang' (gewiss auch möglich: 'zh') geschehen müsse, wurde von niemand bestritten (ich kenne mich da selbst nicht aus). Man könnte allenfalls noch fragen, ob sich daran in absehbarer Zukunft etwas ändern könnte, man die Zeit bis dahin überbrücken kann. Wenn das - wie ich vermute - nicht der Fall ist, sehe ich ohne Vorlagen nur noch wenig attraktive Möglichkeiten wie die, den Originalnamen in einen Kommentar zu packen. APPERs Aussagen machen mir aber Hoffnung, dass die normale Lösung mit 'lang' möglich sein sollte. (Vorlagen im letzten Datenfeld - da kenne ich nur 'Okina' als eventuell möglich - sollten so selten nötig sein (weniger als 5, wenn überhaupt welche zur Zeit), dass man sie mit Tricks wie Redirects von 'reduzierten' Ortsnamen auf die wirklichen vermeiden kann.)

--Griot 01:25, 1. Jun. 2008 (CEST) (jetzt ein paar Tage nicht in Netznähe)

So ich hab mal für die weitere Diskussion die Klammerausdrücke gesammelt und ausgezählt. Schaut mal hier (A.A.o.Gewähr) -- sk 20:58, 2. Jun. 2008 (CEST)

Danke! Der Blick über die nur einmal vorkommenden zeigt schon viele Fehler und eine Vereinheitlichung zwischen "voller Name" und "vollständiger Name" ist sicher auch wünschenswert. --APPER\^☺☹ 01:04, 3. Jun. 2008 (CEST)

---

Okay, ich nehme mir mal heraus, an dieser Stelle zusammenzufassen und zunächst die unstrittigen Punkte aufzuführen, um dann die noch unklaren Punkte aufzulisten und die dann weiter diskutieren zu können.

• Das Feld ALTERNATIVNAMEN enthält durch Semikolons getrennt eine Auflistung aller Alternativnamen. Jeder einzelne Eintrag enthält zunächst den Namen (in üblicher NAME-Ansetzung Nachname Komma Vorname) und zusätzlich in Klammern weitergehende Informationen zu diesem Namen. Die weitergehenden Informationen sind eine durch Komma getrennte Liste (oder Semikolon??? Komma ist sicher einfacher auszuwerten, da das Semikolon ja schon die Namen trennt). Im Normalfall handelt es sich um maximal zwei Angaben: Sprache und Namenspräzisierung. Für die Sprache wird im Wiki eine Liste mit möglichen (erlaubten) Formen (keine Abkürzungen) angelegt, die gegebenenfalls erweitert werden kann (wenn möglich maschinenlesbar und am besten gleich mit Zuordnung zur Sprache (z.B. ISO-Code). Für die Namenspräzisierungen werden bevorzugte Formen festgelegt (z.B. "voller Name" statt "vollst. Name" oder "vollständiger Name") Wegen mir auch andersrum, ist mir egal, muss dann diskutiert werden, ansonsten sind hier Freiheiten erlaubt.

Noch zu diskutieren:

• Kennzeichnung der Namenspräzisierung des Hauptnamens.
• Finden der Liste der Haupt-Namenspräzisierungen. Evtl. legt man dazu die entsprechende Seite an, auf der diese Liste später gepflegt werden soll (Hilfe:Personendaten/irgendwas) und führt die Diskussion dort auf der Diskussionsseite.
• Vorlagen in den Feldern. Wobei wir uns wohl einig sind, dass die Diskussion ausschließlich die Felder NAME und ALTERNATIVNAMEN und die Vorlagen lang und zh betrifft. Die Vorlage:Okina ist nicht nötig, da das Zeichen in Unicode dargestellt werden kann und die Vorlage teilweise andere Zwecke hat (z.B. Darstellung im IE; Erkennung von entsprechenden Artikeln...), die für die Personendaten irrelevant sind. Dafür sollte wohl ein neuer Diskussionspunkt angefangen werden (was ich gleich mal mache).

Also. Ich denke, wir kommen dem Ziel näher ;) --APPER\^☺☹ 01:04, 3. Jun. 2008 (CEST)

So, ich habe jetzt Hilfe:Personendaten/Alternativnamen angelegt. Dort wird detaillierter auf dieses Feld eingegangen, offene Punkte hab ich markiert. Wir sollten am Ende aber auf jeden Fall eine Kurzform auch auf Hilfe:Personendaten ablegen, man kann niemandem zumuten, diese Seite zu lesen, auch wenn es der automatischen Auswertbarkeit wegen nötig ist, eine solche Seite zu haben. Beim Schreiben sind mir noch ein paar kleine weitere Fragen eingefallen, die wir aber vermutlich auf der dortigen Diskussionsseite ausdiskutieren sollten. Wer sind eigentlich wir? Wie ich das sehe, diskutieren zur Zeit nur sk, Griot und ich, Frank C. Müller sagte nur am Anfang etwas. Evtl. sollten wir nach einer Andiskussion der offenen Punkte (also wenn wir unsere Meinungen zu den offenen Punkten gesagt haben), nochmal Ephraim33, Vlado und Frank C. Müller anschreiben, dass die sich das nochmal anschauen. --APPER\^☺☹ 03:56, 3. Jun. 2008 (CEST)

---

Zusätze zum Hauptnamen:

Ich finde den Vorschlag, einen eventuellen Zusatz einfach im Feld NAME unterzubringen am besten (Bsp.: "NAME:Fernandel (Künstlername)"; die In-Feld-Syntax für Zusätze wäre dann bei den Feldern NAME und ALTERNATIVNAME gleich. Die Option, im Feld NAME evt. einmal eine Unterscheidung zwischen gleichnamigen Personen unterzubringen, würde ich nicht offenhalten, da diese Unterscheidung ja schon im Lemma geschieht, die Personendaten können sich hier auf andere Aspekte konzentrieren.

Nummern zu den Zusatzlisten:

Ich würde die Liste der Zusätze nicht nummerieren, die Nummern mögen vielleicht als Programmierhilfe ganz nützlich sein, das sollte aber jeder Programmierer für sich entscheiden; hier im Lexikon sind sie m.E. eher fehl am Platz.

--Frank C. Müller 08:15, 3. Jun. 2008 (CEST)

Zum Thema "Zusätze zum Hauptnamen": Ich schließe mich wie Frank C. Müller dem Vorschlag von sk an, die Zusatzangaben mit in das NAME-Feld aufzunehmen. (Meine geäußerten Bedenken entfallen, wenn man das Lemma als impliziten Bestandteil der Personendaten auffasst.) --Griot 16:39, 8. Jun. 2008 (CEST)

Ich schließ mich dem auch mal an ;). Das Lemma gehört, genauso wie die Kategorien (z.B. Geschlecht) immer implizit zu den Personendaten. --APPER\^☺☹ 17:05, 8. Jun. 2008 (CEST)

Personendaten in Weiterleitung?

Hallo, ist es sinnvoll, analog zu Kategorien auch Personendaten in Weiterleitungen einzubauen (zwecks Auswertung)? Als Beispiel mal Ernst Witschi: Relevant, aber eben nur als Partner des Büros Henauer und Witschi. --Port(u*o)s 17:43, 10. Jun. 2008 (CEST)

Siehe den letzten Paragrafen im Abschnitt Verwendung. --32X 19:04, 10. Jun. 2008 (CEST)

Danke schön. Da hatte ich Tomaten auf den Augen. --Port(u*o)s 19:06, 10. Jun. 2008 (CEST)

Fiktive Personen

Kriegen fiktive Personen auch Personendaten? Bsp. Dr. Stay Dry. Könnte man das auch in der Hilfe erwähnen? --Frank C. Müller 08:24, 13. Jun. 2008 (CEST)

Eigentlich nicht, aber bei Dr. Stay Dry habe ich auch eine Weile überlegt. Leider weiß ich zu wenig über ihn: Ist das immer dieselbe Person, die den darstellt? Dann könnte man "Dr. Stay Dry" als dessen Pseudonym auffassen (so wie "Madonna" oder "Prince"). Leiht ihm der Darsteller auch seine Stimme oder ist das eine dritte Person? Ein ähnlicher Fall (MC Hawking) hat übrigens keine Personendaten. --Ephraim33 10:12, 13. Jun. 2008 (CEST)

Probleme mit antiken Namen der Griechen und Römer

Auf Bitte von Stefan hin versuche ich mal hier zu erklären, warum die Theorie der PD bei den Namen antiker Griechen und Römer nicht funktioniert. Ich bin die Revertierungen mittlerweile leid und auch es an zig Stellen immer wieder neu erklären zu müssen. zudem ist das keinen Streit mit Leuten wie Stafan oder Rax wert.

• Griechische Namen: Es gibt häufig Beinamen bei griechischen Namen, die im allgmeinen aus nur einem Namen bestehen. So heißt Perikles wirklich nur Perikles. Die Griechen nannten dazu je nach Ort noch ein paar weitere Angaben, Vatersnamen, Demos, Phyle etc. Diese Zusärte werden heute nicht mehr verwendet. Bleibt der persönliche Name. Nun gibt es das Problem, daß es so viele Namen nicht gab. Deshalb werden häufig Zusätze verwendet. Da es Lais mehrfach gab, haben wir beispielsweise im Projekt Lais von Korinth und Lais von Hykkara. Es bleibt aber dabei, daß die Zusätze zwar etabliert sind, aber nur zur Unterscheidung dienen. Aus den PD wird aber meist der Eigenname gelöscht und der Name mit Zusatz behalten. Das ist faktisch falsch. Wenn man schon nur einen Namen möchte, dann muß das der Eigenname ohne Zusatz sein. Denn den Namen trug die Person. Und das entspricht eben nicht unbedingt dem Lemma. Besonders nervend ist es, wenn sie Sortierung nach Beinamen passiert, wie ich es schon ein paar mal verzweifelnderweise erlebt habe (Hykkara, Lais von).

• Römische Namen: Hier wird es noch komplizierter. Im allgemeinen besteht der Name eines römischen Mannes aus drei Teilen - Pronomen (Vorname) * Gentilname (Familienname) * Cognomen (Beiname). Dabei ist der Vorname irrelevant. Sortiert wird im allgemeinen nach dem Gentilnamen, aber auch nach dem Cognomen. Darum gibt es immer zwei Sortierungen (Caesar, Gaius Julius; Julius Caesar, Gaius). Hier gibt es allerdings selten Probleme. Problematisch wird es bei römischen Frauen. Sie erhielten im allgemeinen den Gentilnamen des Vaters. Julius Caesars Tochter hieß Julia, Ciceros Tochter Tulia, Pompejus Tochter Pompeja. Auch soweit kein Problem. Vor allem während der Kaiserzeit jedoch kam es dazu, daß auch Frauen häufig einen Beinamen bekamen. Beide Namen waren letztlich gleich viel wert. Deshalb muß man in den PD beide Möglichkeiten finden. Als Beispiel mal Claudia Quinta. Sie wird zunächst wie ein moderner Name "Quinta, Claudia" gelistet. Doch erfolgt die Sortierung eigentlich noch eher und noch mehr nach "Claudia". Deshalb muß als Alternative auch in solchen Fällen immer "Claudia Quinta" in den PD stehen. Beide Male liegt die Betonung richtigerweise auf dem ersten Namensteil.

Ich weiß, es ist nicht immer ganz leicht zu verstehen, und ich hoffe mal, ich konnte es einigermaßen klar machen. Ich für meinen Teil stehe auf dem Standpunkt, daß eben auch in den PD alles korrekt sein sollte und man die Korrektheit nicht der Uniformität opfern sollte. Ich weiß auch, daß es ein paar Leute gib, die den "Kampf" verzweifelt aufgegeben haben oder die die PD nicht für wichtig genug halten. Marcus Cyron 16:23, 21. Jun. 2008 (CEST)

Hallo Marcus. Danke für die Ausführungen, mir zumindest haben sie viel geholfen! Ich unterstütze auch deine Forderung nach korrekten Personendaten. Evtl. sollte man deine Erläuterungen irgendwo auf der Hilfe-Seite unterbringen. Wenn "Lais" der Name ist, dann sollte er unter "Name" auftauchen, die Lemmaform sollte meiner Meinung nach aber auch unter ALTERNATIVNAMEN auftauchen (wie bei Lais von Hykkara). Bei römischen Namen ist es das gleiche: Unter Name die häufigste Ansetzungsform unter entsprechenden Wissenschaftlern (nicht nach Laien-Vorstellung), alle anderen üblichen Formen sollten unter "Alternativnamen" auftauchen. Evtl. sollte ein HTML-Kommentar vor die Personendaten gepackt werden (<!-- Achtung: ... -->, damit unerfahrene Personendaten-Bearbeiter bei solchen Fällen nichts falsches löschen oder einfügen?! --APPER\^☺☹ 16:33, 21. Jun. 2008 (CEST)

Marcus Cyrons Erläuterungen zu den antiken Namen der Griechen und Römer sollten (möglichst ergänzt um andere zu anderen Zeiten/Regionen) auf eine Hilfeseite, wie APPER schon vorschlug. Das eigentliche ungelöste Problem ist aber ein anderes, es betrifft alle PD: Welche Bedeutung hat das NAME-Feld?

Zunächst: Alle Bearbeiter der PD bemühen sich, diese korrekt auszufüllen, Vandalen haben wir hier zum Glück nicht. Aber was heißt 'korrekt'? Konkret für das NAME-Feld gibt es zwei Deutungen, die oft verschiedene Ergebnisse liefern:

(F) Die Abgrenzung des Felds vom ALTERNATIVNAMEN-Feld ist technischer Natur, nicht inhaltlicher. Konkret: Der Name in NAME gibt (mit gewissen Umstellungen) das Lemma wieder. Ob dies der/ein 'wirklicher' Name der Person war, spielt keine Rolle.

(I) Die Abgrenzung des Felds vom ALTERNATIVNAMEN-Feld ist inhaltlicher Natur, nicht technischer. Konkret: Der Name in NAME gibt (mit gewissen Umstellungen) den/einen 'wirklichen' Namen der Person wieder. Ob das Lemma diesem Namen entspricht, spielt keine Rolle.

Keine dieser Auffassungen ist an sich falsch. Notwendig ist aber die Einigung auf eine davon. Zur Zeit basieren die Fehlerlisten von sk auf Interpretation (F), entsprechend die bearbeiteten PD. (Es sei angemerkt, dass niemand widersprach, als diese Interpretation in Pflicht: NAME identisch mit Artikeltitel vorgeschlagen wurde.)

Wenn beides möglich ist, welche Interpretation ist geeigneter?

(F) Dies hat den Vorteil, die Korrektheit des NAME-Felds automatisch überprüfen zu können. Das bedingt leider, dass das Feld dem Lemma sehr wenig Information hinzufügt.

(I) Automatische Kontrolle gelingt nicht, aber eine Zusatzinformation wird geliefert: Dies ist 'der' 'eigentliche' Name bzw. jedenfalls einer 'der' 'eigentlichen' Namen. (Trotz der vielen Relativierungen ist das im konkreten Fall i.d.R. eine wertvolle Zusatzinformation.)

(F:I) Der große Nachteil von (F) ist: es ist wenig plausibel. Unter 'NAME' erwartet man (der Fachmann wie der 'naive' Nutzer, ausgenommen höchstens Programmierer) eine inhaltlich bestimmte Angabe.

Entscheidend ist, wie gesagt, die Einigung auf eine der grundsätzlich beiden möglichen Interpretationen. Alle weiteren gewünschten Namen können unter ALTERNATIVNAMEN angegeben werden (eventuell mit Regeln für die Reihenfolge), darunter auch das Lemma (sofern es nicht zwecks Namensdifferenzierung gekünstelt ist). Auch ein Korrektheitstest ähnlich dem jetzigen wäre auch bei (I) möglich, er hieße nur: Unter den Namen sollte einer sein, der dem Lemma entspricht.

ALso: Eine definitive Entscheidung ist nötig. Meine Stimme hat (I). --Griot 20:41, 21. Jun. 2008 (CEST)

Es gibt noch ein weiteres Problem. Asiatische Namen (japanische, chinesische, koreanische v.a.). Dort werden die Namen ja andersrum angegeben. "Nachname Vorname". Darum hat es sich eingebürgert, bei den Alternativnamen die umgedrehte Form anzugeben. Fengtong Yu wird dann um mal ein Beispiel zu bringen als "Yu, Fengtong" und "Fengtong, Yu" angegeben. Mittlerweile wird aber auch das gelöscht. Marcus Cyron 13:59, 26. Jun. 2008 (CEST)

Verstehe ich Dich richtig? ('Es hat sich eingebürgert' heißt noch nicht, dass Du es für gut hältst.) Du meinst, in NAME + ALTERNATIVNAMEN von Yu Fengtong sollten sowohl 'Yu, Fengton', als auch 'Fengton, Yu' erscheinen? Weil nicht davon ausgegangen werden kann, dass die große Mehrzahl der potentiellen Nutzer Yu als den Familiennamen erkennt? --Griot 22:48, 26. Jun. 2008 (CEST)

So, ich steige hier aus. Am 2. Juli wurde wieder im großen Stil falsch in den PD antiker Personen geändert. Ich habe die Schnauze echt voll. Ich werde es nicht mehr revertieren, aber ich werde mir überlegen, ob ich ein MB zur Abschaffung initiiere. Bislang scheint es nur dazu gut zu sein, damit Leute die nicht fähig sind Artikel zu schreiben Edits sammeln können. Marcus Cyron 13:47, 7. Jul. 2008 (CEST)

Hallo Marcus, so verständlich Dein Frust ist, dies ist wohl kaum die Lösung. Wie ich ja auch inzwischen bemerken musste, gilt hier i.d.R. das Motto "erst schneiden, dann messen". Das liegt aber eher weniger an denen, die guten Gewissens nach nicht ausreichend durchdachten Richtlinien handeln. Schwerer wiegt, dass die Teilnahme an den Diskussionen über geeignete Formen "suboptimal" ist, wenn ich mich mal auf ein Zitat zurückziehen darf. --Griot 15:23, 7. Jul. 2008 (CEST)

NAME und Apostroph

In der Fehlerliste gibt es die gleichnahmige Rubrik. Beim Abarbeiten ist mir aufgefallen, das es gerade bei französischen Namen mit de unterschiedliche Angaben von Name der Personendaten und Defaultsort gibt. Beispielsweise Lucie-Madeleine d’Estaing, dort wird erstmal ein anderes Apostroph verwendet, als im Lemma, aber die Sortierung von Defaultsort und Name unterschiedlich, daher habe ich den Artikel nicht bearbeitet, hingegen Luigi d’Aragona hatte die gleiche Sortierung von Name und Defaultsort, daher habe ich ihn bearbeitet. Christian d’Elvert beispielsweise schreibt das de aus Charles Henri d’Estaing nicht. Gibt es dazu eine einheitliche Regel oder kann man mir einen guten Tipp geben, wie das am besten zu handhaben ist? Vielen Dank. Der Umherirrende 09:45, 8. Jul. 2008 (CEST)

Unter Hilfe:Kategorie#Sonderbehandlung von Personennamen wurden neue Hinweise zur Sortierung eingestellt. Sollten diese auch hier gelten? Zum großteil halte ich sie für plausibel. Der Umherirrende 14:47, 10. Jul. 2008 (CEST)

Vorlagen

Hallo, hier also die versprochene Diskussion zur Verwendung von Vorlagen in den Personendaten. Der maschinellen Auswertbarkeit wegen ist klar, dass es maximal eine sehr kleine Liste zulässiger Vorlagen geben kann, bisher hat sich herausgestellt, dass nur die Vorlagen zur Sprachkennzeichnung (lang und zh) nötig sind (ob die Vorlage zh nötig ist, kann später diskutiert werden). Nun gilt es abzuwägen: Vorlagen komplett zu verbieten erleichtert die Auswertung, Sprach-Vorlagen zuzulassen erhöht die Informationen in den Personendaten, da einzelnen Namen Sprachen zugeordnet werden können. Ich zähle einfach mal wild Argumente auf:

• Die Personendaten lassen sich mit Vorlagen nicht mehr so leicht extrahieren
• Mit einem regulären Ausdruck ist das zumindest bis auf das Feld STERBEORT relativ leicht möglich.
• Es muss eine zusätzliche Instanz zum Auswerten dieser Vorlagen in Auswertungsprogramme eingebaut werden, zumindest aber die Entfernung der Vorlage.
• Die Informationen zur Sprache sind wichtige Zusatzinformationen
• Die Informationen zur Sprache können auch in der Klammer stehen.

Vor allem das letzte Argument überzeugt mich, evtl. das bisher übliche Vorlagen-Verbot beizubehalten. Oder habe ich da was übersehen? --APPER\^☺☹ 01:10, 3. Jun. 2008 (CEST)

Die einzige wesentliche Verwendung von Vorlagen in Personendaten, die bisher genannt wurde, ist die Angabe der originalen Schreibung von im Original nicht-lateinisch geschriebenen Namen (im weiteren kurz 'Originalname') im Feld ALTERNATIVNAMEN. Es genügt daher, über diesen Fall zu diskutieren. Die Angabe des Originalnamens erfordert - wenn sie korrekt erfolgen soll - nach bisherigem Wissensstand, sie in die Vorlage 'lang' (oder 'zh', das lasse ich im weiteren weg) einzubetten. Zunächst einmal wäre es gut, wenn jemand, der die Problematik kennt (hallo, Matthiasb), sich einmal dazu äußert, ob das Problem, welches durch die Verwendung nicht-lateinischer Zeichensätze außerhalb von 'lang' entsteht, ein zeitweiliges oder ein dauerhaftes ist. Ist es ein zeitweiliges, können wir uns diese Diskussion vielleicht sparen.

Welche Nach-, welche Vorteile hat also die Angabe des Originalnamens (neben den Nachteilen, die jede Angabe hat - mehr Arbeit, mehr Fehlermöglichkeiten)?

Nachteile:

• Die abgeleitete Notwendigkeit, im Feld ALTERNATIVNAMEN (und nur dort!) Vorlagen zuzulassen, erschwert die Extraktion der Personendaten.
• Sie erschwert ebenfalls die Auswertung. (Allerdings schätzt APPER oben ein: diese sei 'relativ leicht möglich'.)

Vorteile:

• Der Originalname ist die ursprüngliche, festeste, von der WP-Sprachversion unabhängige Information, welche über den Namen vorliegt.
• Aus dem Originalnamen können Schreibweisen in anderen Schriftsystemen abgeleitet werden, teilweise ganz, teilweise halbautomatisch.
• Der Originalname ist in der Regel nicht aus Umschriften eindeutig rekonstruierbar.
• Über den Originalnamen ist eine erste Verständigung zwischen verschiedenen Sprachversionen darüber möglich, ob dieselbe Person gemeint sein könnte oder nicht.
• Die meiste Information über eine Person liegt in der Regel in der Schrift seines Originalnamens vor, ist also über diesen aufzufinden - nicht aber über Umschriften.
• Ganz allgemein ist es für eine (hier: verteilte) Datenbank immer angebracht, sich nicht unnötig auf die momentan sichtbaren Verwendungen zu konzentrieren, sondern die Information AUCH in möglichst ursprünglicher, nicht in Richtung konkreter Anwendungen vorbereiteter Form vorzuhalten. Die ursprüngliche Information aber ist hier der Originalname.

Worum es nicht geht:

• Information zur Sprache zu liefern ist nicht Zweck dieser Angabe. Diese kann in den geklammerten Zusatzinformationen untergebracht werden. (Ob sie dort auch angegeben werden sollte, wenn sie [unsichtbar] bereits in der 'lang'-Vorlage enthalten ist, ist nebensächlich. Dies wäre allerdings bei Zulassung der Vorlage noch festzulegen.)

Ob ein Verbot von Vorlagen überhaupt die genannten Nachteile vermeiden würde, ist übrigens zweifelhaft, da die Benutzer, welche den Originalnamen als unerlässlich ansehen, ihn trotz Verbot eintragen: sei es mit Vorlage, sei es ohne - also inkorrekt. Dies ist bereits jetzt der Fall, obwohl in der Beschreibung für ALTERNATIVNAMEN nichts dazu gesagt wird.

(Frage nebenbei an APPER und sk: welche Programmiersprache benutzt Ihr zur Auswertung?) --Griot 14:49, 7. Jun. 2008 (CEST)

Perl. -- sk 18:31, 7. Jun. 2008 (CEST)

Also erstmal: es gibt meiner Meinung nach kein Verbot für den Originalnamen und meiner Meinung nach gehört der natürlich in dieses Feld. Es geht meiner Meinung nach nur darum, ob dieser in der Vorlage ist oder einfach so ins Feld geschrieben wird. Du schreibst, Informationen über die Sprache zu liefern, ist nicht Sinn dieser Vorlage - dann sollten wir erst weiterdiskutieren, wenn auch mir klar wird, was dann eigentlich der Sinn ist?! Kann mir das jemand erklären? Die auf der Vorlagenseite erläuterten Zwecke sind in diesem Feld auch nicht nötig. Wozu also? PS: Ich benutze hauptsächlich PHP. --APPER\^☺☹ 20:50, 7. Jun. 2008 (CEST)

Oh. Da scheinen wir aneinander vorbeige'redet' zu haben - uns aber zum Glück im Wesentlichen einig zu sein. Die Vorlage 'lang' an sich ist mir gleichgültig. Es geht mir nur um die Aufnahme der Originalnamen. Und da stützte ich mich voll auf die Aussage von Matthiasb in [7], dass das korrekt nur mit Vorlage gehe. Eine Aussage, auf die ich auch mehrmals hinwies und der nie widersprochen wurde. Ich selbst kann nicht beurteilen, ob sie zutrifft und welche Folgen der Vorlagenverzicht wirklich hat. (Sollte 'lang' wirklich verzichtbar sein, käme man gewiss auch ohne 'zh' zurecht, trotz eines gewissen Komfortverlustes.) --Griot 22:05, 7. Jun. 2008 (CEST)

Okay, also wir sind uns einig, dass der Originalname wichtig ist, das werde ich auch explizit nochmal angeben. Wegen korrekten HTMLs ist diese Angabe natürlich wirklich nötig, da hat Matthiasb recht. Wir sollten die Vorlage:lang also erlauben, ich finde jedoch, wir sollten zusätzlich das Sprachattribut in den Klammern angeben, sodass man die Vorlage einfach "wegschneiden" kann und nicht analysieren muss. Ich spreche mich aber an dieser Stelle explizit gegen die Vorlage:zh aus, da in ihr sehr viel mehr Informationen stecken (schon alleine mehrere Namen) und das die Auswertung ungemein erschwert. --APPER\^☺☹ 15:37, 8. Jun. 2008 (CEST)

Wunderbar, wir sind ja fast am Ziel. (Vielleicht ist eine kurze Überlegung, ob 'zh' mit Beschränkung auf nur einen Namen und mit vorgeschriebenen Parameter 'kurz=' viel Mehraufwand macht, noch möglich? Aber wichtig ist's nicht.) Für die Angabe chinesischer Namen mittels 'lang' hatte eine Diskussion auf der Disk.-seite von 'Vorlage:zh' schon ergeben, dass folgende Formen nötig (oder nur angebracht?) sind:

{{lang|zh-Hans|<kurzform>}}
{{lang|zh-Hant|<langform>}}
{{lang|zh-????|<einheitsform>}}        -- und hier fehlt mir noch eine Information

Die Sprache zusätzlich in der folgenden Klammer anzugeben, unterstütze ich. --Griot 16:32, 8. Jun. 2008 (CEST)

Sehr gut. Es wäre wohl gut, irgendwo einen Leitfaden abzulegen, vor allem für die zh-Vorlage, damit jeder, der sich nicht damit auskennt, weiß, wie man die Vorlage:zh durch Lang-Vorlagen für die Personendaten ersetzt. --APPER\^☺☹ 17:08, 8. Jun. 2008 (CEST)

Ist die Aufnahme oder Nicht~ der lang-Vorlage inzwischen geklärt? Dann sollte man es in die Dokumentation fürs Alternativnamen-Feld schreiben. Oder ist es einfach egal? Es stört mich zwar nicht besonders (ist ja die Sysyphos-Arbeit anderer); aber etwas eigenartig finde ich schon, dass alle paar Wochen ein PD-fix-Edit auf meiner Beoliste lang-Vl’n wahlweise einfügt oder entfernt. Und schön zu wissen, wie man anderen Arbeit abnimmt, indem man das gleich beim Einstellen fixt, wäre es auch. --Asakura Akira 09:15, 4. Jul. 2008 (CEST)

Wenn das mit der HTML-Kodierung und der Vorlage lang stimmt, dann würde ich mein Skript entsprechend anpassen. Alle anderen Vorlagen sollten aber weiterhin entfernt oder in lang umgewandelt werden. -- sk 07:20, 13. Jul. 2008 (CEST)

Ortsangabe "auf See"

Ich schlage vor, das wir bei den Ortsangaben eine Standardisierung aller auf See gestorbener durchführen. Mein Vorschlag wäre "auf See, ..." z.B.:

• auf See, Atlantik
• auf See, Mittelmeer bei der Schlacht von XY
• auf See, Nordpazifik
• auf See, Großer Wannsee
• auf See, Elbe

Ich hatte erst überlegt "auf See im ..." aber z.B. bei Großer Wannsee muss man dann den Link anpassen zu "auf See im Großen Wannsee". Alternativ "auf See: Großer Wannsee". Ich würde das bei alle Ertrunkenen und auf Schiffen geborenen und gestorbenen Personen so handhaben. -- sk 04:19, 17. Jul. 2008 (CEST)

Das ist so möglich. Allerdings sind Angaben wie "auf See, Elbe" etwas(?) seltsam... Und wirklich notwendig scheint mir eine solche Form nicht zu sein. "Ort" als "bewohnter Ort" zu interpretieren, ist ohnehin zu eng. Man findet ja auch "Nanga Parbat" und "am Mt. Everest". Wenn "Ort" allgemeiner interpretiert wird, reichen "Atlantischer Ozean", ..., "Elbe", "Mount Everest" völlig aus.

Welche präpositionalen Ausdrücke bleiben notwendig? (Es geht hier nur um die primäre Angabe, Zusatzangaben bleiben unberücksichtigt.) Auf "über dem Atlantik" kann man wohl verzichten, die wenigen km sollten vernachlässigbar sein. Ich sehe nur zwei Formen:

• bei Steinhude
• zwischen Oberammergau und Unterammergau

sowie die Variante

• beim Steinhuder Meer

("nahe" hat eine engere Semantik als "bei", weshalb "bei" m.E. geeigneter ist.) --Griot 23:01, 17. Jul. 2008 (CEST)

"Auf See" bezieht sich auf See im Sinn von Meer. Großer Wannsee ist ganz einfach Berlin. --08-15 00:04, 18. Jul. 2008 (CEST)

Erweiterung des Datumsformat

Ich möchte vorschlagen, dass wir Datumsangaben wir "4. April 20. Jahrhundert" mit aufnehmen. Bsp. Jean Carol und zahlreiche japanische Mangazeichner. Bei diesen Leuten ist zwar der Tag aber nicht das Jahr bekannt. -- sk 03:29, 17. Jul. 2008 (CEST)

Ich habe das so in das geänderte Datumsformat aufgenommen. --Griot 23:50, 23. Jul. 2008 (CEST)

Pflichtangabe Geburtsdatum?

Ich denke es wäre sinnvoll das Feld Geburtsdatum als Pflichtfeld zu betrachten. Über das Geburtsdatum sollte eigentlich in 99,9 % der Fälle eine Aussage treffbar sein. Also mindesten das Jahrhundert sollte machbar sein z.B. "19. Jahrhundert". Selbst wenn das konkretes Sterbedatum z.B. "9. Mai 1660" ist lässt sich bei dieser Person im Datenfeld Gebursdatum "16. Jahrhundert oder 17. Jahrhundert" eintragen, weil man ja nicht 100% sicher sagen kann in welchem Jahrhundert er nun genau geboren ist. Was meint ihr dazu? -- sk 21:20, 19. Jul. 2008 (CEST)

Dann könnten wir ja auch endlich die überflüssigen Geboren-/Gestorben-Kategorien löschen :-) -- Harro von Wuff 01:16, 20. Jul. 2008 (CEST)

Naja, man könnte, aber man muss nicht. Schließlich kann derzeit niemand mal so fix auf die Schnelle zeigen wer alles im Jahr 1647 gestorben ist, das geht nur mit den Kategorien. -- sk 05:48, 20. Jul. 2008 (CEST)

Gut, es gibt bestimmt alle zusammengerechnet ein Dutzend Leute, die tatsächlich beim Geburtsjahr/Todesjahr nachsehen wollen. Die erhalten dann natürlich eine wirklich wertvolle Information. Und eine solch entscheidende Erkenntnis über eine PD-Suche abrufen zu müssen, ist natürlich eine unverantwortliche Verkomplizierung. Zumal man da überflüssigerweise auch noch so völlig unnütze Daten wie den genauen Geburtstag abrufen kann und das geht eben nicht mit einem Klick, das ist absolut benutzerunfreundlich. Und wenn in 0,1 % der Fälle dann noch der Toolserver ausfällt und man nicht sofort rankommt, dann bricht natürlich die Welt zusammen. Dafür lohnt es sich schon, wohl so 300 000 Kategorieeinträge vorzuhalten. Außerdem macht es ja auch diejenigen glücklich, die die To-do-Liste abarbeiten können und so zu Edits kommen, ohne sich anstrengende Gedanken machen zu müssen. Das fördert die Zugehörigkeit und das Gefühl, etwas Wichtiges geleistet zu haben.

Oder anders ausgedrückt, rational war die Diskussion um diese Kategorien noch nie. Und wenn sich alle erst einmal an etwas gewöhnt haben, dann fragt keiner mehr nach dem Sinn. Egal. Ich lästere ja bloß, es stört mich nicht mehr und es ärgert mich auch nicht, ich finde es richtig lustig (inklusive Ablästern). Besonders wie die Leute ins Schwimmen geraten, wenn man sie auf Nutzen-Argumente anspricht. Ist auch keinerlei Kritik an dir, du machst eben auch mit. Mach nur wie du meinst, du machst hier großartige Arbeit. Ein faszinierendes Phänomen bleibt es dennoch. :-) Gruß -- Harro von Wuff 14:43, 20. Jul. 2008 (CEST)

Das Feld bei neuen Artikeln zum vielleicht nicht "Pflicht-", aber sagen wir "nach Möglichkeit (notfalls grob) zu füllenden" Feld zu machen, wäre sinnvoll. Ebenso, zu empfehlen, es zu füllen, wenn ein Artikel ohnehin bearbeitet wird. Es wäre jedoch kaum gerechtfertigt, einen Artikel nur zu diesem Zweck zu bearbeiten. Noch weniger, eine Aktion zu starten, das durchgängig von Hand zu tun. Der Informationsgewinn wäre mäßig, der Aufwand hoch: beim letzten Dump war das Feld in 13171 Artikeln leer. Gerechtfertigt wäre allenfalls, dass ein Bot in den (im letzten Dump) 5065 dieser Artikel mit nichtleerem STERBEDATUM ein GEBURTSDATUM einsetzt.

Viel kritischer ist der zur Zeit meist bescheidene Informationsgehalt der Kurzbeschreibung. Indizien hierfür sind das 'ehemalig'-Problem und der 'Bürgermeister von Moskau'. M.E. sollte angestrebt werden, dass bei allen Ämtern die Amtszeit angegeben wird. Bei Sportlern die aktive Zeit bzw. (der Anfang ist oft nicht bestimmbar) deren Ende. Evtl. auch etwas mehr, z.B. bei Fußballern der wichtigste Klub, die Spielposition. Zur Zeit des Dumps gab es 13576 Artikel, in denen Fußball in der Kurzbeschreibung genannt wird. Nur in etwa 920 davon steht mehr als bla-bla-Information der Art 'französischer Fußballer'. Wirklich Sinn machen Änderungen m.E. aber auch hier nur, wenn sie in Richtung 'automatische Auswertbarkeit' gehen. Dazu wären Formen (eine wird nicht ausreichen) nötig, gewisse noch festzulegende Informationen anzugeben. Bei Fußballern könnte ich mir folgende Grundformen vorstellen:

absurdistanischer Fußballer (Stürmer, FC Kugel), aktiv bis 1999
absurdistanischer Fußballer (Stürmer, Nationalmannschaft, FC Kugel), aktiv bis 1999
absurdistanischer Fußballer (Stürmer, Nationalmannschaft, FC Kugel), 2008 noch aktiv (Fsv Murmel)

Weitere Angaben, etwa 'Fußballtrainer', könnten nach ';' angefügt werden. --Griot 17:19, 22. Jul. 2008 (CEST)

Also meiner Meinung nach geht das zu dings, äh, weit. Die Personendaten sind ja zur Identifizierung der Personen. Das ist ja schon eine Kurzbiografie, wobei viele Spieler ja daneben noch bei SC Pille oder VfB Kirsche erfolgreich waren. Diese Daten sind typisch für die Fußballer-Infobox.

Ich habe eine Formulierung, das Füllen der Datumsfelder sei erwünscht, in die Beschreibung des Datumformats aufgenommen. Sollte die Diskussion hier noch zu schärferen oder schwächeren Forderungen führen, kann das ja noch angepasst werden. --Griot 23:56, 23. Jul. 2008 (CEST)

Niemand sonst diskussionsbereit... Zunächst zu den Geboren-/Gestorben-Kategorien. 'Streichung' kann hier zweierlei bedeuten: (a) Streichung der expliziten Angabe im Artikel; (b) Streichung dieser Kategorien aus dem System. Für (b) sehe ich keine guten Argumente. (a) dagegen ist vernünftig - eine Angabe wie das Geburtsdatum sollte perspektivisch nur an einer Stelle im Artikel stehen. Zur Zeit sind es 2 1/2 bis 3 1/2 Stellen: Einleitungssatz, PD, evtl. Infobox, zur Hälfte in den Kategorien. Sobald Geburts- und Sterbedatum in allen PD steht, in einer normgerechten Form, kann die Vorlage Personendaten so ausgebaut werden, dass sie Geboren-/Gestorben-Kategorien automatisch erzeugt. Folge: keine widersprüchlichen Angaben, weniger Arbeit. (Allerdings ist eine 'kleine' Bedingung noch nicht gegeben: ein Satz von Zeichenkettenoperationen für die Vorlagenprogrammierung ist erforderlich. [Dass dieser noch fehlt, ist ohnehin unverständlich.])

Zum Informationsgehalt der Kurzbeschreibung. Ja, mein Vorschlag ist zweifelhaft. Aber mehr automatisch auswertbare Information halte ich für notwendig. Man könnte die Infobox mit heranziehen. Allerdings gibt es für viele Sportler keine, z.B. haben nur etwa 5800 Fußballer eine Infobox, das ist wohl knapp die Hälfte derer, die einen Artikel haben. (Zu den genannten 13576 gehören auch Trainer und Funktionäre.) Für Infobox-Erstellung braucht es vermutlich Fans... Nun ist Information über Sportler für mich auch nicht so wichtig - solche über z.B. Politiker aber schon. Die Fragen bleiben: welche zusätzliche Information ist erwünscht? Wie sollte sie angegeben werden? Wie erreicht man, dass sie angegeben wird?

Ach ja, Zweck der PD 'Identifizierung der Personen'. Das sehe ich gar nicht so, es ist nur ein kleiner Nebenzweck. Es geht m.E. um Informationskonzentration in möglichst automatisch auswertbarer Form. --Griot 18:01, 28. Jul. 2008 (CEST)

Und wozu dienen die konzentrierten Informationen der Personendaten? Zur Identifizierung, für eine Personenliste, nicht für minimalistische Berufsgruppenvergleiche. Außerdem sind interessante Daten so komplex und, z. B. bei Politikern und Fußballern, so unterschiedlich, dass man die gar nicht in eine Kurzbeschreibungszeile packen kann. Und pflegbar wäre das ohnehin nicht, dieses PD-Feld ist auch so schon das uneinheitlichste.

Bei den Fußballern schätze ich mal, dass 80-90 % der Neuzugänge ne Box haben und die alten holen auf. Bei den GG-Kats waren es noch gar nicht so lange auch nur 50 %. Das ist eine Frage der Zeit. Viele Artikel (Fußballer, aber auch Orte, Alben) sind oft nur noch kommentierte Infoboxen, obwohl es nicht sein sollte.

Und bei den GG-Kats stellt sich mir nach (b) eher die Frage nach guten Argumenten für ihr Verbleiben. Aber warten wir mal die PD-Aktualisierung und vielleicht die Entwicklung der Auswertemöglichkeiten ab, dann kann man mehr sagen. Gruß -- Harro von Wuff 20:41, 28. Jul. 2008 (CEST)

Ja, warten wir's ab. Gruß, --Griot 13:46, 30. Jul. 2008 (CEST)

Verlinkung in den Personendaten

Ich bitte mal um eine grundsätzliche Klärung: welche Felder dieser Vorlage sollen/dürfen wiki-verlinkt werden und welche sollen/dürfen nicht verlinkt werden? Und wo kann ich das später nochmal nachlesen, falls diese Disk. archiviert wird? Ich stelle nämlch immer wieder fest, dass die Verlinkung mancher(?) Felder rückgängig gemacht werden mit der Bemerkung: "PD fix", und ich sehe darin irgendwie kein konsequentes Verhalten. --Hdamm 12:19, 30. Jul. 2008 (CEST)

Also NAME, ALTERNATIVNAMEN, GEBURTSDATUM, STERBEDATUM sollen auf keinen Fall verlinkt werden. Bei GEBURTSORT und STERBEORT soll möglichst nur der genaue Ort verlinkt werden. Bei KURZBESCHREIBUNG besteht, denke ich, noch Klärungsbedarf. Andim 12:52, 30. Jul. 2008 (CEST)

Es hat - jedenfalls in 'historischer Zeit' (= in diesem Jahr) - noch keine zu einem Ergebnis führende Diskussion über (u.a.) die Verlinkung in GEBURTSORT und STERBEORT gegeben. Ich halte es daher für dem Grundsatz 'respektiere die Arbeit anderer' angemessen, in diesen Feldern vor einer Klärung weder eine vorhandene Verlinkung zu beseitigen, noch Zusatzangaben wie Land etc. zu entfernen. (Es sei denn, man ändert diese Felder ohnehin, versteht sich.) --Griot 13:43, 30. Jul. 2008 (CEST)

Danke für die Hinweise. Wo würde ich denn - falls ein Diskussiosergebnis erzielt worden wäre - darüber erfahren? --Hdamm 13:55, 30. Jul. 2008 (CEST)

Wir haben die Verlinkung von Geburtsort und Sterbeort vor einigen Monaten diskutiert, siehe weiter oben auf dieser Seite, was eine Folgediskussion hierzu war. Beides schon in diesem Jahr, also nicht historisch. Das man Zusatzangaben wie Region oder Staat hinzufügt, ist eine Selbstverständlichkeit und braucht nicht diskutiert zu werden, da etwa bei der Druckausgabe die Verlinkung verloren geht. (Die Angabe Bremen, oder gar Bremen, Deutschland ist nicht eindeutig, siehe Bremen (Begriffsklärung)). --Matthiasb 10:28, 31. Jul. 2008 (CEST)

Für die Datums- und Namensfelder habe ich die Nichts-Verlinken-Regel mal auf der Seite vermerkt. Bei den Orten gibt es ja schon eine relativ eindeutige Regelung. Ich nehme mir seit Monaten vor, mal eine tatsächliche Auswertung zu starten, die sicher hochspült, inwieweit das funktioniert und sinnvoll ist. Aber bisher sehe ich da keine Probleme. Das einzige undiskutierte ist meiner Meinung nach das Kurzbeschreibungsfeld. Gibt es irgendeinen Grund, dort zu verlinken? Mir würde keiner einfallen, aber vielleicht ja jemand anderem

Aber nochmal eine Rückfrage zur eigentlichen Frage: Wo gab es denn Änderungen ausschließlich der Verlinkung wegen? Es gibt keinen Grund, Artikel nur wegen der Verlinkung in Personendaten zu bearbeiten. Höchstens zum Einfügen der Verlinkung zu einem Ort (und dort auch nur den Ort, nicht das Land). Wenn du Beispiele hast, kann man evtl. den Bearbeiter darauf hinweisen. --APPER\^☺☹ 01:28, 31. Jul. 2008 (CEST)

Ich hatte mehrere Änderungen gesehen (wo das war, kann jetzt nicht mehr genau sagen), in denen - glaube ich - nur die Datumsfelder entlinkt wurden. In meiner Einfältigkeit hatte ich angenommen, dass deswegen gar kein Link in den PD erlaubt sei. --Hdamm 09:42, 31. Jul. 2008 (CEST)

Zu dem Kurzbeschreibungsfeld sieh mal bitte dieses Diff. Ist das jetzt hier sinnvoll oder nicht? --Hdamm 09:46, 31. Jul. 2008 (CEST)

Die Verlinkung des Sterbeortes ist auf jeden Fall sinnvoll. Zur Kurzbeschreibung gibt's wie gesagt noch verschiedene Ansichten. --APPER\^☺☹ 14:43, 31. Jul. 2008 (CEST)

@APPER: Gibt es irgendeinen Grund, dort zu verlinken? Gegenfrage: Gibt es irgendeinen Grund, dort nicht zu verlinken? --Matthiasb 10:34, 31. Jul. 2008 (CEST)

Der einzige Grund, der mir einfällt ist, dass das Platz auf den Servern verbraucht und die Links-Tabelle füllt, aber das ist ziemlich vernachlässigbar. Ich finde, wir sollten das Feld nicht anfassen, sprich keine Entlinkungen vornehmen (wobei es sicher auch da Ausnahmefälle gibt), alles zu verlinken finde ich aber auch nicht sinnvoll. Im Endeffekt handelt es sich um ein Textfeld, das irgendwo als Kurzbeschreibung zur Person angezeigt wird. Ich bin da recht emotionslos ;) --APPER\^☺☹ 14:43, 31. Jul. 2008 (CEST)

Aber wenn ich mir die Personensuche so ansehe, dann werden Links in der Kurzbeschreibung gar nicht ausgewertet? Oder ist da noch was in Planung? --Hdamm 15:05, 31. Jul. 2008 (CEST)

Nein, da ist nichts in Planung, weil ich Links an dieser Stelle für überflüssig halte. Aber vielleicht gibt es ja Personen, die diese auswerten können und wollen - daher keine Entlinkungen vornehmen, aber Verlinkungen extra vorzunehmen ist auch nicht sinnvoll, da es eben bisher keinen Einsatzzweck gibt. --APPER\^☺☹ 15:24, 31. Jul. 2008 (CEST)

Danke für die ausführlichen Auskünfte. --Hdamm 16:08, 31. Jul. 2008 (CEST)

Die Aussagen zur Kurzbeschreibung überraschen mich etwas. Ich hatte dort (nach mehreren entsprechenden Vorschlägen Stefans, denen nicht widersprochen wurde) Nicht-Verlinkung als vereinbart angenommen. Also lasse ich Links künftig drin.

Die Verlinkung des eigentlichen Geburts-/Sterbeorts wurde diskutiert (wenn man das so nennen will, wenn alle derselben Meinung sind: Verlinken). Nicht aber die Verlinkung kleinerer (Ortsteile) und vor allem größerer Einheiten - und auf diese bezog ich Hdamms Frage (vielleicht irrtümlich). Wie m.E. auch noch nicht vereinbart ist, ob/wann/wie kleinere/größere Einheiten angegeben werden dürfen/sollten. (Ich bin sehr dafür, Matthiasb' obiges Argument bestärkt mich darin. Es gab aber Bearbeiter, die alles nach dem Komma tilgten. Ich hielt das bisher für bedauerlich, aber regelgerecht.)

Vorschlag für eine vorläufige Festlegung: Neben sowieso dem Ort werden kleinere Einheiten verlinkt, sowie - falls der Ort noch keinen Artikel hat - aufsteigend größere Einheiten bis zur ersten 'blauen'. Darüber ist Verlinkung freigestellt.

Sollte zusätzlich Konsens erzielt werden, die Angabe von Region, Staat, ... mindestens zu respektieren, würde mich das freuen. --Griot 17:21, 31. Jul. 2008 (CEST)

Ich bin sehr dafür, höhere Einheiten beim Ort mit anzugeben und zu verlinken, auch wenn der direkte Ort einen Artikel hat. Wieso sollte jemand, wenn er nur wissen will, in welchem Land jemand geboren ist, ganze Kategorienbäume durcharbeiten? Ich dachte, dass das relativ klar ist (siehe Beispiele auf der Hilfe-Seite. Bei den dortigen Beispielen ziehe ich die zweite der Alternativen vor (komplette Verlinkung). Eine Tilgung des Inhalts nach dem Komma halte ich für nicht regelgerecht und nicht akzeptabel. Ich bin sehr für die Regelung, dass zusätzlich der Staat und eine Region (mit Links) angegeben werden können. Eine Soll-Regelung ist übertrieben, dann gibts wieder 1000 Leute, die das ändern, aber die vorzuziehende Form ist es meiner Meinung nach schon. --APPER\^☺☹ 12:49, 1. Aug. 2008 (CEST)

Datenfelder#Datum

Kann mir mal jemand erklären warum nicht: Ein Artikel sollte aber nicht geändert werden, nur um einen solchen Link zu tilgen. (Tabelle Datum falsch richtig). Beim Sichten stoße ich auf einen Benutzer, der das Datum sukzessive verlinkt. Soll ich das jetzt nicht wieder rückgängig machen??? Wozu dann überhaupt diese Regel? Gruß--Der ohne Benutzername 05:16, 3. Aug. 2008 (CEST)

Auf jeden Fall sollte dieser Nutzer darauf hingewiesen werden, dass diese Änderung nicht erwünscht ist. Rückgängig machen ist übertrieben, aber es sollte auf jeden Fall dafür gesorgt werden, dass es von diesem Nutzer nicht weiterhin Änderungen in diese Richtung gibt. --APPER\^☺☹ 06:01, 3. Aug. 2008 (CEST)

Habe den Benutzer natürlich direkt angesprochen. Allerdings wurden schon einige Vorlagen:PD geändert, da er das anscheinend als seinen Tätigkeitsbereich gewählt hat.

Es stellt sich mir auch die Frage nach dem Nutzen dieser Regel, wenn man sie nicht im nachhinein anwenden darf! So wird irgendwann in allen Vorlagen das Datum verlinkt sein. Wenige neue Benutzer werden auf diese Seite hier stoßen und daher sollte die Regelung wenigsten auch bei WP:VL auftauchen... Oder kassiert werden. Gruß--Der ohne Benutzername 17:05, 3. Aug. 2008 (CEST)

Ich dachte, dass es dort relativ eindeutig ist - es wird ja unter "daten" erwähnt, dass Daten nur in besonderen Fällen und in der Einleitung verlinkt werden soll, ich hab aber einen Satz ergänzt, dass dies bei Personendaten nicht passieren soll. Es werden sicher nicht irgendwann alle Datumsangaben verlinkt sein, der Anteil sinkt sogar eher und dass es noch recht viele Verlinkungen gibt ist eher eine Altlast. Viele Abarbeiter von Fehlerlisten entlinken und wenn es Botaufgaben gibt und ein Personenartikel sowieso bearbeitet wird, entlinkt zumindest mein Bot sowas auch zusätzlich ([8]). Nur extra eine weitere Bearbeitung zur Entlinkung muss halt nicht sein. --APPER\^☺☹ 17:16, 3. Aug. 2008 (CEST)

Ich bin beim abarbeiten einer Liste (Akas Tool für veraltete Sichtungen) auf die Artikel gestoßen. Für die meisten Artikel, in denen der Benutzer editiert hat, steht noch die erstmalige Sichtung an, die ich gerne machen würde... Aber wie soll ich da jetzt verfahren? Entlinken oder nicht? Gruß--Der ohne Benutzername 17:28, 3. Aug. 2008 (CEST)

Ich würde es nur entlinken, wie schon weiter oben gesagt, wenn in dem Artikel auch was anderes zu erledigen ist, denn wer weiß, vielleicht kommen wir ja schon morgen zu einem anderen Konsens. ;-) Editiermöglichkeiten gibt es aber eh' in fast jedem Artikel. Und BKL-Verlinkung sollen ja in (fast) jeden Fall aufeglöst werden. --Matthiasb 00:00, 4. Aug. 2008 (CEST)

Feld für die PND

Weiß jemand, warum die PND nicht in die PD integriert wird? Im Grunde geht es bei der PND vor allem um die eindeutige Zuordnung eines Namens zu einer Person, sie gehört also thematisch zu den Personendaten. Der irritierende und daher standardmäßig ausgeblende Link zum Bibliothekskatalog, bei Personen, zu denen "kein Treffer im DNB-OPAC" vorliegt (z.B. Jim Lehrer), könnte man dadurch eleganter lösen. (Vorschlag: Das PND-Feld in der PD ist standardmäßig auf die Info zur Person verlinkt [9] und bei Bedarf wird unter "Weblinks" wie bisher die Verknüpfung mit den Publikationen hinzugefügt [10].) --Kolja21 19:27, 25. Aug. 2008 (CEST)

Eine Diskussion dazu unter Hilfe Diskussion:PND#Verwirrung angeregt. --Kolja21 21:23, 9. Sep. 2008 (CEST)

A Fine Frenzy

„A Fine Frenzy“ ist der aktuelle Künstlername der Sängerin Alison Sudol und Lemma des Artikels. Die Frage ist jetzt, ob der Name im Feld NAME jetzt als „A Fine Frenzy“ oder „Fine Frenzy, A“ eingetragen wird. Ich tendiere zu letzterem, kann jedoch keine konkreten Vorgaben für diesen Fall finden. -- net 16:04, 19. Okt. 2008 (CEST)

Wenn du den Künstlernamen als "echten" Namen behandelst, musst du ihn unter "Frenzy, A Fine" eintragen. This is America: Last-, First- and Middlename. (Bei einer Spanierin wäre der Fall anders.) Da "A" und "Fine" keine geläufigen Vornamen sind, würde ich den fiktiven Familiennamen aber nicht abtrennen. --Kolja21 16:12, 19. Okt. 2008 (CEST)

Formulierungsvorschlag

Die Ergänzung könnte so aussehen:

Bei einem Künstlernamen muss man im Einzelfall entscheiden, ob er als "echter" Name behandelt und entsprechend beispielsweise unter "Twain, Mark" (Mark Twain) eingetragen wird. (Bei einem Pseudonym wie 50 Cent ist das wenig sinnvoll.)

Sinngemäß. Das kann man bestimmt noch besser formulieren. --Kolja21 16:21, 19. Okt. 2008 (CEST)

Braucht man nicht unnötig zu verkomplizieren. A Fine Frenzy ist kein Personenname und Artikel werden im Deutschen wie im Englischen nachgeordnet, siehe Hilfe:Kategorien#Sortierschlüssel abweichend vom Lemma. -- Harro von Wuff 23:26, 19. Okt. 2008 (CEST)

Also „Fine Frenzy, A“? -- net 00:38, 20. Okt. 2008 (CEST)

Personengruppen

Wie soll bei Personen"gruppen" verfahren werden? Bei Gilbert & George war's klar, ich habe Gilbert Prousch und George Passmore angelegt für Kats und PD, dito für die Gebrüder Grimm mit Jacob Grimm und Wilhelm Grimm. Bei Chang und Eng Bunker tu ich mir aber irgendwie schwer, daraus zwei Personenartikel zu machen. Soll statt dessen ein PD-Satz für beide angelegt werden? Die Daten stimmen (in diesem Fall) ja überein. Aber es gibt auch andere, wo dank OPs es nicht immer stimmen muss (Ladan und Laleh Bijani wohl am selben Tag gestorben). Was tun? —Ulz Bescheid! 22:17, 27. Okt. 2008 (CET)

Redirects für die Einzelpersonen anlegen, und die Personendaten dort einfügen. --08-15 23:20, 27. Okt. 2008 (CET)

Pflichtkategorien Geschlecht und Nationalität in Personendaten integrieren

Können "Personendaten" erweitert werden um die Merkmale Geschlecht, Nationalität um so die entsprechenden (lästigen) Pflichtkategorien unter Person zu erübrigen? Gab oder gibt es hierzu eine Diskussion? -- Pfir 12:38, 26. Okt. 2008 (CET)

Soweit ich weiß, sind die Kategorien:Mann/Frau gewünscht, um Personen überhaupt als solche zu kategorisieren. Bei den Nationalitäten kenn ich auch keine Diskussion, ich gehe aber auch davon aus, dass das Kategoriensystem hier funktioniert und es keinen Bedarf gibt, hunderttausende Artikel zu bearbeiten ;) --APPER\^☺☹ 00:05, 28. Okt. 2008 (CET)

Die Nationalität ist bereits Teil der Kurzbeschreibung ("französischer Journalist" etc.). --Kolja21 01:23, 28. Okt. 2008 (CET)

Ich habe mal etwas im Archiv gestöbert und diese Disk gefunden. Die Meta-Daten können ja softwaremäßig aus den bestehenden Kats abgeleitet werden, diese würden dann überflüssig. Meta-Daten haben gegenüber Kats den Vorteil, das mit Ihnen Schnittmengen gebildet werden können, was bei Kats ja noch lange nicht der Fall sein wird. Nationalität=F und Tätigkeit = Journalist würde eine Riesenmenge Speicherplatz sparen und das System beschleunigen. Pfir 14:17, 28. Okt. 2008 (CET)

Das Problem ist: MediaWiki unterstützt derzeit keine Meta-Daten-Ablage anders als über Kategorien oder einfach im Text. Wenn man also komplette Personendatensätze will muss man derzeit sowieso die Personendaten-Vorlage aus dem Artikelquelltext extrahieren. Da macht es kaum Arbeit, auch nach "Kategorie:Mann" oder "Kategorie:Frau" zu suchen. Zudem bieten die Kategorien den Vorteil, dass bei den Dump-Downloads auch Kategorientabellen dabei sind und man somit sofort und einfach Personen inklusive Geschlecht findet. Wenn es _irgendwann_ eine schon lange geplante Metadaten-Ablage gibt, dann werden die Personendaten dahinwandern und sicher kann man dann auch über Geschlecht und Nationalität nachdenken. Insofern verstehe ich deine Aussage "Meta-Daten haben gegenüber Kats den Vorteil, das mit Ihnen Schnittmengen gebildet werden können" nicht. Wie soll das gehen? Nur nach vorheriger manueller Auswertung (siehe z.B. [11]). Oder übersehe ich was? --APPER\^☺☹ 16:42, 28. Okt. 2008 (CET)

Dieses Tool ist genau das, was ich vermisst habe. Besten Dank für den Tipp. Hier lassen sich ja die von mir gesuchten Schnittmengen bilden. Funktioniert das auf der Basis von Kategorien? Pfir 20:05, 28. Okt. 2008 (CET)

Geschlecht und Nationalität werden dort per Kategorien ermittelt, der Rest aus den Personendaten. --APPER\^☺☹ 01:00, 29. Okt. 2008 (CET)

Januar/Jänner

Sollte nicht auch die Zulässigkeit von Jänner erwähnt werden? Siehe:Wikipedia:Meinungsbilder/Monatsnamen --Zoris Trömm 19:08, 13. Nov. 2008 (CET)

"Jänner" ist in den Personendaten eben nicht zulässig. Die Personendaten dienen _nicht_ der Anzeige sondern ausschließlich der Auswertung durch Programme. Da auch nicht verlinkt werden soll in diesem Feld, sind aus Gründen der einfachen Auswertbarkeit hier nur Angaben wie "10. Januar" erwünscht. Ich denke, dass dies nicht weiter stört, da die Daten – wie gesagt – sowieso kein normaler Leser sieht. --APPER\^☺☹ 21:21, 13. Nov. 2008 (CET)

Das ganze wird hier übrigens auch als zweites Beispiel gebracht. --APPER\^☺☹ 21:22, 13. Nov. 2008 (CET)

Unsicherer Ort

Da ich es selbst schon gemacht habe, gesehen habe, dass es andere machen und sich das PD-Fehler-Skript nicht darüber beschwert: Ist bei Geburts- und Sterbeort unsicher: [[Ort]] zulässig? Falls ja, sollte man das auch hier erwähnen, häufig werden ja solche Daten mit [[Ort]] (?) gekennzeichnet. Für das "unsicher:" spricht, dass es dann einheitlich zu Geburts- und Sterbedatum ist. --Schnark 11:12, 14. Nov. 2008 (CET)

Tja, da gibt es verschiedene Ansätze ("unsicher:", "vermutlich", "?"). Soweit ich weiß, wurde das schon diskutiert, aber warum es zu keinem Ergebnis kam, weiß ich nicht. Bei den Lebensdaten war das ganze nicht erwünscht (wobei ich da anderer Meinung bin), es solle halt das genaueste bekannte angegeben werden... --APPER\^☺☹ 16:49, 14. Nov. 2008 (CET)

Leute ohne Nachnamen (Neuzeit) (gehört das hierher?)

Einige Menschen, z. B. die meisten Isländer, einige Färinger und dieser Herr, haben keine Nachnamen. Wenn es ein eingliedriger Name ist (wie z. B. bei N!xau) entsteht wohl kein großes Problem, aber z. wild herausgegriffenen B. Hjálmar Jónsson wird in Kategorie:Geboren 1980 unter J angesetzt, was falsch ist, und auch in seinem Artikel kurz als "Jónsson" betitelt, was ebenfalls falsch ist. Ich habe keine Konvention zu Isländern oder dem Problem gefunden, nur zu mittelalterlichen Namen steht hier was. Was kann man tun, um das Problem generell in den Griff zu kriegen? (So weit ich das verstanden haben, müßte die Personendatenangabe NAME in diesem Fall NAME=Hjálmar Jónsson lauten, nicht NAME=Jónsson, Hjálmar.) Ein anderer Name 14:14, 20. Nov. 2008 (CET)

Nachtrag: → WP:FZW. Ein anderer Name 20:27, 21. Nov. 2008 (CET)

Ungenaues Geburts- und Sterbedatum, welche Kategorie?

Erstmal etwas Statistik:

234122 Gesamtzahl Artikel mit PD
224185 in PD mit Geburtsdatum
121250 in PD mit Sterbedatum
213927 mit Geburtskategorie (Jahr)
  8084 mit Geburtskategorie (Jahrhundert)
115031 mit Sterbekategorie (Jahr)
  3370 mit Sterbekategorie (Jahrhundert)
  5896 in PD weder Geburtsdatum noch Sterbedatum
  5611 in PD weder Geburtsdatum noch Sterbedatum + keine Geburtskategorie + keine Sterbekategorie
   957 nix, aber Kategorie mit Jahrhundert (Bischof 3. Jahrhundert)
  5684 Geburtsdatum "um 1234"
  2765 Geburtsdatum "um 1234" + Geburtskategorie (Jahrhundert)
  1506 Geburtsdatum "um 1234" + Geburtskategorie (Jahr)
  1418 Geburtsdatum "um 1234" keine Geburtskategorie (weder Jahr noch Jahrhundert)

1. )Gerade die letzten 4 Einträge möchte ich erstmal diskutieren. Wenn im Geburtstag "um 1975" steht, welche Kategorie soll da rein "Geboren 1975" oder "Geboren 20. Jahrhundert"?
2. )Sollen wir versuchen die letzten Artikel ("5611 in PD weder Geburtsdatum noch Sterbedatum + keine Geburtskategorie + keine Sterbekategorie") ohne Zeitlichen Bezug per Zwang zu Geburts- und Sterbekategorie zu verpflichten? Ich denke bei den meisten lässt sich da was machen. Nur ein kleiner Teil ist vielleicht nicht zeitlich eingrenzbar auf ein Jahrhundert.
3. )Soll durchgesetzt werden, das mindestens eine Angabe bei den Artikel ("5896 in PD weder Geburtsdatum noch Sterbedatum) wo überhaupt nichts enthalten ist, rein kommt, damit man die Personen zeitlich zuordnen kann?

Schreibt mal eure Meinungen. -- sk 20:57, 24. Nov. 2008 (CET)

Wir können uns schlecht ein Jahr "aussuchen", wenn es genausogut falsch sein könnte, deshalb bei 1: 20. Jahrhundert. Bei 2 sehe ich nicht die unbedingte Notwendigkeit (für eine gezielte Aktion), aber auch nichts, das dagegen spricht. Vielleicht genügt eine Empfehlung? Bei 3 müsste das dann natürlich immer noch eine korrekte Angabe sein, also ganz grob "x. Jahrhundert oder (x+1). Jahrhundert" oder so? -- Harro von Wuff 21:14, 24. Nov. 2008 (CET)

Platzierung (erl.)

Mir erschließt sich der Sinn des Abfolgegeschubses von vor Kats und Interwikis hin zur Einordnung dazwischen nicht. Was ist der Sinn? Welche Verbesserung bringt das mit? Ich habe eher den Eindruck, dass da einige eher den Edit um des Edits Willen ausführen. Julius1990 Disk. 12:04, 29. Nov. 2008 (CET)

Eine einheitliche Position der Daten ist immer zu bevorzugen, wenn auch gleich nicht ein Vorteil daraus entsteht. Die Position verdeutlicht aber, dass es sich um Metadaten handelt, und die Position lässt auch erklären, warum man diese nicht standardmäßig zu sehen bekommt. Es gab sehr früher mal eine Diskussion dazu, ich finde sie nur nicht wieder. Desweiteren findet man bei solchen Artikeln auch noch andere formale Mängel, die gleich mit behoben werden. Zwar ist dies nicht bei jedem Artikel der Fall, aber sehr überwiegend. Der Umherirrende 13:17, 29. Nov. 2008 (CET)

Personendaten, Interwikis und Kats sind alles Metainformationen, was bringt dann die Umgruppierung dieser drei untereinander? Ich setzte bei meinen neuen Sportlern immer erst PD, dann Kats, dann Interwikis. Warum muss da ein zusätzlicher Edit erfolgen und zwar auch dort, wo noch nicht einmal eine Kat ergänzt wird, so dass es nicht nur darum gehen würde? Ich erkenne da den formalen mangel nicht. Tut mir Leid. Julius1990 Disk. 13:25, 29. Nov. 2008 (CET)

Kats und Interwikilinks sind keine Metainformationen, da sie für den Normalleser sichtbar sind. Die PD müßten eigentlich ganz ans Ende, hier hat man aber aus Kompatibiltätsgründen gesagt, dass man diese vor die Interwikilinks setzt (die Interwikilinks stehen in allen Projekten am Ende). Die Sinnfrage dieser Edits ist damit beantwortet, dass es inzwischen zwei Wikiprojekte gibt, die ausschließlich Quelltextkosmetik betreiben. Diejenigen die das für nicht sinnvoll halten sind in der Minderheit. -- chemiewikibm cwbm 13:37, 29. Nov. 2008 (CET)

Und die Minderheit wurde aus einem MB, einer Umfrage oder ähnlichem abgelesen oder werden andere Meinung, wenn sie Projekten entgegenstehen, jetzt generell als Minderheiten abqualifiziert? Typisch. Julius1990 Disk. 13:42, 29. Nov. 2008 (CET)

Ich würde auf jedenfall davon abraten, ein MB ala "Bearbeiten von Artikeln nur zur Quelltextkosmetik ist unerwünscht" durchzuführen. Der Ausgang ist imho vorhersehbar. -- chemiewikibm cwbm 13:47, 29. Nov. 2008 (CET)

Vor gut drei Jahren wurde im Vorfeld der Wikipedia:Wikipedia Tagging Party, bei der über tausende Personendaten eingefügt wurden, darüber diskutiert, wo die genau hin sollen. Man kam zum Schluss, dass dies zwischen Kat und Interwikis zu erfolgen hat. Und seit dem ist das so. Siehe auch :Wikipedia:PD#Kopiervorlage (Satz unten) -- sk 16:24, 29. Nov. 2008 (CET)

Sorry, aber in einer Entscheidung von 30 Leuten (von denen ich die meisten sehr schätze) sehe ich keine allgemeine Regelung und auch keinen tatsächlichen Nutzen. In welcher Reihenfolge die letzten drei Punkte im Quelltext stehen ist nun einmal vollkommen egal. Die hier vorgebrachten Punkte bestärken mich allein in dem Glauben, dass das alles großer Unsinn ist. Julius1990 Disk. 16:44, 29. Nov. 2008 (CET)

Julius, was ich nicht verstehe, ist warum du dich nicht einfach an diese Reihenfolge hälst. Noch sinnloser als zum Herstellen dieser Reihenfolge Artikel zu bearbeiten ist es nämlich die Reihenfolge absichtlich nicht einzuhalten, damit jemand anderes extra dafür den Artikel bearbeitet (Es gibt ein Projekt, was diesen "Fehler" systematisch korrigiert). -- chemiewikibm cwbm 16:55, 29. Nov. 2008 (CET)

Das ist ein Fehler des Projektes und nicht meiner. Ich arbeite wie ich möchte und halte die Regeln ein die sinnvoll sind. Mir vorschreiben zu wollen, wie ich den Artikel gliedere, die Abfolge im Quelltext etc. gehört aber nicht mehr dazu. Und dieses Projekt sollte sich auch Mal überlegen welche Änderungen sinnvoll sind (Unstimmigkeiten in den Personendaten z.B.) und wo die Zeit besser in Qualitätssteigerung investiert werden sollte (Personendatengeschubse usw.). Julius1990 Disk. 17:08, 29. Nov. 2008 (CET)

Wo sie stehen, ist tatsächlich egal; es ist aber sinnvoll, das einheitlich zu machen. Du brauchst dich an die Regelung nicht zu halten, aber wenn du es nicht tust, solltest du dich auch nicht aufregen, wenn es jemand anders ändert. --08-15 17:22, 29. Nov. 2008 (CET)

(BK)Nur dein Kampf ist noch sinnloser als der von Don Quichote. Auf der Fehlerliste sind noch 200 Artikel wo die Reihenfolge falsch ist, bei über 200.000 Artikeln mit PDs. Es ist nur eine Frage der Zeit, bis die Liste abgearbeitet ist. Die wirst wohl kaum die Änderungen auf deiner Beo revertieren, und selbst wenn betrifft das nur eine handvoll Artikel und hat keinerlei Nutzen. Und wenn die Menschen sich mit sinnvollen Dingen beschäftigen würden, dann würden wir in einer besseren Welt leben. -- chemiewikibm cwbm 17:24, 29. Nov. 2008 (CET)

Jeder sieht etwas anderes als sinnvoll an, die Rubrik hatte anfang der Woche ca. 500 gelistete Artikel. Es wird ja nicht nur die Position korrigiert, auch andere formale Fehler, wie ich schon schrieb. Zusätzlich finden sich komische Fehler: Beispiel. Qualität liegt immer im Auge des Betrachters. Der Umherirrende 18:56, 29. Nov. 2008 (CET)

Löschantrag

Hallo, ich wollte nur hier mal drauf hinweisen, dass die Vorlage:Personendaten zur Löschung vorgeschlagen wurde. Betrifft dann ja einige weitere Seiten, zum Beispiel diese hier. Löschdiskussion. --APPER\^☺☹ 16:26, 31. Mai 2008 (CEST)

West- und Ost-Berlin

Die Angaben zu West-Berlin und Ost-Berlin werden zzt. systematisch aus den Geburts- [12] und Todesangaben [13] gestrichen. Die Diskussion dazu, siehe hier. --Kolja21 16:02, 16. Jul. 2008 (CEST)