Last modified: 2014-11-01 13:38:13 UTC
We should make it possible on the client to access data from an item that is not connected to the current page. (filing as someone asked for a bug to follow progress on this)
Very important functionality IMO. Two possible, realistic, use cases: 1) We have an infobox in the article about sunflower (Q171497). We want to show that Linnaeus (Q1043) is the author of this species. Because this is botany, we don't want the infobox in Q171497 to show Linnaeus' full name. Instead we want the infobox to show the "botanist author abbreviation" (Property:P428) from the external item Q1043. In other words, we need to be able to get the value of a property of a different item than the article in question. 2) The species sunflower belongs to the genus Helianthus which belongs to the tribe Heliantheae which belongs to the subfamily Helianthoideae which belongs to the family Asteraceae which belongs to the order Asterales which belongs to the unranked (!) group Asterids which belongs to the unranked group Eudicots which belongs to the unranked group Angiosperms which belongs to the kingdom Plantae. Storing all this information in Q171497 plus all of sunflower's close relatives requires a proverbial ton of redundancy in the data. I would much prefer to be able to traverse the items in at least 10 or 20 levels, to get the relevant name, rank, and possibly some other information from each group/level in the hierarchy. All this will be displayed in the infobox of sunflower (Q171497).
I have another use case for this, as explained at https://www.wikidata.org/w/index.php?title=Wikidata:Properties_for_deletion&oldid=49338731#Property:P289 and https://www.wikidata.org/w/index.php?title=Wikidata:Requests_for_comment/How_to_classify_items:_lots_of_specific_type_properties_or_a_few_generic_ones%3F&oldid=49339875#Discussion_2 . USS Carl Vinson (CVN-70) is an instance of (P31) Nimitz-class aircraft carrier. Nimitz-class aircraft carrier in turn is an instance of ship class. In such cases (or analogous), the following algorithm should work. In a template such as {{Infobox ship}}: 1. Take L as the list of items the page (ship) is an instance of. 2. For every member x in L, check if x is an instance of ship class (Q559026). If so, display it in the ship class field. Step 1 can be done now, but 2 requires a fix to this bug.
To be more concrete about this, I'd like mw.wikibase.lua to have a getEntity overload (or another method also returning an item) that accepted an arbitrary ID (Q123). Libraries on top of that can be done on-wiki.
Another use case, as explained at http://www.wikidata.org/wiki/Help_talk:Lua Provide localization and links to articles for all flag icons in all languages, based on single English table: http://en.wikipedia.org/wiki/Module:Sandbox/QuimGil/FlagTranslations I'm working on a Lua based template that already would save hundreds of subtemplates to every Wikipedia. If it would also save the work of maintaining all the local translations for all languages that would be amazing. Wikidata has already all this data in place. It's "just" a matter of leveraging it.
Trying to summarize a discussion we had internally about this a few weeks ago (from memory, please correct me if I got something wrong): Tracking on clients: * have a table mapping local pages <---> entity IDs * ...should track both implicit and explicit item usage * ...should track property usage * ...should track indirect item usage (labels) * this needs to be updated whenever the page is edited * ...and when the page is moved (for implicit item usage) or deleted * ...and when any of the referenced items change (for implicit item usage, and indirect/label usage) * the tracking table is expected to be roughly as big as the pagelinks table Tracking on the repo: * tracking table saying which client wiki uses which entities (but not where) * the information in that table is derived from the client side tables: * when the client side tracking table is updated, we need to note which entities were used before, and which are used after * then we can update the repo side tracking table accordingly So, the flow of information is: * client edit: client tracking table -> repo tracking table * repo edit: repo change -> client change handler -> client page update -> client tracking table -> repo tracking table
Use case: We have an article on "Bonnie and Clyde" on Wikipedia. We want it to have two infoboxes, importing data from the Wikidata pages for 'Bonnie Parker" and for "Clyde Barrow". Use case: We have a wikivoyage page for an area. It has datacards for three museums, two hotels, four bars, each of which has a wikidata item separate from the wikidata item linked to the current page. We want to import the info for these datacards into this page.
*** Bug 49805 has been marked as a duplicate of this bug. ***
Additional Use Case: The labels may be used for Internationlisattion in Commons. On pages like https://commons.wikimedia.org/wiki/Acrocephalus Acrocephalus and https://commons.wikimedia.org/wiki/Acrocephalidae Acrocephalidae the labels corresponding to https://commons.wikimedia.org/wiki/Acrocephalus_aequinoctialis Acrocephalus aequinoctialis : https://www.wikidata.org/wiki/Q1585161 on wikidata may be used to internationalice the bird name.
Here's the break-down of this task from the backlog page: 1. create Subscription table on the repo 2. create EntityUsage table on the client 3. populate Subscription table on the repo 4. populate EntityUsage table on the client 5. update Subscription table on the repo 6. (#47288) update EntityUsage table on the client 7. use Subscriptions table to push changes to the right clients from the repo 8. use EntityUsage table to deploy the changes on the client 9. allow arbitrary access
Two use cases (which I hope will be possible after this is fixed): 1) https://www.wikidata.org/wiki/Q1278115 for "Fort Ross". Commons category https://commons.wikimedia.org/wiki/Category:Fort_Ross needs access to Q1278115's properties. I hope that I will be able to access them if I know the Q code once this bug is fixed. Ideally there would be a way to look up the properties without the Q code, for example Commons Category:Albert Einstein -> Q7213562 -> P301 -> Q937 and its properties. 2) https://commons.wikimedia.org/wiki/Creator:Albert_Einstein has the wikidata Q937 code, but if missing than I should be able to access the Q937 properties, because each Creator page is associated with a category so I should be able to follow the trail from category to article Q code outlined above. Once that is a possibility it will be imbedded in templates/modules and used a lot. Or is there a better way?
> Or is there a better way? Ideally, Albert Einstein should be the same item as Category:Albert Einstein, Template:Albert Einstein, Creator:Albert Einstein, Wikipedia:Albert Einstein etc. In other words, one item should be able to link to many different namespaces in each language/project. The developer team has, as far as I understand, acknowledged that something like this would be a good idea, but I don't know when or if it will be implemented. It is a huge change, technically. See https://www.wikidata.org/wiki/Wikidata:Requests_for_comment/Commons_links
(In reply to soulkeeper.wikipedia from comment #11) > In other words, one item should be able to > link to many different namespaces in each language/project. That would be a better solution and we probably would need a different bug report for it. Software would then either show a link to only one page per project or to all while somehow indicating if page is in a different namespace. This would really simplify how to handle properties associated with same subject at many namespaces.
*** Bug 58856 has been marked as a duplicate of this bug. ***
Change 144965 had a related patch set uploaded by Hoo man: Lua: Allow arbitrary item access https://gerrit.wikimedia.org/r/144965
Why is this bug depends on 44946 and 68029? Doesn't look like real dependency for me.
(In reply to Sergey Vladimirov from comment #15) > Why is this bug depends on 44946 and 68029? Doesn't look like real > dependency for me. +1, it seems unrelated.
