On 1 April 2012 13:04, Markus Krötzsch <markus.kroetzsch(a)cs.ox.ac.uk> wrote: to This is a technically valid solution. Socially, I fear it would lead to endless uncertainty which mechanism to use. Few abstract entities will have exactly the same delimitation/width, but where should one switch from one method of linking (one wikidata page with several more less closely matching wikipedia pages) to the other (several wikidata pages, one for each wikipedia page in each language)? Also, importing data will be a nightmare, because the concepts used in imported data will have to be compared with all wikipedias. One Wikipedia-language-version has the post-WWII extent of Russia as well as the current and another Wikipedia-language-version has them separated. It may not have mattered before and only one Wikidata page links to both language-versions. However at some point historical data are imported and suddently Wikidata needs to be reorganized to have two pages. ... Just thinking loud - this may be unavoidable perhaps... However, my gut feeling is that if you plan to avoid relations between Wikidata and Wikipedia, it might be a more comprehensible model to then always using only one method, i.e. have a 0 to 1 or 1 to 1 relation between Wikidata page and Wikipedia page only, and express everything else in Wikidata to Wikidata page relations. These relations are then easily traceable and updateable, just as the broadness or narrowness of a page in a given Wikipedia develops over time. cover This worries me. It means that there will be forever conflicting systems of editing interwiki links. If everything can be achieved with Wikipedia, but only a subset with Wikidata, it spells social adoption danger. _______________________________________________ Wikidata-l mailing list Wikidata-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l

On 1 April 2012 13:04, Markus Krötzsch<markus.kroetzsch(a)cs.ox.ac.uk> wrote: This is a technically valid solution. Socially, I fear it would lead to endless uncertainty which mechanism to use. Few abstract entities will have exactly the same delimitation/width, but where should one switch from one method of linking (one wikidata page with several more less closely matching wikipedia pages) to the other (several wikidata pages, one for each wikipedia page in each language)? Also, importing data will be a nightmare, because the concepts used in imported data will have to be compared with all wikipedias. One Wikipedia-language-version has the post-WWII extent of Russia as well as the current and another Wikipedia-language-version has them separated. It may not have mattered before and only one Wikidata page links to both language-versions. However at some point historical data are imported and suddently Wikidata needs to be reorganized to have two pages. ... Just thinking loud - this may be unavoidable perhaps... However, my gut feeling is that if you plan to avoid relations between Wikidata and Wikipedia, it might be a more comprehensible model to then always using only one method, i.e. have a 0 to 1 or 1 to 1 relation between Wikidata page and Wikipedia page only, and express everything else in Wikidata to Wikidata page relations. These relations are then easily traceable and updateable, just as the broadness or narrowness of a page in a given Wikipedia develops over time. This worries me. It means that there will be forever conflicting systems of editing interwiki links. If everything can be achieved with Wikipedia, but only a subset with Wikidata, it spells social adoption danger.

I certainly appreciate your experience in system design, Markus! Still, I feel strongly about this so I poke another time. :-)

My analysis is that one of the two doors should closed in the first iteration. This iteration could start with a clean system, that is easily analyzed and has the potential of a better learning curve (it does not delegate the difficulty to decide which door to use to the user). If it turns out that both options of relations are needed, I believe it is possible to add them in the next iteration. My interpretation of the options: Solution 1 (my preference for the sake of simplicity): ======== A wikidata page reflects an independent entity that may be an exact, close, narrower or broader match with several Wikipedia language versions. That is, each Wikidata page has relations to 0-n Wikipedias, Wiktionaries, or Commons (NEW PROPOSAL to extent beyond Wikipedia alone), each of which is labeled by exact/close/narrower/broader match (SKOS vocabulary). In addition (NEW PROPOSAL) it allows to express relations to other definitions outside of Wikipedias, Wiktionaries, Commons, esp. were the entity is complex to understand or map to Wikipedia entities. This would be a natural extension of the Wikipedias, Wiktionaries, or Commons to the entire semantic web. An option to be researched over time would be, whether a "defining link" qualifier must be present on one relation, pointing either to a Wikipedia permalink to a given version or to an external permalink. The great advantage of this system to me is that it can deal efficiently with data where an import is desired, but where the exact mapping to Wikipedia pages is difficult to ascertain. Solution 2 (clear cut version of your present proposal, perhaps cleanest solution): ======== A wikidata page reflects 0-1 Wikipedias, Wiktionaries, or Commons pages. Relations such as exact/close/narrower/broader between the language versions (the interlanguage links) are stated only between Wikidata pages. Advantage to me: Clearcut design. As Wikipedia pages develop and become broader or narrower in scope, only the relations between wikidata objects need to be changed. However, property data of the Wikidata page may become false as the linked Wikipedia page in a given language changes. Solution 3 (your present preference to express relations with two structurally separate means): ======== A wikidata page reflects 0-n Wikipedias, Wiktionaries, or Commons pages. If two pages are an exact or close match, they are stored as multiple Wikipedia-Links to a single Wikidata page. A differentiation between close and exact match is not possible. If a given language version of Wikipedia is sufficiently different from another one, it must be linked to a newly created, independent Wikidata pages. Relations between Wikidata pages can be qualified as narrower/broader (but not close or exact match, these are required to be given the same Wikidata page. Advantage as I see them: None. Potential problems with solution 3: 1. The user is expected to use two widely different actions depending on whether two language versions are sufficiently closely matching or not. The actions are structurally different, and it is unlikely that this can be hidden by the user interface (because wikidata page object creation and deletions are involved) The burden of the decision where to draw the line is left to the user community. Revisions of this decision within the community require creating or deleting Wikidata objects, and are therefore likely to be difficult to make transparent. 2. Scenario: If two Wikipedia language versions describe more or less the same abstract object, but one is later revised to be more narrow, the other more broadly, a careful study of the changes of the revisions since the creation of the wikidata page object is required, to decide which Wikidata page remains linked to a Wikipedia page, and for which revision a new one must be created. Or whether perhaps two new ones must be created? apologies for pestering you with this... Gregor _______________________________________________ Wikidata-l mailing list Wikidata-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l

We should take care not to overrate this topic. There are hundreds of thousands of articles that have a unique, exact match between different language versions.

Cities,

countries,

works of art,

We are going very soon to look into the actual data. If my current assumption holds, that more than 99% of all links are simple 1:1 links, the requirement for a more complex system might be deferred to later.

Wikidata can (and probably will) store information about each moon of Uranus, e.g., its mass. It does probably not make sense to store the mass of "Moons of Uranus" if there is such an article. It does not help to know that the article "Moons on Uranus" also talks (among other things) about some moon that has a particular mass: you need to know what *exactly* you are talking about to exploit this data. An article on "Moons of Uranus" could still (eventually) embed Wikidata data to improve its display, but this data must refer to individual moons, not to the article as a whole.

The label and the description together are meant to be identifying. I.e. "Georgia - A country in central Asia", or "Frankfurt - A city in Hesse, Germany", etc. Additionally, the Wikipedia links provide quite some guidance to it.

Regarding definitions: Note that I said "Label + Description is identifying", not merely the label. I assume this to be true because even for your example of "Germany", the disambiguation page works with rather short descriptions of each disambiguated page [1]. So even that fuzzy concept that you gave an example seems to be sufficiently identifiable for the sake and mission of the Wikipedia community, which gives me reason to believe that the community can sort this out. I mean, they basically already had! Regarding the Kangoo / Kubistar example: In Wikidata they would be represented as two pages, one for the Kubistar (which would link to the Danish and German page for the Kubistar), and one for the Kangoo (which would link to the 20 language versions of the Kangoo article, including a Danish and a German one). This is a rather simple example, which would be easily expressed with the exact matches that we suggest. In Wikidata, the Wikipedia links are planned to be inverse functional - i.e., every Wikipedia article in a specific language can only be linked to from one single Wikidata article. Two Wikidata pages cannot claim the same Wikipedia article in a single language as their defining article. I.e. in the Kubistar/Kangoo example there would be two Wikidata pages. One about the Kubistar, linking to de:Nissan_Kubistar and da:Nissan_Kubistar, and one about the Kangoo, linking to the 20 different Kangoo articles. The Wikidata page for Kubistar could not link to any of those Kangoo articles. Please do not misunderstand, I am not categorically against nonexact matches or broader or narrower (or else I wouldn't be discussing). But I haven't seen examples yet that convince me that the additional complexity of broader/narrower or unexact is required. As I said before, if we can model more than 99% of all language links with the suggested simple solution, I am reluctant to make it more complicated for the remaining <1%. Cheers, Denny P.S.: oh, yes, indeed! Thank you for this excellent and interesting discussion, it really does shed light on some of the aspects of the current draft of the data model, and will eventually improve it and sharpen the understanding of the model. [1] https://en.wikipedia.org/wiki/Germany_(disambiguation) 2012/4/5 Gregor Hagedorn &lt;g.m.hagedorn(a)gmail.com&gt; On 5 April 2012 18:30, Denny Vrandečić &lt;denny.vrandecic(a)wikimedia.de&gt; wrote: I believe it will be difficult to craft labels that work as definitions. A label is hinting, and may often be sufficiently precise for the majority of purposes. If we speak of "Germany" it is very hard to express in a simple string the different historical, geographical, political delimitations that this term may carry. In my own field of work even technical terms are often difficult to resolve to a definition. In biology, the width of taxon delimitations changes over time and with new research, and even technical terms in morphologoy often have quite different meanings, depending on the "school" that is being followed. Or to cite a car example again: The label "Renault Kangoo" is unspecific as to the version/revision/release of it, so technical data that vary between these versions can not be added to it. However, the de.wikipedia.org/wiki/Nissan_Kubistar is in most Wikipedias also subsumed under "Renault Kangoo". So it is a valid assumption that when labeling something "Renault Kangoo" it refers to both of these identical models sold under different names. But then, the "Nissan Kubistar" is only equivalent to the first version/revision/release of the "Renault Kangoo"... This is not unsolvable, but if you want to import or add data to an element, it will be very hard to judge from a short label the correct concept. I was hoping that linking this to Wikipedia articles would help, but this will be hard if a Wikidata page is linked to 40 Wikipedias, any given Wikidata editor can read only a handful of, and with no support to distinguish between exactMatch and closeMatch. My suggestions is to allow a differentiation of exactMatch and closeMatch and instruct editors to use at least one exact match, and considers this or these the defining wikipedia pages, whereas other are added as close match. Of course, the label will remain useful to stumble of changes in definition of width of concept over time, and correct those after consulting the revision number to which the original links was formed (not present, but perhaps achievable by some timestamping and comparison?) Gregor _______________________________________________ Wikidata-l mailing list Wikidata-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l -- Project director Wikidata Wikimedia Deutschland e.V. | Eisenacher Straße 2 | 10777 Berlin Tel. +49-30-219 158 26-0 | http://wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. _______________________________________________ Wikidata-l mailing list Wikidata-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l

The problem I see is that you have no definition to which real object the data are tied. We agree that the problem is not the interwiki links per se. It is what results from it. How do we tie data to a wikidata page when we don't know what it is about?