Wikidata talk:WikiProject Infoboxes

From Wikidata
Jump to: navigation, search

Zeitplan und Infoboxen[edit]

Die Diskussion zur task force startete am 5. November hier: Wikidata:Forum/Archiv/2012/11#Zeitplan. --Kolja21 (talk) 02:14, 22 November 2012 (UTC)

Properties, question 1[edit]

Is "Fields for different typs of items" a list of properties? If that is true, could you write an introduction for this chapter?
Am I right, that a Infobox template in Wikipedia consists of several rows, which could be grouped together to one property or several properties. For example, Template:Infobox company has a parameter called founder. If we would create a property company, than, is it possible to use for the founder the property person, included in the property company ? --Goldzahn (talk) 01:06, 22 November 2012 (UTC)

Gute Fragen. Ich kann mir nicht recht vorstellen, wie die Angaben für die einzelnen Datenfelder in Eigenschafts-Werten zusammengefasst werden können. Der technischen Erläuterungen finden sich auf der Homepage von Wikimedia (und sollten imho möglichst bald nach Wikidata verschoben werden): Wikidata/Technical proposal/de, Abschnitt "Phase 2: Infoboxen". Was fehlt sind Grafiken, dann könnte man als Nicht-Informatiker leichter verstehen, welches Ziel die Entwickler vor Augen haben. --Kolja21 (talk) 02:32, 22 November 2012 (UTC)
I think meta:Wikidata/Notes/Data model primer is a better page. And we could ask Wikidata:Contact the development team. Zum Vorgehen. Wir könnten uns die Infobox-Vorlagen aller Sprachversionen ansehen und die Kerneinträge heraussuchen. Auf meta heißt es: "There can be several statements about the same property: people can have several children, books might have several authors. Also, there might be diverging points of view on the population of a city -- official numbers and UN estimates, for example. Or there might be values with different qualifiers, like points in time or measurement methods." I think, we should try not to do it in this way. Or we will have many quite similar statements. --Goldzahn (talk) 08:21, 23 November 2012 (UTC)
Danke für den Link! Die Seite kannte ich noch nicht. Jetzt rückt also die Bezeichnung "statement" in den Vordergrund. Man sollte drigend die Konzeption in einem größeren Kreis diskutieren und dafür in einem ersten Schritt die relevanten Informationen auf Wikidata zusammenstellen. Die "Kerneinträge" können wir in unserer Liste ja schon mal sammeln (Personen: Geburtsdatum, Geburtsort etc.), aber solange nicht mal die Begrifflichkeiten klar sind (Wikidata:Glossar ist ein erster Schritt), besteht die Gefahr, dass wir uns in Detailarbeit verlieren und in den wesentlichen Punkten aneinander vorbeireden. --Kolja21 (talk) 11:57, 23 November 2012 (UTC)
Another thing we should ask the developpers: is it possible to change (expand, rename, etc. ) a property after creation. About the "statements": I don´t understand "statements", because they don´t have a namespace but a page. In which namespace will they be? And how will they work together with properties (who will have a page too)? Ansonsten stimme ich dir zu. Es wäre auch toll, wenn die Testinstallation (wikidata-test.wikimedia.de) zum testen für Phase 2 recht bald freigeschaltet werden könnte. --Goldzahn (talk) 08:45, 24 November 2012 (UTC)
I am not a developer, but I can answer your question. Statements are the content of the properties, just as interwiki links are the content of items. Statements are facts with sources, for example the population of Berlin along with an source... The properties are basically infoboxes filled with facts from the statements.--Snaevar (talk) 14:55, 24 November 2012 (UTC)
Thank, you.--Goldzahn (talk) 08:40, 26 November 2012 (UTC)

There are infoboxes and other infoboxes[edit]

Though it seems much too early to consider all in detail one fact must not be missed: different Wikipediae are using different infoboxes. Speaking of "Places / Geografika", for example, we have in most Wikipedia language versions specialized infoboxes for each kind of geographic feature and vor settlements specialized infoboxes for each country, sometimes they also differ for each type of settlement (Infobox Ortsteil vs. Infobox Gemeinde or Infobox Ort with parameter type in DE:WP, for instance) whereas the English Wikipedia has a widespread using of en:Infobox settlement and en:Template:Geobox which includes appearantly a zillion of parameters mostly empty.

On the other hand we have infoboxes which are fully (e.g. de:Vorlage:Infobox Ort im Vereinigten Königreich vs. en:Template:Infobox UK place, differing only in nameing of the template, though some parameters from EN aren't used in DE) or partly (de:Vorlage:Infobox Gemeinde in Italien vs. it:Template:Divisione amministrativa with some parameters to be added or to removed respectively) compatible.

Then there are differences in content, e.g. en:Template:Infobox river is much poorer in content than de:Vorlage:Infobox Fluss.

I feel it will be necessary after the devs are ready with the second phase – so we know better how it will work – and before we start to add content to discuss how this content will be added and who (as in which "source-wikipedia") will do it, for avoiding that some are starting with the "poorest" set of data and later we'll have to add the data which was missed. (That will happen anyway but let's try to minimize.) --Matthiasb (talk) 13:38, 25 November 2012 (UTC)

Hallo Matthias, ich habe mich heute "vor Ort" auf dem Offenen Sonntag von Wikimedia kundig gemacht. Die Konzeption von Wikidata ist (vorerst) weitgehend abgeschlossen; es geht im Moment (bis März 2012) nur noch um technische Details. "Wir", die community, können ab Phase 2 festlegen, welche Eigenschaften (proterties) wie Kontinent, Staat oder Einwohnerzahl in Wikidata aufgenommen werden.
Gegenstand (item): Berlin (Q64)
Eigenschaft (property) 1: Kontinent
Wert: Europa / Europe / etc. (Q46)
Quelle: ...
Eigenschaft (property) 2: Staat
Eigenschaft (property) 3: Einwohnerzahl
Eigenschaft (property) 4: (Ober-)Bürgermeister
Eigenschaft (property) 5: ...
Die Einbindung in die Infoboxen bleibt uns überlassen. --Kolja21 (talk) 17:41, 25 November 2012 (UTC)

Qualifier[edit]

Ich habe mir nochmal den Data_model_primer angesehen. Das Beispiel "Two statements with the same property, each with one qualifer:" könnte vielleicht für eine Person genommen werden, bei der ein Statement ein Authority control/Normdaten-Eintrag ist. Die unterschiedlichen Normdaten werden durch einen anderen Qualifier identifiziert (laut Glosary heißt Qualifier Abfragekriterium). Also, einen Qualifier für GND, einen anderen für LCCN, zwei weitere für NDL und VIAF, etc. Für Personen könnte dieses Statement Teil eines Personen-Eintrags sein (eventuell wäre das ein item), also neben z.B. birt_date und birt_place. Habe leiner keine Ahnung, ob das so richtig ist. --Goldzahn (talk) 15:46, 27 November 2012 (UTC)

Wikidata-Fachausdrücke
Wäre eventuell möglich. Das sähe dann so aus:
Eigenschaft (property): Normdaten
Abfragekriterium (qualifier) 1: GND
Abfragekriterium (qualifier) 2: VIAF etc.
Vielleicht sollte man sich das Feld "Abfragekriterum" aber besser für Dubletten, Nebeneinträge und ähnliche Sonderfälle aufsparen? Wichtig ist für uns auf jeden Fall erst mal, dass wir in der Liste sammeln, welche Eigenschaften wir überhaupt aufnehmen wollen. Gruß --Kolja21 (talk) 18:12, 27 November 2012 (UTC)
Ich bin dafür, die konkrete Normdatendatei mit der Eigenschaft (Property) auszudrücken, also eine Eigeschaft für GND und eine andere Eigenschaft für VIAF usw. Die Verweise auf zwei unterschiedliche Normdatendateien sind zwei unterschiedliche Informationen und nicht etwa die gleiche Information aus zwei unterschiedlichen Quellen. --Spischot (talk) 14:25, 29 December 2012 (UTC)
Sehe ich auch so. --Kolja21 (talk) 04:07, 30 December 2012 (UTC)

Kategorisierung durch Snaks[edit]

Die Sinnhaftigkeit / Notwendigkeit von bestimmten Eigenschaften (Properties) hängt offenbar von der Art des Gegenstands (Item) ab. Umseitig werde solche Arten grob an zwei Stellen verwendet:

  1. main entities: p =person (individual), n=name (disambiguation), k=corporate body, ...
  2. Geografika (Places) type: city, river, country, etc...

Ich glaube entdeckt zu haben, wie Wikidata solche Arten abbilden will: Gegenstände (Items) werden durch InstanceOfSnaks Klassen zugeordnet, und die Klassen werden durch SubclassOfSnaks in einer Hierarchie gegliedert. Dadurch ergibt sich zum Beispiel:

Amazon River is instance of Main stem is subclass of River is subclass of Body of water is subclass of Place
George Washington is instance of President of the United States is subclass of Head of state is subclass of Bureaucrat is subclass of Person

Ich vermute, dass dadurch Kategorien für Gegenstäde (Items) innerhalb von Wikidata überflüssig werden. Wir sollten uns aber keine Hoffnung machen, dass uns die üblichen Probleme mit der Einteilung in Kategorien erspart blieben; sie werden lediglich mit anderen Mitteln abgebildet. Wenn ich richtig liege, wäre es vermutlich klug, jetzt nicht nur die Eigenschaften (Properties) zu definieren, sondern parallel auch die bestimmenen Klassen-Gegenstände (Items) zu identifizieren und deren Beziehung zueinander zu entwickeln. --Spischot (talk) 11:44, 8 December 2012 (UTC)

+1. Danke für die Info. Dass "place" nicht verlinkt ist, ist vermutlich kein Zufall. en:Location (geography) entspricht in der dt. Wikipedia der Artikel "Standort", und der Begriffe, die als Haupteinträge in Frage kommen, sind viele. Daher mein Vorschlag, sich vorab auf sechs Grundtypen (Entitäten) zu einigen. Anderenfalls wird Wikidata zum Verschiebebahnhof, mit Zielbahnhöfen, die oft nur in einzelnen Sprachversionen plausibel erscheinen. --Kolja21 (talk) 22:00, 8 December 2012 (UTC)
Die vorgeschlagen Grundtypen erscheinen mir sehr sinnvoll - mein Versuch, die entsprechenden Wikidata-Items zu finden, scheitere aber leider daran, dass ich für v (Veranstaltung), w (Werk), s (Sachbegriff) und g (Geografikum) weder passende deutsche noch englische Artikel finden konnte. Die englische Seite en:Place (geography) leitet leider auf location (geography) weiter - die Location ist der Standort, angegeben durch die Koordinaten. Das Geographikum ist aber mehr als nur seine Koordinaten. Dieses Problem, dass es in der hier benötigten Abstraktion und Präzision nicht die genau passenden Wikipedia-Artikel gibt, wird uns beim Aufbau der Hierarchie vermutlich noch mehrmals begegnen. Mir gefällt an den InstanceOf- und SubclassOfSnak, dass es eine klar defnierte Struktur gibt die durch die Verwendung der Wikidata-Item herrlich flexibel (und selbstreferenziell) ist. Es wird aber noch etwas Mühe erfordern, die sechs Grundtypen mit diesem Konzept in Einklang zu bringen. ---Spischot (talk) 22:42, 8 December 2012 (UTC)
Nachtrag: Ich habe noch Geographical feature gefunden - das wäre ein guter Kandidat für das Geographikum. --Spischot (talk) 22:55, 8 December 2012 (UTC)
Im Moment, in der Startphase von Wikidata, ist jedem Gegenstand (item) mindestens ein Wikipediaeintrag zugeordnet. In der Zukunft werden weitere items aus anderen Quellen dazukommen. Ich fände es sinnvoll, die Grundtypen unabhänig von einem Wikipediaeintrag als item einzutragen und mit der Beschreibung (description) "general properties / allgemeine Eigenschaften" zu versehen. - Phase 1 und 2 von Wikidata widersprechen sich im Grunde. Man tut im Moment so, als würden die Interwikilinks stets die gleiche Sache verlinken. Dass dem nicht so ist, sieht man beispielsweise bei einem Blick auf die Taxonomie in der Biologie. Die eine Wikipedia hat einen Eintrag zur Gattung, die andere zur Art, die dritte zur Unterart eines Lebewesens und alle sind, falls sie jeweils nur einmal vorkommen, via Interwikilink verbunden. Ich denke, Wikidata wird dazu führen, dass die Interwikilinks präziser (und seltener) gesetzt werden. Der entsprechende "Partnerartikel" wird in Zukunft dann in vielen Fällen nicht über einen Interwikilink, sondern nur über den Umweg über Wikidata zu finden sein. --Kolja21 (talk) 23:28, 8 December 2012 (UTC)
Ich finde den Vorschlag, zur Not ein eigenes Item zu erzeugen, recht charmant – Wikidata emanzipiert sich damit sozusagen von Wikipedia :-) Allerdings bin ich spektisch, dies generell zu tun, also auch dann, wenn bereits ein Item (und die zugehörigen Wikipedia-Artikel) besteht. Zum einen kann ich keinen fundamentalen Unterschied zwischen den Grundtypen und weiteren, spezielleren Typen zu erkennen. Je weiter man in der Hierarchie nach unten kommt, desto konkreter werden die Begriffe und desto kleiner das Problem. Zum anderen geht dein Vorschlag nach meinem Empfinden an der Grundidee vorbei. Die Grundidee (soweit ich sie verstehe) ist, das
  1. zu jedem definierbaren Gegenstand ein Wikidata-Item existieren kann.
  2. die Klassifikation nicht als separates, losgelöstes abstraktes System definiert wird, sondern die Items von Wikidata verwendet werden. Dadurch bekommt man unter anderem auch gleich die Mehrsprachigkeit und die detaillierte Beschreibung durch zugeordnete Artikel (sofern ein solcher vorhanden ist).
Eine Unterschiedung zwischen Person und einem neu zu erstellendem Item "Person" (general properties) also mit der gleichen Bedeutung aber nur zur Verwendung als Grundtyp halte ich aber nicht für sinnvoll. Wenn man den Gedanken auf speziellere Typen überträgt, was man meiner Meinung nach nur konsequent wäre, erhielte man z.B. auch zu Polymer ein neues Item "Polymer" (general Properties). Das ist doch verrückt. In diesem Punkt sind wir vermutlich nicht gleicher Meinung.
Mein Vorschlag: Wir sammeln umseitig mal die vorhandenen Items und parallel dazu auch die Kritik an deren Auswahl und mögliche Alternativen. Die Kritik und Alternativen könnte man in einem getrennten Absatz in der Nähe der Items sammeln. So erheben wir eine Basis und sehen, wo und welche Probleme bestehen; trotzdem vermeiden wir eine vorschnelle Festlegung können problematische Fälle später gezielt behandeln, z.B: durch Anlegen eines neuen Items.
Ich will dieser Tage mal etwas mehr Material sammeln und umseitig einarbeiten - da würde ich auch einen ersten Vorschlag für mögliche passende Items einarbeiten. --Spischot (talk) 16:55, 28 December 2012 (UTC)
Das item Q215627 definiert Person "als Individuum". Das ist nicht identisch mit Person "als Entität", der auch Personengruppen, Familien, Geister, Götter und Gespenster angehören können. Aber ich denke, dass ist nicht das Hauptproblem. Die grundlegende Frage ist, ob Wikidata eine Art Weltenzyklopädie werden soll, die auch Menschen lesen können, oder nur eine Datensammlung, die die automatische Auswertung von Wikipediaartikeln verbessert (Stichwort: Semantisches Web). Bin auf jeden Fall auf deine Ergänzungen gespannt. Bei "Veranstaltung" können wir event. auf item Q1656682 zurückgreifen, allerdings fehlt dort nicht nur die Beschreibung, sondern auch eine engl. Übersetzung. --Kolja21 (talk) 17:48, 28 December 2012 (UTC)
Eine Personengruppen ist keine Person. Eine Familie ist keine Person. Eine fiktive Person ist zumindest im engeren Sinn auch keine Person und ob der weitere Sinn hier eher hilfreich oder schädlich ist, weiß ich nicht. Ich grübele nun schon seit Tagen, woher diese abenteuerlichen Behauptungen wohl stammen mögen. Die Begründung, dass dies wohl folgen müsse, weil ein Begriff „als Entität“ verwendet wird, war für mich nicht schlüssig. (ein Fahrrad wird ja auch nicht zum Auto, in dem man „Auto als Entität“ sagt).
Jetzt hat du Entitätencodierung: Vergaberichtlinien - Kurzliste. angegeben und nun wird mir einiges klarer. Dafür erst mal herzlichen Dank. Offenbar hälst du dich ganz eng an diese Codes und der GND-Code p umfasst halt nun mal neben den natürlichen Personen mit den Codes pip und piz auch noch allerlei anderes, was im üblichen Sprachgebrauch keine Person ist. Auch in anderen Breichen dieser Entitätencodierung finde ich Anlass zur Verwunderung (das soll aber erst mal nicht das Thema sein)
Für mich ist klar: Wir haben in den Wikipedien eine große Anzahl von biographischen Artikeln und diese haben einige systematische Eigenschaften. Eine Übertragung solcher Eigenschaften, wie zum Beispiel in der Vorlage Personendaten nach Wikidata ergibt für mich Sinn. Damit das gelingt und nicht im Chaos endet, müssen die Eigenschaften (Properties) klar definiert sein:
  • Welche Eigenschaften halten wir für sinnvoll?
  • Für welche Gruppe von Gegenständen (Items) ist eine bestimmte Eigenschaft gültig?
  • Welche lokalisierten Namen haben die Eigenschaften?
  • Welche Datentypen haben die Eigenschaften?
  • Welche Werte sollen für die Eigenschaften zulässig sein?
Ich halte die Diskussion und Klärung dieser Fragen für den wichtigsten, wenn nicht sogar für den einzigen Zweck dieser Task-Force.
Der Vorschlag der Grundtypen schien mir dazu auf der ersten Blick gut geeignet. Ein Gegenstand (Item) bezeichnet eine Person (also gibt es die Eigenschaften Datum und Ort der Geburt) oder einen Staat (also gibt es kein Datum oder Ort der Geburt, dafür aber eine Flagge und einen ISO-3166-1-Code) oder halt was anderes. Über „was anderes“ habe ich mir noch nicht den Kopf zerbrochen. Egal wo man anfängt und wie man gliedert: Es wird immer „was anderes“ geben, das nicht in die Systematik passt, also andere Eigenschaften hat. Ich will erst mal mit den wichtigen, klar definierten Dingen anfangen; das führt zu konkreten Ergebnissen, gibt uns ein Gerüst und erlaubt uns, die Randbereiche später ausgehend von einer soliden Basis anzugehen.
Für dieses Unterfangen brauchen wir klar umrissene Entitäten, wie eine Person als Individuum. Eine Mischmasch-Gruppe zu der sich keine einzige gemeinsame Eigenschaft (Property) definieren lässt, halt ich für verzichtbar. Klar kann man sagen das der GND-Typ p natürliche Personen und fiktive Personen und Gruppen von Personen und Pseudonyme zusammenfasst – aber welchen Vorteil können wir für die Zwecke von Wikidata daraus ziehen? „Weil die von der GND das so machen“ ist für mich keine stichhaltige Begründung. --Spischot (talk) 11:25, 31 December 2012 (UTC)
Hi Spischot, die Entitäten, die in der GND verwendet werden, sind das Ergebnis jahrelanger bibliografischer Arbeit. Wir haben in der dt.-sprachigen Wikipedia für die de:Vorlage:Normdaten die sechs Haupt-Entitäten übernommen und damit gute Erfahrungen gemacht. Aus diesen beiden Gründen habe ich sie für die Gliederung der Arbeit in Wikidata herangezogen. Deine Einwände sind dessen ungeachtet natürlich völlig berechtigt. Die Detailarbeit - z.B. gezielt für "Person als Individuum" - wird durch die Aufteilung der Themenfelder imho aber nicht behindert. --Kolja21 (talk) 18:02, 31 December 2012 (UTC)
Ja, stimmt schon, es ist keine Behinderung sondern hilft tatsächlich, irgendwo mal einen Anfang und eine Grundstruktur zu finden. Wenn wir Götter mal wichtig finden, haben die auch schon einen Platz. :-) Lass uns aber bitte darauf achten, dass wir die handfesten Entitäten nicht dadurch infrage stellen, dass die GND einen auf den ersten Blick ähnlich scheinenden Begriff anders besetzt. --Spischot (talk) 18:23, 31 December 2012 (UTC)

Collecting high class data sources[edit]

I just added a proposal to handle data sources. The list of properties for a specific kind of items allows for a precise reference to one or more high class data sources for this property. From my point of view this would enable this task force to collect a number of acceptable data sources along with the identification of the property we would like to be fed from this source. I'd highly appreciate your comments on this method of presentation and given an agreement on such a method I'm looking forward to see your input for more data sources. --Spischot (talk) 20:26, 1 January 2013 (UTC)

Neben der Homepage, die es ja nur bei noch aktiven Organisationen, Veranstaltungen etc. gibt, spielen sicherlich auch konventielle Literaturangaben eine große Rolle. Jetzt ist die Frage, ob man in das Feld "Literaturangabe/Quelle" alles eintragen kann oder nur Bücher und Aufsätze, die in einer Liste mit Referenzwerken erfasst sind. Das macht mehr Arbeit (erst das Werk in Wikidata aufnehmen, dann als Quelle verlinken), führt aber zu besseren Ergebnissen. --Kolja21 (talk) 22:03, 1 January 2013 (UTC)
Wir können in dieses Feld alles eintragen, was uns hilfreich erscheint. Mir geht es dabei weniger um Quellen, einer Information für ein einzelnes Item sondern um die großen Quellen (wie z.B. das CIA World Factbook oder die Quellen von Einwohnermeldedaten, gerne auch als Sammelbegriff "Statistische Landesämter der deutschen Bundesländer" usw.), die systematisch von Bots angezapft werden, um die Properties zu füllen. Wir können damit festhalten, welche Quellen wir grundsätzlich akzeptieren wollen und welche nicht. Eine Liste mit Referenzwerken in Wikidata einzutragen? Scheint mir für den Zweck der Task-Force zu umständlich. Wie genau die Quellenangabe in den Statements auszusehen hat, ist dann eine andere Frage. --Spischot (talk) 22:57, 1 January 2013 (UTC)
I analyzed de:Wikipedia:WikiProjekt Metadaten and related categories and bots in dewiki for metadata and their sources:
Item class Infoboxes Wiki-Projects Templates Data sources
Musician AllMusic, MusicBrainz
Film director IMDb
Actor Infobox Cinéma (personnalité) IMDb
Sportsperson
Chess player Infobox Schachspieler de:Benutzer:DrTrigonBot/Subster de:Vorlage:Elo-Punkte ELO points: FIDE, [1]
Table tennis player Infobox table tennis player,
Infobox Tischtennisspieler
de:Benutzer:DrTrigonBot/Subster de:Vorlage:ITTF-Weltranglistendaten DrTrigonBot subster mail queue
Film Infobox film,

Infobox Film,
Infobox Cinéma (film)

IMDb
Currency exchange rates
Currency Infobox Währungseinheit de:Benutzer:DrTrigonBot/Subster de:Vorlage:Wechselkursdaten/EZB ECB
Kreditinstitute
Kreditinstitute DE Infobox Kreditinstitut de:Benutzer:DrTrigonBot/Subster de:Vorlage:Infobox_Kreditinstitut/DatenDE,

de:Vorlage:Infobox_Kreditinstitut/DatenDE/Quelle,
de:Vorlage:Deutsche Sparkasse

Deutsche Bundesbank, [2], DGSV [3]
Kreditinstitute AT Infobox Kreditinstitut de:Benutzer:DrTrigonBot/Subster de:Vorlage:Infobox_Kreditinstitut/DatenAT ÖNB, [4]
Kreditinstitute CH Infobox Kreditinstitut de:Benutzer:DrTrigonBot/Subster de:Vorlage:Infobox_Kreditinstitut/DatenCH SIX Interbank Clearing, [5]
Commodity
Goldpreis Infobox Währungseinheit de:Vorlage:Goldpreis LBMA, 2012 London Gold Fixings
Silberpreis Infobox Währungseinheit de:Vorlage:Goldpreis LBMA, 2012 London Silver Fixings
Platinpreis Infobox Währungseinheit de:Vorlage:Platinpreis LPPM, 2012 London Platinum Fixings
Palladiumpreis Infobox Währungseinheit de:Vorlage:Platinpreis LPPM, 2012 London Palladium Fixings
Population of administrative subunits and settlements
AD de:Wikipedia:WikiProjekt Metadaten de:Vorlage:Metadaten Einwohnerzahl AD
AT Infobox Town AT,

Infobox Gemeinde in Österreich,
Infobox Gemeindeteil in Österreich

de:Wikipedia:WikiProjekt Metadaten de:Kategorie:Vorlage:Metadaten Einwohnerzahl AT Statistik Austria
BE de:Wikipedia:WikiProjekt Metadaten de:Vorlage:Metadaten Einwohnerzahl BE
CH Infobox Swiss town,

Infobox Ort in der Schweiz,
Infobox Commune de Suisse

de:Wikipedia:WikiProjekt Metadaten de:Kategorie:Vorlage:Metadaten Einwohnerzahl CH Statistik Schweiz
CZ de:Wikipedia:WikiProjekt Metadaten de:Vorlage:Kategorie:Metadaten Einwohnerzahl CZ
DE Infobox German location,

Infobox Gemeinde in Deutschland,
Infobox Commune d'Allemagne

de:Wikipedia:WikiProjekt Kommunen und Landkreise in Deutschland/Einwohnerzahlen de:Kategorie:Vorlage:Metadaten Einwohnerzahl DE Daten der Statistischen Landesämter
DM de:Wikipedia:WikiProjekt Metadaten de:Vorlage:Metadaten Einwohnerzahl DM
DK de:Wikipedia:WikiProjekt Metadaten de:Kategorie:Vorlage:Metadaten Einwohnerzahl DK
ES Infobox Gemeinde in Spanien,

Infobox Commune d'Espagne

de:Wikipedia:WikiProjekt Metadaten de:Kategorie:Vorlage:Metadaten Einwohnerzahl ES INE
FI de:Wikipedia:WikiProjekt Metadaten de:Vorlage:Metadaten Einwohnerzahl FI
FR Template:Infobox French commune,

Infobox Gemeinde in Frankreich,
Infobox Commune de France

de:Wikipedia:WikiProjekt Metadaten de:Kategorie:Vorlage:Metadaten Einwohnerzahl FR Insee
HU de:Wikipedia:WikiProjekt Metadaten de:Kategorie:Vorlage:Metadaten Einwohnerzahl HU
IT Infobox Italian comune,

Infobox Gemeinde in Italien,
Infobox Commune d'Italie

de:Wikipedia:WikiProjekt Metadaten de:Kategorie:Vorlage:Metadaten Einwohnerzahl IT ISTAT
IS de:Wikipedia:WikiProjekt Metadaten de:Vorlage:Metadaten Einwohnerzahl IS
JP de:Wikipedia:WikiProjekt Metadaten de:Kategorie:Vorlage:Metadaten Einwohnerzahl JP
LI de:Wikipedia:WikiProjekt Metadaten de:Vorlage:Metadaten Einwohnerzahl LI
LU de:Wikipedia:WikiProjekt Metadaten de:Vorlage:Metadaten Einwohnerzahl LU
MT de:Wikipedia:WikiProjekt Metadaten de:Vorlage:Metadaten Einwohnerzahl MT
NL de:Wikipedia:WikiProjekt Metadaten de:Vorlage:Metadaten Einwohnerzahl NL
NO de:Wikipedia:WikiProjekt Metadaten de:Vorlage:Metadaten Einwohnerzahl NO,

de:Vorlage:Metadaten Einwohnerzahl Ort NO

PH de:Wikipedia:WikiProjekt Metadaten de:Vorlage:Metadaten Einwohnerzahl PH
PL de:Wikipedia:WikiProjekt Metadaten de:Kategorie:Vorlage:Metadaten Einwohnerzahl PL
PT de:Wikipedia:WikiProjekt Metadaten de:Kategorie:Vorlage:Metadaten Einwohnerzahl PT
QA de:Wikipedia:WikiProjekt Metadaten de:Vorlage:Metadaten Einwohnerzahl QA
RU de:Wikipedia:WikiProjekt Metadaten de:Kategorie:Vorlage:Metadaten Einwohnerzahl RU
SE de:Wikipedia:WikiProjekt Metadaten de:Kategorie:Vorlage:Metadaten Einwohnerzahl SE
SK de:Wikipedia:WikiProjekt Metadaten de:Kategorie:Vorlage:Metadaten Einwohnerzahl SK
SM de:Wikipedia:WikiProjekt Metadaten de:Vorlage:Metadaten Einwohnerzahl SM
ZA de:Wikipedia:WikiProjekt Metadaten de:Vorlage:Metadaten Einwohnerzahl ZA
Open Data portal Vienna data.wien.gv.at
Feel free to extend the list. --Spischot (talk) 00:08, 5 January 2013 (UTC)
Basically all data having an online source (url, mail, ...) can be updated by DrTrigonBot. --DrTrigon (talk) 11:25, 12 January 2013 (UTC)

Feasibility of DrTrigonBot/Subster to update Wikidata[edit]

The point I am currently struggling with is the fact that DrTrigonBot is freely configurable for any wikipedia user in order to automatically update any wikipage from any source out there (if the license is ok, of course). Because of this it is not clear to me if it even has to create properties or just claims and qualifiers... and all the stuff. So at the moment I am afraid that I am quite confused and just of minimal help here... ;) Greetings --DrTrigon (talk) 21:35, 5 January 2013 (UTC)

Let's take for example the chess player: Let's assume the chess players are already created as items and their FIDE ID is given as property. The property FIDE rating has also been already created with interationalized labels, interationalized descriptions and datatype QuantityValue.
In order to provide up to date FIDE ratings to all Wikipediae through Wikidata we would need some procedure like a tool or a bot to create new statements for property FIDE rating for items of type chess player. The created statments shall have the actual rating as value, the date als qualifier and the FIDE ratings as reference. Is DrTrigonBot able to do this? --Spischot (talk) 21:06, 6 January 2013 (UTC)
I think... we are thinking into the same direction... may be I should mention the mail conversation from Dec '12 and Jan '13 as well as the test example I created test:Q356 (config on test:Talk:Q356) and "linked" (by aliases - VERY SLOW) to test:Q366 and test:Q367. What do you think about all this? Greetings --DrTrigon (talk) 22:58, 11 January 2013 (UTC)
I'm very impressed by your (and your bots) ability to use the Wikidata API to automatically update Wikidata. However, the examples you provided look very weird to me – likely as a result of
  1. Incompletenes of phase two features (in the UI and in the API)
  2. “Sloppy” test data beeing used
  3. Unexpected methods to use Wikidata concepts to express data, likely to facilitate the bot procedure.
I will try to list my feedback even if it's a only result of (1) or (2).
  • Lables of items and properties are partly en, partly de, partly nonsense ("0" and "test") and partly missing. Likely reason is (2) but it makes it hard to follow the idea. I don't want to mess up your example but if you would be ok I'd correct and complete the lables to solve this issues.
  • Property lables are not perfectly meaningful. I see a lot of three letter properties (obvisously currency code) meaning not the currency itself but contain one (or more) exchange rates. (Imho a currency is something different than an exchange rate from one currency to another currency)
  • Many (or even all) property seem to have data type Item which is not the correct data type. Insetad of a reference to an item these properties just contain text. Th UI display the values as links to the item. Confusing. Likely reasons are (1) and (2)
  • Q356:P33 has one statement "JPY" and another statement "111.52". Looks like nonsense in the context of statements and properties. The same applies to Q356:P34 having one statement "NOK" and another statement "7.3645".
  • Q356:P32 has a statement "STAND=2013-01-11". This looks like a qualifier (which is not implemented yet). I recommend to wait for this feature instead of putting the information somewhere else. The idea to put an identifier and a value concatenated with "=" or " = " into a value does not make sense to me.
  • Q356:P32 has a long list of statements, one for each currency. I have several problems with that:
    • An exchange rate is not a property of an item "Wechselkursdaten EZB".
    • An exchange rate from e.g. JPY to EUR is not a valid value for a property "USD"
    • A list of exchange rates codified like "JPY = 118.18" combined as several statements of one property seems to be the trial to dump a list of key-value tuples into one single property. This is not what a property is meant for. I really don't get a meaningful idea behind that.
  • Q366:P32 (namely item LTL with propert USD) contains an comversion rate from EUR to LTL (3.4528). If I asume the property "USD" would be renamed "Exchange rate from EUR" it would make more sense to me. Even more sense for an item LTL would be the exchange rate from that currency (LTL) into another currency (e.g. EUR).
My overall impression is that you misuse the concepts Property, Statement, Claim and Value to store lists and touples, which they are not meant for and imho not feasible. It would be better to store as separate properties, properties like "Exchange rate to CHF" on item "EUR". I would store only a few relevant exchange rates (USD, GBP, JPY, CHF) on the item EUR. The ECB rate from EUR to LTL should be stored on LTL only. This could require for a separate configuration and another run of Subster. Maybe you do this now on a two step process (first put all rates on Q356 then find Q366 by the Alias and copy exchange rate from Q356 into Q366). I think this comes with the disadvantage to produce over-structured and not very meaningful data on Q356 so I would challenge this two-step procedure. --Spischot (talk) 12:25, 12 January 2013 (UTC)
May be I should also have stated that this was a (fast) first-shot in order to "have something". You are completely corrent in more or less every aspect you mentioned (even though I might have not understood them all yet), especially my misunderstanding and misuse of several concepts. ;)) I would thanks you very much for all your comments and help!! Basically the point is; until now we had a template containing more or less exactly this data, then you used e.g. "USD" as parameter (key) to the template to get the value back (key-value pair). Now to me in fact the only question is how to port this to wikidata? The config should be possible on 1 page, but the values can be distributed over multiple (even though this is not preferred since slow). I put the config on the talk page and "tried to" do an output on the item itself. I also am of the opinion having separate properties would be good, but as I can see the API does not yet provide a possibility to create properties and I was not sure if it is appropriate to create numerous properties by bot just for single use. Greetings --DrTrigon (talk) 22:32, 12 January 2013 (UTC)
Imho your bot should not create properties. Your bot should instead create statements for items (e.g. "EUR") and properties (e.g. "Exchange rate to USD") both having been created manually before your bot runs. I also think you run into a poor solution if you try to port the extract of all currencies in one rush to Wikidata. Think different: Extract only the EUR to USD rate in one run and configure this process (maybe on the talk page, that's an option indeed). When you are done, you can continue to set up a second(!) process to extract the EUR to LTL to a statement in item LTL. --Spischot (talk) 00:04, 13 January 2013 (UTC)
Yes I am aware of this concept (comes up all the time here at wikidata). I just want to submit that this is "somehow impracticable" because of the size of the external data. Some lists contain 1000+ entries. So you would have to setup all those items manually. Of course this can be done over time. But what happens if there is e.g. a slight change in the source data format? In the worst case you end up adopting 1000+ items manually?! Another may be more important point is the performance; it is a huge difference whether the bot has to update one e.g. one item or thousands. That's the reason of my very initial statement that I am "struggling" with some problems here... ;))) One main point is that I have not found any information about the final API design and what kind of modifications and operations can be done performant. Thanks and Greetings --DrTrigon (talk) 12:13, 13 January 2013 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── I understand your concerns about performance and maintainability. You are right that my proposal would be horrible to maintain. I made it because I was afraid that you went for a poor result because you did not see any alternative to produce a better result or because you prioritized performance and ease of maintenance over correctness of the output. Maybe you already considered all of this before - then my input would not have been helpful, of course.

Is the performance problem a result of querying and processing the data source, of resolving codes together with aliases to find the correct item or just the result of having many statments and item to be updated? If it is the latter I do not see a way to overcome this. It's a waste of time to think why Wikidata does not store information in structured tables like a relational data warehouse would to – it is like it is. As there would be not more room to improve the performance for creation of statements the configuration should then be optimized for ease of maintenace (only if the bot could produce the same results from a centralized configuration, of course). Regarding information about the final API design: When looking at all the gaps in the Data model and Denny's recent activities around Representing values and the prototypes for input methods I conclude the design is by far not finalized yet. I'm not surprised that there is no final documentation on this. The best is to watch the project pages and wait. --Spischot (talk) 16:45, 13 January 2013 (UTC)

Sorry for my huge delay... At the moment I am a bit busy - but now I will focus all my wiki-time to this wikidata issue... ;) Give me some time to become familiar with all details again and then I will give a full answer. Thanks for your time and help so far! Greetings --DrTrigon (talk) 11:59, 10 February 2013 (UTC)
So I set-up the bot to work here now (not on wikidata-test anymore) and started doing some test... I reported the result to Wikidata:Requests for permissions/DrTrigonBot may be you want to have a look there too? That would be nice! Thanks a lot and Greetings!! --DrTrigon (talk) 17:26, 10 February 2013 (UTC)

Creative work / Werk / Œuvre créative[edit]

Die Suche nach einen brauchbaren Anker ist bei dem Begriff "Creative work / Werk" noch nicht befriedigend gelöst, denn das item "Creative work / Œuvre" (Q2187400) ist im Deutschen eine Begriffsklärung (de:Œuvre), im Englischen aber ein Artikel (en:Creative work). Unter "Œuvre" versteht man das Gesamtwerk eines Künstlers, während "Creative work" mit Kreativität und Schöpfungshöhe zu tun hat und eher dem Artikel de:Werk (Urheberrecht) entspricht. --Kolja21 (talk) 22:20, 1 January 2013 (UTC)

+1 --Spischot (talk) 22:47, 1 January 2013 (UTC)
O.k., dann ändere ich das mal. (Umverknüpft nach Q574288.) --Kolja21 (talk) 23:07, 1 January 2013 (UTC)

Subpages with tabs[edit]

Looks good! --Kolja21 (talk) 19:10, 3 January 2013 (UTC)

"Note: Please don't take the terms 'person', 'event' etc. literally."[edit]

So how should I take it? I don't understand that note. Maybe an example would help. --Zulu55data (talk) 12:38, 6 February 2013 (UTC)

The "main types of items" are a form of generalization. "Persons" also includes families, the EU is not filed under "organization" but "place" etc. [6] --Kolja21 (talk) 01:44, 13 February 2013 (UTC)

Clean up - and relationship to other pages[edit]

How should these page be related to Wikidata:Property proposal and Wikidata:List of properties? Can we remove all property defintions from these pages, and focus on mapping properties to infobox parameters? Discuss at Wikidata talk:List of properties#Harmonization with infobox parameter names - and relationship to Wikidata:Infoboxes task force. Mange01 (talk) 00:45, 13 February 2013 (UTC)

To clean up, I removed some of the suggested parameters from these pages, as discussed above. However, the suggestions that require more datatypes are not possible to discuss at Wikidata:Property proposal. Should I put them back, or remove the other suggestions for parameters from these pages?
I also suggest that the pages should only be written in English, but may include examples from other Wikipedias, and may be translated to other language versions. Mange01 (talk) 22:14, 15 February 2013 (UTC)

Noble title[edit]

Looking at its uses right now, it is used on a few items for Russian nobles where its value is Emperor of all Russia. That's fine for male nobles but it's not precise for Catherine the Great, who was Empress of all Russia. Even worse is items like Henry III of France where the item used for P97 is List of French Monarchs instead of King of France (presumably that's the wikilink taken from the infobox). Most wikis don't have separate generic articles on noble titles like King of England or Duke of Saxe-Coburg and Gotha, instead preferring to redirect those pages to lists of title holders or articles of the geographical range of the title. So what should we do with titles that don't have specific wiki articles and/or gender differences in titles? Possible solutions that I could think of would be:

  1. Create a dummy item with the correct label but add no site links
  2. Create a dummy item with the correct label and add site links for the page that redirects
  3. Wait for String or MultilingualText to be implemented and use those instead

Any other opinions or ideas? /Ch1902 (talk) 13:22, 19 February 2013 (UTC)

Pro: Waiting for MultilingualText. Since the property has been added without discussion, you can file a RFD. Kolja21 (talk) 14:45, 19 February 2013 (UTC)
Having thought about it some more, and considering the redundancy in the amount of translations using MultilingualText would mean, I've started a discussion at WD:Notability about using items without sitelinks. /Ch1902 (talk) 00:17, 5 April 2013 (UTC)

Colors / Farben[edit]

Suggestion, moved from Infoboxes task force to the talk page --Kolja21 (talk) 17:52, 19 February 2013 (UTC)

Man könnte den Entitäten (Typen) drei Grundfarben zuordnen und das Datenblatt entsprechend farblich (dezent) hervorheben, so wie sich in einigen Sprachversionen z.B. die Diskussionsseiten farblich von den Artikeln unterscheiden. Damit wäre Wikidata für "normale" Leser (humans) leichter lesbar. (Die Farbe für Personen entspricht Commons:Template:Creator.)

Legislation (UK and Commonwealth)[edit]

Hi,

I was wondering if someone that had some spare time would be able to examine this, http://en.wikisource.org/wiki/Portal:Acts_of_the_Parliament_of_the_United_Kingdom/Anne/6Ann

And figure out how to represent that data in an appropriate manner on Wikisource.

I'd like to see a discussion on this,as I would find it useful to have a means of turning regnal/chapter style references back into Short Titles and vice versa, as well as being able to bring up commencment or assent details based on a short title, or regnal data.

It would also be nice to be able to use Wikidata to 'unlock' legislation related data sets which have previously been at a premium. Sfan00 IMG (talk) 12:13, 24 February 2013 (UTC)

Slightly off topic, but a huge amount of UK legislation data is available for free (gratis and libre) from legislation.gov.uk - I used to work with that team. There is definitely scope for Wikidata taking this data along with other sources, but we'll be starting from a very strong base! James F. (talk) 17:53, 28 February 2013 (UTC)
Any progress on this? Sfan00 IMG (talk) 11:42, 3 August 2013 (UTC)

Entitätencodierung: Vergaberichtlinien - Kurzliste[edit]

Does someone know a translation of Entitätencodierung: Vergaberichtlinien - Kurzliste? Otherwise we need to make a translation by ourself. We should add the info to Wikidata:Infoboxes task force/persons/Intro, terms/intro etc. --Kolja21 (talk) 01:30, 26 February 2013 (UTC)

World factbook infobox[edit]

It would be very useful to a have Wikidata for economy infoboxes. eg. GDP, GINI, Exports etc.

Further clean-up and focus only on parameter mapping?[edit]

These page are confusing, and that is probably why so few contribute. Can we remove almost everything from these pages, and essentially only include mapping of infobox parameters to existing properties?

Parameter mapping is important, because it would be helpful for developing bots and gadgets for collecting data from Wikipedia infoboxes. Se for example Wikidata:Tools#Import_statements. It would also be helpful for future inclusion in templates.

Which of the following can we remove?

  1. List of suggestions for properties? (Often quite old proposals. I have already moved some of it to the talk pages. New suggestions should be placed as WD:Property proposals and WD:Property proposals/Pending.)
  2. Non-english language? (The page intros may perhaps be marked for translation to many languages, but a mix of different languages is really confusing.)
  3. Long text about authority control? (Perhaps to a separate task force?)
  4. UML diagrams?

I would like to see many more infoboxes here, also from other Wikipedias than the English.

I also suggest that these pages are used as a loggbok of bot jobs, showing which infoboxes that are fully imported from a certain Wikipedia. Is that okay?

To avoid that these pages becacome huge, I have made some of the infoboxes collapsible/expansible, using the Hidden begin and Hidden end templates. Is it okay to hide every template? Please further improve the structure. Mange01 (talk) 17:13, 13 March 2013 (UTC)

Thanks for taking care. Originally these pages were installed for Wikidata:Property proposal‎. Additionally there have been several sub-projects started, so it's hard to keep updated. --Kolja21 (talk) 00:59, 14 March 2013 (UTC)

/* EE-number / EE-Nummer / EE-numéro / (P303)[edit]

I don't know if to add and where to add Property:P303. May someone help me out? --PigeonIP (talk) 06:47, 20 March 2013 (UTC)

Create a new paragraph in Wikidata:List of properties under Term / Sachbegriff / Terme Snipre (talk) 21:02, 20 March 2013 (UTC)
Created "Animal breeds / Haustierrassen / Race animale" under "Biology / Biologie / Biologie". Thanks for your help. --PigeonIP (talk) 18:50, 26 March 2013 (UTC)

✓ Done

Main type for band/musical group[edit]

What should the main type be for a band? Superm401 - Talk 01:24, 4 April 2013 (UTC)

Q43229 (organization), see e.g The Beatles --Spischot (talk) 05:18, 4 April 2013 (UTC)

Taxa are not terms[edit]

Currently, scientific taxa are given the GND of "term", but this is like listing all persons as "name". The name of a taxon is a term, but the taxon itself includes all organisms that are descended from a common ancestor. Likewise, the Wikipedia articles about taxa are not about a "term", but about the organisms named by that term. "Terms" do not have flowering times, distributions, average clutch sizes, or any of the other qualities that are discussed in their Wikipedia articles. A taxon, like a human family or an organization, is an assemblage of organisms sharing certain qualities in common.

I therefore propose adding a seventh basic GND of taxon to cover this deficiency. --EncycloPetey (talk) 21:19, 9 April 2013 (UTC)

GND main type s is called "term", but you can not take this literally. We first have to change WD:N before we can make any improvements like the one you've suggested. Please look at Wikidata talk:Notability#Main types (GND). --Kolja21 (talk) 21:45, 9 April 2013 (UTC)
No, we don't have to change WD:N, as "taxonomic entries" are notable by default. This already appears in that page. The proposal is to create a separate main type from the general grab-bag item of "term". The way we are using "term", it is a hodge-podge of every item that does not belong to a specific main type; that is, it is defined negatively rather than positively. Biological taxa should be grouped positively, and we need to do something like this now because it affects more than a million articles or potential articles on the Wikipedias, as well as all the pages in the main namespace of Wikispecies. --EncycloPetey (talk) 23:32, 9 April 2013 (UTC)
As discussed in great detail at Property talk:P107 (and elsewhere), these main types weren't just made up by Wikidata. They reuse an existing set of types from something called the "Integrated Authority File". You're not the only one who finds the selection limiting (particularly 'term'), and it was even proposed for deletion. However, it was kept, and just adding a single one type would be arbitrary. For most items instance of is used (which allows any item as the value), though for taxons people seem to use taxon rank. Superm401 (talk) 03:40, 11 April 2013 (UTC)
That may be the history of how we ended up with this situation, but does not address the problem that we have an "everything else" data type. Nor do our main types match those six used by the GND. If we're not actually using a set of items that match the GND, then it isn't a satisfactory argument to say that we got this from the GND. For instance, the GND uses "Name" (as in family names), and we do not. They also use "Subject heading", as the GND was developed specifically for the German National Library. That's fine for them, but a system developed for housing books and periodicals is not necessarily going to meet our needs.
Adding a single type would not be any more or less arbitrary than changes to two of their types, and, as I have noted above, helps serve a great need of ours in dealing with a collection of well over one million specialized data items that share common qualities not found in any other group of data. This thread was stimulated by the fact that a bot was being used to systematically tag all taxonomic entries as "Terms", which is a pointless, needless, and completely uninformative process. My fundamental point is that the data type of "Term" is completely meaningless. This issue was raised at Property_talk:P107#Terms, on the page you mention, but the issue was never resolved. The question of using "Term" as a grab-bag (and therefore meaningless) property is still open. Its presense provides no positive information about an item on which it is placed. I prefer instead to follow the philosophy of marking items with properties they have and share, and not with meaningless markers for the sake of marking. --EncycloPetey (talk) 14:50, 11 April 2013 (UTC)
I think it's best to ignore p:P107 and use instance of, subclass of and part of, as appropriate. For example, I've stated that Homo instance of taxon; the same could be done for all other taxons. Silver hr (talk) 22:50, 12 April 2013 (UTC)
@Silver hr: So this is what you call ignoring? Will you now stop - after trying to rename, trying to change the use, starting about 20 treads against P107 and a RFD - your fight or should I call it war? I've stopped most of my work at Wikidata because I'm not willing to play these games. --23:39, 14 April 2013 (UTC)
 – The preceding unsigned comment was added by Kolja21 (talk • contribs).
As for that edit, you yourself have said that P107 is used for authority control, so I've simply moved it to the "Authority control" table where it belongs, next to the GND identifier property. And by "ignoring" I meant it's best not to use the property in items (because of its multiple problems noted in discussions I'm sure you remember). As for your accusations that I'm a sock puppet of Emw, we've had that discussion elsewhere. Silver hr (talk) 04:01, 23 April 2013 (UTC)
While I agree that "instance of" has no hugely objectionable problems, it still doesn't help to identify or to group these items that share many features found nowhere else. I would argure that they share an underlying property as taxonomic names, and simply identifying them as an instance of such does not bring this to the forefront. As I would use "subclass of" on a taxon, because "subclass" has a very precise meaning in taxonomic nomenclature. And ignoring P107 doesn't resolve the issue of negative properties that "Term" is an instance of. Properties should be positive, and identify things by what they are rather than by what they are not. --EncycloPetey (talk) 01:18, 13 April 2013 (UTC)
GND main type is a totally non flexible standard, and is hardly the only way to define a type. Soon bots in biology will be aware of the use the obvious way of modeling knowledge in this project, lets consider GND for what it is and nothing more. GND main type is really too limited for our needs, just use it for what it is and for what it is helpful: help mapping data with german libraries, and other project which uses it. Ways to regroup taxon, species and co will come with the ability to query the database, this is where the real issues and will make the system usable. TomT0m (talk) 10:04, 13 April 2013 (UTC)
Agreed; GND is not our job to fix before making Wikidata workable, and if GND fails (as it so often does), ignore it. James F. (talk) 11:13, 13 April 2013 (UTC)
RE: Jdforrester: Most recently, I've seen someone tagging taxonomic entries with both GND "Term" and "instance of" taxon. The same user is also using a different value for taxonomic orders than everyone else on the project. With this kind of inconsistency, it will not be easy to query the database, and items will be burdened by lots of uninformative "information". There need to be some standards for handling properties when tagging taxonomic groups. If there are none, then the inconsistency will hamper development and utility of the data. And if we can safely ignore GND in this case, then can a bot be sent around to remove the GND tag of "term" from all taxon pages? --EncycloPetey (talk) 05:05, 14 April 2013 (UTC)
RE: TomT0m: If GND is a "totally non flexible standard", then why has it been changed here on Wikidata? What we are calling "GND" does not match the original set, and therefore it is changeable. Either that, or we need to undo the changes we've made in adopting GND. And if GND is too limited for our needs (which I agree on), then can we tell people to STOP labelling everything with a GND, even when it's not appropriate? And to only use GND when it is actually meaningful? I believe you have a very high expectation of what queries can do with a fouled-up database. --EncycloPetey (talk) 05:05, 14 April 2013 (UTC)
I, this is an interesting question, I have started discussions in project chats on I believe realted topics
Anyway as a quick answer here : I am not sure about what GND is exactly usefull on Wikidata, and if it changes I think we will end with something that is totally different, so why start on something that begun with a totally different mindset as a structural choice ? I am not sure of the function anyway, an the redundancy seems a clear indication that there is something wrong with that ... TomT0m (talk) 10:40, 14 April 2013 (UTC)
I'm not sure it's entirely clear what we're talking about here so let me try to recap (and sorry for the rather long comment). First of all, I'm not a biologist so excuse me if I get something wrong. Also, in the context of knowledge representation, sets of individuals are called classes. "Class" in this sense is not to be confused with the biological concept of "class".
Every living thing/biological organism that exists or has existed is an individual/instance within the set or class of all living things--let's call it "Living thing". Now, biologists have divided this set into three subsets or subclasses they call domains: Archaea, Bacteria and Eukaryota. The relation between any of these subsets and "Living thing" is, obviously, subclass of. Similarly, Eukaryota is further subdivided into Animalia, Fungi, Amoebae, Plantae, Chromalveolata, Rhizaria, and Excavata. These are subclasses of Eukaryota. And so on until we get to the subclass Homo sapiens, which we are instances of. Of course, we are instances of all supersets of Homo sapiens as well, but that doesn't need to be stated explicitly because it is implied.
However, while I said that Animalia is a subclass of Eukaryota, a biologist would say (I assume) that Animalia is a kingdom of Eukaryota, and likewise for every other of Eukaryota's subclasses. That leads me to conclude that "kingdom" is a name for the subclass of relation when applied between Eukaryota and its subclasses. Similarly, "domain" is a name for the subclass of relation between the "Living thing" class and its subclasses. Likewise for all the levels in the hierarchy. Now, this could be expressed with the concept of subproperties. Kingdom is a subproperty of "subclass of" which is limited to the class Eukaryota. Unfortunately, Wikidata doesn't support the concept of subproperties, unlike some other knowledge representation systems.
We are left with the question of what a taxon is. Since all of the named subsets in this hierarchy are taxa, I conclude that "taxon" is the name of the subclass of relation when applied between any set and its subset in this hierarchy. In other words, taxon is a subproperty of "subclass of", and the earlier subproperties are actually subproperties of taxon. So, according to this, I was wrong in my previous response to state that Homo is an instance of taxon.
I'm not exactly sure what your objection was, so does the structuring with instance of and subclass of I've described in this comment resolve it? If not, please state specifically (and preferably with an example) what your objection is. Also, when you add comments on talk pages, please put your comment below the one you're replying to, and one level of indentation deeper. If there are already replies to the comment you're replying to, put your comment below the lowest branch of those replies. I've rearranged your previous comments to conform to this.
Silver hr (talk) 04:01, 23 April 2013 (UTC)
RE: "I conclude that "taxon" is the name of the subclass of relation when applied between any set and its subset in this hierarchy." That definition doesn't work. There are, for example named fossil taxa that have not been assigned any relationship to taxa of higher ranks. That is, some subset relationships are not known and therefore not hypothesized. The fossil genus Prototaxites, for example, is not assigned to any kingdom. So, the taxa exist independently of relationships to other taxa. It is also true that the relationships between taxa change as new data is incorporated. The genus Takakia used to be a member of the division Marchantiophyta, until reproductive structures were discovered that demonstrated it was a moss (division Bryophyta). I know of a cycad that was originally thought to be a fern, and a fossil bird that was originally thought to be a plant. The point is that these errors, ommissions, and changes do not affect the taxa themselves, so they must exist independently of any subset relationships. Yes, there is a goal of elucidating all the subset relationships, but those relationships are not the taxa themselves. --EncycloPetey (talk) 05:32, 24 April 2013 (UTC)
Your example of Prototaxites would be a taxon according to the definition in my previous comment because it is still a subset of the set of all living things, even though presently it may not be defined in more precise terms. As for changes in scientific consensus, I don't see why they couldn't be reflected in Wikidata as they happen. Specifically, Takakia would first have been related to Marchantiophyta via a chain of "subclass of" properties, and then, after the relevant discovery, to Bryophyta. And if what you meant by that example is that you're interested in preserving historical values for the record, we can do that as well. We can have multiple statements with the same property (in this case multiple "subclass of") with qualifiers to specify the difference. Some time in the future, ranks will be implemented as well, allowing us to mark current values with the "preferred" rank, and historical ones with "normal" or possibly "deprecated".
I should also mention that there is another, equivalent, way of looking at this picture, which I was going for in my first comment, and that is to treat classes as both classes and instances. So, Animalia would then be a subclass of Eukaryota, but it would also be an instance of the class kingdom. Kingdom would be a subclass of taxon, and it would also be an instance of the class "taxonomic rank". Likewise for the rest of the hierarchy. Perhaps this is a better way, especially since Wikidata doesn't support subproperties and it's unsure whether it will.
Silver hr (talk) 02:27, 25 April 2013 (UTC)
I concur. Taxa are sets. Taxa do not "have flowering times, distributions, average clutch sizes, or any of the other qualities that are discussed in their Wikipedia articles" but taxa are comprised of organisms, and it is the organisms that "have flowering times, distributions, average clutch sizes, or any of the other qualities that are discussed in their Wikipedia articles". - Brya (talk) 05:20, 12 July 2013 (UTC)

What kind of entities?[edit]

Person, organization, work, place - Real? Virtual? How about such classification ("Space" and "Objects") 1) Space (Frame of reference, Coordinate system, The space of the existence of objects, Area, Areal, Range and so on) 2) Objects of such space. "Subentities" (hierarchy): 1) Matter:Space/Matter:Objects (Physical objects) -> 2) Brain:Space/Brain:Objects -> 3) Virtuality:Space/Virtuality:Objects (virtual objects) -> 4) Mathematics:Space/Mathematics:Objects. For example, Subatomic particle - Physical objects, Real person - Physical objects, Virtual person - Virtual objects. Idea - Brain:Objects, Real work (by this idea) - Physical objects. Point - Mathematical object. Or may be w:Category:Objects? Fractaler (talk) 08:27, 15 April 2013 (UTC)

I'm not sure what you're asking, but (1) I don't see the dividing lines here very clearly, and (2) I don't see this categorization as nearly exhaustive enough. With regard to (1) is a "triangle" part of space, a physical object, an object in the mind, or an object in mathematics. I could see it falling into all of these categories. And is a "wave" a physical object or not? Subatomic particles are both waves and particles, and so it makes a difference, and light travels as a wave. Is magnetism then a physical object or what? Likewise, is "France" a physical object or a nationalistic idea? What about NATO? Is it physical or not? With regard to (2) a "cow" is clearly a physical object, but what about "cattle", "bovines", "bovids", "ungulates", or other groupings of physical objects? And is Shakespear's play Richard III a physical object or not? Is the title character (as distinct from the historical king) a "virtual" object or what? --EncycloPetey (talk) 03:17, 16 April 2013 (UTC)
Yes, until very rough classification (later - more exactly). So, by definitions: w:triangle - "is one of the basic shapes in geometry" (so, only "an object in mathematics"). w:Wave - What kind of? A water wave - physico-mathematical object. w:Subatomic particles - physical object. Mathematical model (behavior) - 1) wave 2) point. w:magnetism - "is a class of physical phenomena" (physical: 1) object, 2) process). "w:France" - what kind of? The territory? The idea? Territory of France - a place in real world (if in virtual, then - a place in virtual world - com games). w:NATO - real alliance, real organization (not virtual). w:groupings (set) - mathematical object, groupings of physical objects - physico-mathematical object. w:cattle, w:bovines, w:bovids, w:ungulates - by w:systematics (objects of systematics). w:Richard III (play) - play (information space). Richard III by play - object in the information space. Fractaler (talk) 11:14, 16 April 2013 (UTC)

Guidance anywhere?[edit]

Sorry if I'm being dense but I cannot find any guidelines on how to actually implement this. I've read that phase II is active, but I cannot see anything other than drafts. If we want to use wikidata in a wikiproject's infoboxes, how do we do this? I'm initially thinking about en:WikiProject Spaceflight and en:Template:Infobox_spacecraft and the large number of satellite articles we have. Are there instructions anywhere? Thanks. Secretlondon (talk) 10:07, 27 April 2013 (UTC)

There are a series of proposals for properties related to these infoboxes at Wikidata:Property_proposal/Space.
Currently the only available property types are "item", "string" and "media". Most infoboxes rely on dates and numbers. Thus we can't map most infoboxes to available properties. Obviously, you can already suggest the specific fields/properties for creation and build statements with items/strings/media. --  Docu  at 10:26, 27 April 2013 (UTC)

Phase 2 on hold für military+weapons templates[edit]

Pls. note http://de.wikipedia.org/wiki/Portal_Diskussion:Waffen#WikiData actually we do not want wikidata for the infobox-spectrum https://de.wikipedia.org/wiki/Kategorie:Vorlage:Infobox_Militär_und_Waffen This can change if a new consensus shows up with partcipation of Q12101076 + Q12099956. Regards --2.206.0.14 08:33, 29 April 2013 (UTC)

Where do railway topics fit in the infobox types?[edit]

I just stumbled upon Wikidata today while updating the Trains Portal on en.Wikipedia. Since I'm heavily involved in editing rail transport related articles there (and especially since I was the editor who originally created the locomotive infobox in 2006, my first thought was to find how data for these topics will be centralized and what needs to be changed on the individual wiki templates. Since creating that template, a number of other rail transport related infoboxes have been created for railway companies, stations, multiple units, railway lines, passenger services, etc., but I don't see how they all fit into the persons/organizations/events/works/terms/places hierarchy here. Sure, the railway companies infobox would be an organization infobox, and the stations infobox would be a places infobox, but where do we fit the locomotive infobox? A locomotive is not really a creative work in the same manner as the artwork categories that are listed there now.

So, I'd like to help with getting railway related infoboxes integrated, but I'm unsure where to start. Thanks! Slambo (talk) 17:22, 25 May 2013 (UTC)

Wikidata:List of properties and Wikidata:Property proposal for any new ones. What sort of properties do current railway related items have and what should they have? Secretlondon (talk) 22:17, 26 May 2013 (UTC)
Thanks, I'll take a look at those pages. The answer to your question depends on what railway related item you're looking at. For example, steam locomotives have information such as the fire grate area, boiler pressure, cylinder pressure and water capacity; while diesel locomotives have information on the prime mover model, the type of traction motors and the transmission; and electric locomotives have information on the power system voltage and collection method; while all locomotives have information on the gauge, wheel arrangement, builder and operational details. If we look at railway lines, there is information on the line's endpoint stations, the line's length and minimum/maximum elevations, the year the line was first opened, and the companies that have operated over the line. Stations have similar data for the railway company that first opened it, where it is/was located, the number of tracks and platforms, and the dates that the station was opened and closed. Slambo (talk) 14:23, 27 May 2013 (UTC)
Motors may be covered by Property:P516, others are manufacturer, designer, located. 'Type of' relationships will be covered by Help:Basic_membership_properties. Dates are yet to be implemented. There already seem to be five railway related things on Wikidata:List_of_properties/Geographical_feature - connecting line, operator, railway alliance, adjacent station, station code. Secretlondon (talk) 19:54, 28 May 2013 (UTC)

Make embedding data in wikipedia human readable[edit]

Hi I believe that information should be easily accessible to everyone. This is why i support wikipedia and this is why i propose what i propose here. At the momement if one wants to include data from wikidata into wikipedia one has to use this human unreadable synthax: {{#property:p35}}. Using p35 instead of the name of the property is bad since new users are disturbed and it is not intuitive! It would be better to use {{#property:NAME OF PROPERTY}} e.g. {{#property:head of state}}. Technically this should be quite easy since one can use a dictionary to translate the Name of the property to the identifier pXX (e.g. p35) - so in the background not that much has to change . Please fix this as soon as possible. Otherwise wikidata will be rejected by many wikipedians. --92.202.103.41 08:27, 25 July 2013 (UTC)

Wikidata will probably be implemented by people, who make templates, ie this will not be something normal Wikipedians would come across. Littledogboy (talk) 10:55, 25 July 2013 (UTC)
this is so not true.
Albert Einstein ({{#property:P569}}; {{#property:P570}}) was ....
and if it were true, it is such an "I so do not want it!"
In an Infobox: if it must be, OK. In the article-text - NO! --PigeonIP (talk) 12:30, 25 July 2013 (UTC)
I can imagine to have templates for properties to use wikidata in the text. For example {{wd:birth date}} and {{wd:birth place}}. This would be easier understandable and the wd shows that the data comes from Wikidata. --Pyfisch (talk) 15:21, 25 July 2013 (UTC)
+1 strong support --Biggerj1 (talk) 15:36, 25 July 2013 (UTC)
This is planned. I'd show you, but the servers are down atm. Littledogboy (talk) 16:47, 25 July 2013 (UTC)
lookup of properties by label in the clients should work, such as {{#property:head of state}}. I tried and it works for me. Aude (talk) 18:32, 25 July 2013 (UTC)
Here. -- Littledogboy (talk) 20:03, 25 July 2013 (UTC)
please make including properties through {{wd:birth date}} ... available as soon as possible. otherwise people wont start using wikidata (including me)!--141.58.44.204 19:12, 25 August 2013 (UTC)

Unfortunately, designers of Wikidata and the inclusion syntax didn't think through that property titles are not stabilized. Only the number code is a stabilized identifier. Somebody can correct or changed the title and such links will become blind. The same problem is with item links. --ŠJů (talk) 01:54, 1 September 2013 (UTC)

Reuse existing mappings from DBpedia[edit]

We (DBpedia) already did a lot of work in mapping Wikipedia templates to our ontology [1]. Last year, as part of GSoC (Google Summer of Code) we started implemented (simple) DBpedia to Wikidata mappings (see [2] [3]). Everything is open sourced and open licensed and we have been always open for collaboration with Wikidata.

[1] http://mappings.dbpedia.org/index.php/Main_Page [2] http://mappings.dbpedia.org/index.php/OntologyProperty:Family [3] https://github.com/dbpedia/extraction-framework/wiki/GSOC2013_Progress_Hady-Elsahar Jimkont (talk) 07:00, 13 March 2014 (UTC)