Wikidata

Wikidata:Requests for comment/One vs. several sitelink-item correspondence

< Wikidata:Requests for comment
An editor has requested the community to provide input on "One vs. several sitelink-item correspondence" via the Requests for comment (RFC) process. This is the discussion page regarding the issue.

If you have an opinion regarding this issue, feel free to comment below. Thank you!


THIS RFC IS CLOSED. Please do NOT vote nor add comments.

Although the original RfC has been closed, the problem has not been solved yet and the discussion continues in new sections of this page.

This RfC explores possible solutions to the Bonnie and Clyde problem.

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

No consensus looking at this RfC. Since this is a technical matter - forwarded to the development team to show the community side discussion. John F. Lewis (talk) 15:22, 14 May 2014 (UTC)[reply]

What the problem is edit

The current way of linking wikipages to wikidata items is based on the assumption that there's one and only one item for each wikipage. This isn't always the case:

Q394087 (sl:Občina Žiri) and Q15933 (sl:Žiri) are separate concepts (a Slovenian municipality and its capital city). In enwiki, both are joined in en:Žiri. Right now, the enwiki page is linked to Q394087, but in fact it applies to both. So, right now, as far as wikidata knows, the enwiki article is just about the municipality, not the city. This sounds problematic, for a few reasons:

  • From the slwiki city page, there is no way to know there's an enwiki page about the city.
  • If we were to start using wikidata info to create infoboxes instead of maintaining them by hand, the enwiki page wouldn't have access to the city info.
  • A bot extracting data from the enwiki article is likely to assume all of it applies to the wikidata item, since there's only one, and add wrong information (I've seen a few of these marked as both city and municipality, and Q17932 was an instance of both city and river until I moved the river bit to Q13359982 - although at least the latter seems to have been marked by hand and not by a bot).

Possible solutions edit

Make all wikipedias have at most one page per item and one item per page edit

This sounds like the ideal option, but it also seems quite impossible to enforce (in the mentioned cases it might be OK but different wikipedias have different ideas about what's notable and what doesn't deserve its own article). Not really an option.--Reosarevok (talk) 23:22, 29 May 2013 (UTC)[reply]

Allow linking a sitelink to several items edit

This seems like the most reasonable choice, but it clashes with the current wikidata constraints and possibly with the way interwiki links work. I'm not sure if this can be worked around?

  •  Support unless somebody provides a good reason not to. This could benefit this database in certain cases. TCN7JM 20:53, 27 May 2013 (UTC)[reply]
  •  Support I don't see why it couldn't work with interwiki links. The DB query for items linked to an article would then return a list instead of a single item and the IW list would be a union of the elements in those items. Kmiki87 (talk) 20:22, 29 May 2013 (UTC)[reply]
  •  Comment If I understand correctly, this option proposes that a particular Wikipedia page can be linked to more than one Wikidata item? This would imply that an article in some language possibly has several articles in another language, which is certainly a break from how the Wikipedias operated so far. Did you look into the reasons as to why they operate as they do (one language version per article)? Perhaps there's an important reason. My speculation is that, to use your example, enwp could have separate articles on Municipality of Žiri (Q394087) and Žiri (Q15933), it's just that so far there wasn't anyone who cared enough to write up a sufficient amount of text for both articles so that they could stand on their own.
Also, you claim that "If we were to start using wikidata info to create infoboxes instead of maintaining them by hand, the enwiki page wouldn't have access to the city info.". That's because currently, you can only access data implicitly from the connected item--you can't specify an arbitrary item ID you want to access data from. But if you had multiple items connected to a page, you'd have to specify explicitly which one you want data from--so that argument is moot. As to the bot problem, bot operators should be instructed to extract data on local stuff such as cities from the respective local Wikipedias because they most likely have the most complete data. Silver hr (talk) 00:59, 31 May 2013 (UTC)[reply]
 Support Doesn't it imply that because that's exactly what the situation is? When one Wikipedia has a page covering both A and B (regardless of the reasons why, since we can't force Wikipedias to separate concepts unless they want to) and another has a page covering A and a page covering B, then the page on the first Wikipedia corresponds to either both page A and page B on the second Wikipedia or neither of them. It certainly doesn't correspond to only one of the pages. --Nikki (talk) 21:45, 2 June 2013 (UTC)[reply]
 Comment Why I oppose strongly? Because this a very common problem and needs to be dealt with logically. If Wikidata is an ontology (one of its two main aims), than it should have items for both glassblower (Q1413824) and glass blowing (Q12185286). Since most Wikipedias would be right to have only one of those pages covering both (or not, doesn't matter), in an ontology these are two different things. Items are for things, not for articles. Redirects would be ideal. Littledogboy (talk) 14:26, 3 July 2013 (UTC)[reply]
 Strong oppose this is not the Wikidata should work. --Pyfisch (talk) 16:30, 2 June 2013 (UTC)[reply]
Care to elaborate? I'm not too sure *why* it shouldn't work like this, and your comment doesn't really help me understand it :) --Reosarevok (talk) 21:55, 2 June 2013 (UTC)[reply]
 Strong oppose endless mess would ensue. Littledogboy (talk) 12:41, 3 July 2013 (UTC)[reply]
  •  Comment How exactly would that work? Lets say we add en:Student to items representing "student of a university" (de:Student) and "student of a school" (de:Schüler). Which link(s) to the German Wikipedia should then appear in the English article, and - if more than one - how would they be distinguished from each other? --Tobias K. (talk) 16:32, 7 July 2013 (UTC)[reply]
 Oppose in this form but  Support in a slightly different form. Unless Wikipedia implements some kind of interwiki disambiguation pages, which you would allow you to choose to go to e.g. either de:Student or de:Schüler when you click on the German link at en:Student, it is indeed best to have at most one item linked to a Wikipedia article since there is no way to determine which of the items (if more than one were linked) should be used for the German link. If such disambiguation pages won't be implemented, then there will indeed be no solution to link (in this case) en:Student to de:Schüler, but this is how it has always been.
It might however still be possible to link de:Schüler to en:Student without the need to manually add the English link to the German Wikipedia article, by having a slightly different solution than the one proposed here. This would imply a small addition to the Wikidata implementation that would allow to state: "instead of the linking schoolchild (Q48942) (linked to de:Schüler) to Wikipedia article en:Student which is already in use by student (Q48282), link it to Wikidata item student (Q48282) and use its enwiki-link to link schoolchild (Q48942) to an English Wikipedia article". This way, schoolchild (Q48942) will be indirectly linked to en:Student and only one item will have a direct link to it. It is a way of saying "if you want to find more information about schoolchild (Q48942) on the English Wikipedia, you should go to the English article for student (Q48282) where it is being discussed" without involving Wikipedia itself. This has several advantages, not only for interwikilinking:
  • There is no longer the need to add interwiki-links to Wikipedia articles.
  • All items can be linked to a Wikipedia article, even if the relevant article has already been linked to an item.
The last one has big implications regarding items that will be used to populate e.g. infoboxes. If it concerns an item that has no direct link to a Wikipedia article because it is already in use, then it could not be automatically wikilinked in the infobox. However, by creating an indirect link this does become a possibility.
So the English and German sitelinks for student (Q48282) and schoolchild (Q48942) would look as follows:
Q48282 Q48942
enwiki en:Student enwiki Q48282->enwiki
dewiki de:Student dewiki de:Schüler
Of course, in case of enwiki for Q48942 it would show as a link to en:Student, but with a little different layout to show that it is an indirect link.
If the direct link to en:Student would be removed from student (Q48282) (most likely when it is in the process of being moved to another item), then the indirect link at schoolchild (Q48942) could be kept in place as a representation meaning "information about this item (schoolchild (Q48942)) on the English Wikipedia can be found wherever information about that item (student (Q48282)) on the English Wikipedia can be found". Until student (Q48282) has no sitelink, schoolchild (Q48942) would obviously not show a sitelink either, but it would have different layout to show that the indirect link is still in place. student (Q48282) would then either be linked directly to a different English Wikipedia article or indirectly to the one it was previously linked to via the item which received the direct link. In the last case, schoolchild (Q48942) would be linked to an article via two other items, but I don't think this would be a problem unless it kills performance, in which case a bot could periodically change the indirect links to point to the items that received the direct links.
What must be prevented though is that loops are created, like changing enwiki for Q48282 to "Q48942->enwiki". This can however simply be checked by walking down the chain of indirect enwiki-links starting at the item that is being linked to (Q48942) and determining if it would eventually link to Q48282, where in this case it would (and should therefore be denied). One of the items in the potential loop should be given a direct link to solve such situation.
Like with the original proposal of having multiple items linked directly to one article, it doesn't satisfactory solve the problem with retrieving data from multiple linked items, but it does solve these (inter)wikilinking problems. —Thayts (talk) 16:12, 5 October 2013 (UTC)[reply]

Create redirects in wikipedia and link those edit

This is pretty much an ugly hack to do the previous option without completely changing the constraint, but it would be possible to do something like creating a en:Žiri (city) page that redirects to the actual one, and link that to the city item (provided the request to allow linking to redirects is accepted).

I disagree with your statement that it is a Wikidata issue. Unless I'm mistaken, Wikidata aims to be more than an interwiki mechanism or a data store for Wikipedia infoboxes; it aims to be a semantic database in its own right. As such, it needs to have entries on all notable items, and I expect that towns *and* municipalities are notable. Wikipedias, on the other hand, are collections of articles. They want their articles to have a certain minimum amount of text in them, which is why they create compound articles about multiple things when those things individually don't have enough text to merit separate articles. This is precisely where the problem lies, and it is not our problem--it is the problem of the Wikipedias. If they want convenience in the form of not having to read several small articles instead of a larger one, *and* they oppose having some extra redirects to fix the problem to an extent, then they lose the convenience of having Wikidata sitelinks for all the things the larger article is about. Well, in my opinion anyway. (And, of course, the problem can always be solved by writing articles with sufficient content about the things separately--a win-win situation.) Silver hr (talk) 00:29, 1 December 2013 (UTC)[reply]
  •  Oppose I don't see how we can force Wikipedias to not delete redirects they don't want/need just so that Wikidata can link to separate pages. Also, perhaps I don't understand Wikidata well enough, but I also don't see how it even would work. As far as I can tell, looking up the Wikidata page for the English Wikipedia page "Žiri" would either resolve all the redirects and find both Wikidata items (in which case, why not just allow a page to be linked to multiple Wikidata items in the first place?) or it wouldn't and you would get one of the two concepts at random (depending on which concept got the main page name and which got the redirect), which sounds like the worst possible solution, since people would be completely unaware that the page is really split into two separate concepts in Wikidata. --Nikki (talk) 21:45, 2 June 2013 (UTC)[reply]
The wikipedia page for two items would link to a corresponding Wikidata page. This would have links to pages for the individual items using the 'consists of' property. This page would not have statements describing these items.
The two wikidata item pages for the individual items would each link to wikipedia redirect pages. Each would have statements describing that item.
The wikipedia page with two items could have two infoboxes, one for each item, however the infobox would need to be told where to find the corresponding wikidata page since it could not use sitelinks to link to these. This would require some additional functionality to be developed. Filceolaire (talk) 11:44, 14 June 2013 (UTC)[reply]
That doesn't address the point I made that I don't see how we can force Wikipedias to add/keep redirects they don't want/need just so we have something to link to, though. The original example, for example, has no existing redirects for the city and municipality, we would have to create them. --Nikki (talk) 14:53, 18 June 2013 (UTC)[reply]
No one is forcing anyone, this is all consensual ;-). Someone wants to link to en:Mariensäule from de:Mariensäule (München). Real-life example. Littledogboy (talk) 09:22, 24 July 2013 (UTC)[reply]
  •  Support. The only way of reconciling the two basic functions of Wikidata (serve Wikipedias + be an ontology). Littledogboy (talk) 12:43, 3 July 2013 (UTC)[reply]
  •  Strong oppose, I hope this will never happen per Nikki. --Stryn (talk) 14:03, 3 July 2013 (UTC)[reply]
  •  Strong support No one is forcing the wikipedias to keep redirects. If the redirects get deleted then the site links stop working and we don't have langlinks to that wikipedia. Not a problem. The Wikidata pages for the individual topics will still have the info on that topic and the sitelinks to other wikipedias will stil work. Filceolaire (talk) 14:16, 3 August 2013 (UTC)[reply]
  • Do you mean that you can go e.g. on the Finnish Wikipedia, and make some redirect there just for making a link for one item? Users on fi-wiki wouldn't be happy if you will make unneeded redirects. --Stryn (talk) 17:28, 3 August 2013 (UTC)[reply]
  •  Support Anything that will help me out of this translation problem over this synonymous words problem. Ugly? I call it Godsend!AldNonUcallinme? 07:05, 7 February 2014 (UTC)[reply]
  •  Strong oppose I prefer not to have a interwiki, rather than have a wrong interwiki. I still correct few thousand wrong interwiki on wp:fr, I start doing it 1 year ago... I think some peoples doesn't understand that allowing that, created error in long terms... --Nouill (talk) 13:29, 8 March 2014 (UTC)[reply]

Link them to one of them and hope for the best edit

I guess this is always an option...

Allowing use of anchored interwiki sitelinks edit

I think this way the problem will be solved, partly: eg. while there is just one article (student) for conveying both school student(Persian:Danishamoz) and university student(Persian:Danishjoo), each of them refer differently to the same English article "student"(The Persian article Danishamoz can refer to the whole article and The Persian article Danishjoo can refer to an anchored #Mature students part of the English article)--دوستدار ایران بزرگ (talk) 05:26, 28 May 2013 (UTC)[reply]

Use the old interwiki system for this type of cases edit

  • From the slwiki city page, there is no way to know there's an enwiki page about the city.
Simply add [[en:Žiri]] in it.
  • If we were to start using wikidata info to create infoboxes instead of maintaining them by hand, the enwiki page wouldn't have access to the city info.
It depends on the way we create infoboxes. I think that an article about two different concepts should have two different infoboxes.
So do I, but if one of the concepts isn't linked to the article, that won't help much.--Reosarevok (talk) 13:28, 17 June 2013 (UTC)[reply]
  • A bot extracting data from the enwiki article is likely to assume all of it applies to the wikidata item, since there's only one, and add wrong information.
It is the bot's operator's job to check that...

Regards. Peter17 (talk) 19:56, 13 June 2013 (UTC)[reply]

???? edit

Please suggest other options.

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Sitelinks with fragments edit

A respawn of #Allowing use of anchored interwiki sitelinks discussed in a separate RfC

Use a property edit

↓ Copied from Project chat ↓

The problem to solve is that when you are reading de:Schüler, you won't know how to find anything similar in other languages, because there are only 21 sitelinks in Q48942. There are 66 sitelinks in Q48282, which is very similar. However, you will not know, that in de:Schüler you have to follow a Student blue link to find those 66 sitelinks. This could be solved with a property, let's call it "Similar to":

Q48282 Q48942
Similar to (P123456789) Q48942 Similar to (P123456789) Q48282
enwiki en:Student enwiki
dewiki de:Student dewiki de:Schüler

Then, Wikipedia could get the missing sitelinks from (possibly multiple) similar items and (optionally) format them differently to suggest that it is not an exact corresponence.

The idea could be extended to note the order of preference of the similar items or which of the similar items is prefered for a specific target language. Petr Matas (talk) 02:07, 15 November 2014 (UTC)[reply]

↑ Copied from Project chat ↑

I filed a property proposal. Petr Matas 18:43, 13 December 2014 (UTC)[reply]

Convert sitelinks into normal properties edit

The problem in my opinion stems from the fact that the Wikidata software assumes there is a 1:1 relationship between concepts/items and Wikipedia articles about the concepts/items. Therefore we treat sitelinks special, the software knows about them and presents them in a special section of the page. I think the solution could be to convert the sitelinks to normal statements we make about an item by using a property like described by source (P1343) pointing to an item of (a sub-)type of Wikimedia article page (Q15138389) on the item describing the concept. This way multiple items could point via described by source (P1343) to the same article.

Resolving interwikis would then amount to finding the items/concepts relating to a page and from the items/concepts search the articles in other language Wikipedias describing those concepts. If there is only one article found, one has the current situation, if multiple articles are found, the Wikipedia software can group them by concept.

Does this sound reasonable? --S.K. (talk) 11:31, 11 January 2015 (UTC)[reply]

 Oppose. Per WD:Main page, "Wikidata acts as central storage for the structured data of its Wikimedia sister projects including Wikipedia, Wikivoyage, Wikisource, and others." That's where the special handling of interwikis comes from. For example, an interwiki is automatically updated when an article is moved to a new title. If I undestand correctly, it is proposed to have a separate item for every article on every Wikimedia project. Currently we have about 13M Wikidata items and 62M sister project articles. I think that it is useless to create for each article an item merely linking to it. Using an authority control property similar to VIAF ID (P214) without creating separate items would be better, but you don't need to drop the special status of interwikis to modify the 1:1 relationship requirement anyway. I think that the special status question is only loosely related to this RfC. Petr Matas 14:40, 11 January 2015 (UTC)[reply]
 Comment The above is a goal (which I support), but it doesn't say how the goal is reached, or does it? Regarding the proposal, there are two way one could achieve this, a reduced one by making items only for articles having multiple meanings or - like you describe and my preferred solution - making an item for every article. This to me would have other benefits, one could make statements about Wikipedia article like featured article, maintenance tags, etc. as well. --S.K. (talk) 07:22, 12 January 2015 (UTC)[reply]
@S.K.: What precisely do you mean by "the above"? Don't hesitate to modify your comment and delete this one. Petr Matas 23:01, 12 January 2015 (UTC)[reply]

Related discussions edit

Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Requests_for_comment/One_vs._several_sitelink-item_correspondence&oldid=1102557706"