Page MenuHomePhabricator

[RfC] PageTerms API module should work on entity pages and connected pages on a wiki with repo and client functionality enabled.
Open, MediumPublic

Description

Currently, we support prop=pageterms only on the repo, for connected page. We want the same functionality also on the repo, for entity pages. And for wikis with both client and repo functionality, it should work for both, entity pages as well as connected pages.

Event Timeline

daniel created this task.Oct 9 2015, 3:23 PM
daniel raised the priority of this task from to Needs Triage.
daniel updated the task description. (Show Details)
daniel added a project: Wikidata.
daniel added a subscriber: daniel.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptOct 9 2015, 3:23 PM
JanZerebecki added a subscriber: JanZerebecki.EditedOct 12 2015, 1:10 PM

The hack added in https://gerrit.wikimedia.org/r/#/c/244698/ will do this, but it should be replaced by a non hack.

There are open conceptional issues with doing this in a proper way. Let's create a separate ticket once we figured out how to solve it.

Tobi_WMDE_SW renamed this task from PageTerms API module should work on entity pages and connected pages on a wiki with repo and client functionality enabled. to [RfC] PageTerms API module should work on entity pages and connected pages on a wiki with repo and client functionality enabled..Nov 3 2015, 1:59 PM
Tobi_WMDE_SW added a project: Proposal.
Restricted Application added a subscriber: StudiesWorld. · View Herald TranscriptNov 18 2015, 11:41 AM

Notes from today's story time:

  • API allows to ask for a description, and uses the connected item for that.
  • Project page on Wikidata can be connected to *one* item, which links to *one* connected page on enwiki.
  • Problem arises when a sitelink links to an other item. This item then does have *two* ways of resolving the description API request.
  • Suggestion: Special case only for the item namespace. Items are always exclusively connected to themself and can *not* have sitelinks to other items. Plus disallow sitelinks to the item namespace on the item namespace, then this is consistent.
  • Todo investigation: How many sitelinks link to items on wikidata.org?
  • Next: Find valid use cases and decide based on them.
aude added a subscriber: aude.Nov 25 2015, 1:04 AM

Notes from today's story time:

  • API allows to ask for a description, and uses the connected item for that.
  • Project page on Wikidata can be connected to *one* item, which links to *one* connected page on enwiki.
  • Problem arises when a sitelink links to an other item. This item then does have *two* ways of resolving the description API request.
  • Suggestion: Special case only for the item namespace. Items are always exclusively connected to themself and can *not* have sitelinks to other items. Plus disallow sitelinks to the item namespace on the item namespace, then this is consistent.
  • Todo investigation: How many sitelinks link to items on wikidata.org?

there are no sitelinks to items or properties on wikidata.

the sitelinks to wikidata pages are only for categories (a lot of these babel categories), help pages, lua modules, Special:Recentchanges, templates and project (Wikidata) namespace.

  • Next: Find valid use cases and decide based on them.
Lydia_Pintscher triaged this task as Medium priority.Feb 19 2016, 9:55 AM

I ended up looking into this task as part of T255110 and wondered why this ambiguity should only affect the pageterms API and not the Lua code. But the situation there is slightly different; rather than pageterms’ “give me the terms for this page/title”, Lua has different functions:

  • “give me the terms for this Entity ID” (getLabel, getDescriptionWithLang etc.)
  • “give me the Entity ID for this page/title” (getEntityIdForTitle)
  • “give me the terms for the current page” (getLabel, getDescriptionWithLang etc. without Entity ID argument)

Only the last one is potentially ambiguous, and if you’re running Lua that looks at the current page, then the current page can’t be an Entity page, since Items, Properties etc. don’t contain wikitext, so it’s never ambiguous (it can only mean “terms of the linked Entity”, because the current page can’t be an Entity).

…Unless you use the action=parse API, specify the title of an Entity, but set the contentmodel=wikitext and the text to some wikitext that calls a Lua module. Then you can ask for the terms of the current Item page, and the API will return the terms of the Item linked to that Item (rather than, like pageterms with the hack mentioned in T115117#1719166, the terms of the Item you specified in the title).

And also, the “Entity pages don’t contain wikitext” assumption is in fact violated by WikibaseMediaInfo. For the pageterms API, this was reported at T215292; I don’t know if anyone has so far tried to use the Lua term functions on File/MediaInfo pages and found+reported unexpected results. (Testing locally, it seems that mw.wikibase.getLabel() never returns a label on a File/MediaInfo page, regardless of whether it’s linked to an item or not.)

Aklapper removed daniel as the assignee of this task.Jun 19 2020, 4:24 PM

This task has been assigned to the same task owner for more than two years. Resetting task assignee due to inactivity, to decrease task cookie-licking and to get a slightly more realistic overview of plans. Please feel free to assign this task to yourself again if you still realistically work or plan to work on this task - it would be welcome!

For tips how to manage individual work in Phabricator (noisy notifications, lists of task, etc.), see https://phabricator.wikimedia.org/T228575#6237124 for available options.
(For the records, two emails were sent to assignee addresses before resetting assignees. See T228575 for more info and for potential feedback. Thanks!)