| thiemowmde added a project: MediaWiki-extensions-WikibaseClient. thiemowmde moved this task from incoming to needs discussion or investigation on the Wikidata board. thiemowmde added subscribers: aude, Jonas. thiemowmde added a comment. |
- getAllStatements, both as an independent function (T176124), as well as on Entity objects (T166056).
- Use-case: Maintenance code that intentionally checks all statements, including deprecated.
- It was suggested to specify what the Entity returned by getEntity contains. For example, the user knows he needs only some specific statements, but not all of them. He wants to provide a list of these property IDs.
- Use-case: Personally, I believe this is more premature optimization, and better solved with T76156: [Story] mw.wikibase: Use __index to lazy load entity contents.
- It was suggested to have a filter option for the existing getBestStatements that filters out no-value and some-value snaks.
- Use case: Code skipping snaks with no actual value is repeated a lot in community-maintained code. Or they forget this edge-case and stuff breaks when it runs into a no/some-value snak.
- A filter for getBestStatements that only returns statements with a specific reference.
- Use case: When wikis can't decide on a preferred statement, but want to use their own preferred source.
- A boolean entityExists.
- Use case: Currently, I see a lot of code that does if getEntity( … ) then, which is super-expensive for no reason. The cheapest workaround that currently exists is getEntityUrl, but thats awkward to use in an if.
- Some kind of boolean isChildOf or hasParent that recurses a tree up.
- One parameter of the function is a list of properties that describe parent-relations, typically "subclass of" and "instance of". Ideally this should be a list and not only one property, but this does have a huge disadvantage: It's not a linear recursion then, but a tree! Instead of a maximum-depth, the algorithm must enforce a maximum on the number of entities processed.
- The recursion stops when a specific item from a list of possible parents is found. Specifying only one parent item is definitely not enough!
- The recursion also stops when it realizes it runs into a loop, or already processed the maximum number of entities. Personally, I don't think we should allow the user to specify their own maximum. Just decide on a sensible default.
- Use case: Maintenance code that checks if all actors are (if you walk up the tree) properly tagged as "actor", without the need to list subclasses individually.
- Some kind of recursive getParent that returns the entire parent entity found.
- Use case: In the infobox of a city, I want to display information from the country, e.g. a link to the countries article, and the international dialing code. But cities don't necessarily have the "country" (P17) property. But I know I can traverse "located in the administrative territorial entity" (P131) up and stop at an item that is an "instance of" (P31) "country" (Q6256). As before, I might need to provide multiple parent-relations, as well as multiple conditions to identify a parent.
TASK DETAIL
EMAIL PREFERENCES
To: thiemowmde
Cc: Jonas, aude, hoo, Ladsgroup, Tpt, thiemowmde, eranroz, Aklapper, Lydia_Pintscher, Lahi, Gq86, GoranSMilovanovic, QZanden, Wikidata-bugs, Mbch331
Cc: Jonas, aude, hoo, Ladsgroup, Tpt, thiemowmde, eranroz, Aklapper, Lydia_Pintscher, Lahi, Gq86, GoranSMilovanovic, QZanden, Wikidata-bugs, Mbch331
_______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
