Lucas_Werkmeister_WMDE added a comment.
In T305535#7847385 <https://phabricator.wikimedia.org/T305535#7847385>, @ItamarWMDE wrote: > Right, I agree that it shouldn't be re-computed by the consumer, but after a short discussion with @WMDE-leszek I realized that this "best rank" is not core to the data model <https://www.mediawiki.org/wiki/Wikibase/DataModel#Ranks_of_Statements> that we keep referring to, it is derived from it though in the paragraphs below it. This feels like an artificial distinction to me. It’s part of the data model, and as Lydia said it’s an important concept; why is this “core” subset of the data model so important now? > I think we can, however, add a union to the parameter to indicate that we want both ranks and ask to order them by the rank, so that all a re-user has to do is use the top of the list returned by the response from: `rank=preferred|normal&orderby=rank`. In my opinion, this is the best way to avoid delegating this sifting logic to the client, while maintaining the flexibility and simplicity that the data model affords as it is currently defined. IMO I don't think we have to worry about consumers potentially requesting other ranks of statements since we currently allow them to do so, and giving re-users the opportunity to request statements beyond `best-ranked` will allow them to create their own interpretations of the data model. For instance, just off the top of my mind, an application that compares the top two or three statements returned from `rank=preferred|normal&orderby=rank` to determine which one is truly the "best ranked". To me this doesn’t address what I wrote before: > When I get a list of best statements, I expect that they’re all equivalent, and I don’t have to look at the rank anymore. In my opinion, any solution here that still requires me to look at the rank adds very little value, regardless of what order the API returns statements in. If the API can return preferred-rank and normal-rank statements together, then that’s not best-rank statements, and I still need to implement the logic on my side. --- In T305535#7847432 <https://phabricator.wikimedia.org/T305535#7847432>, @ItamarWMDE wrote: > To add to that, if network overhead is truly a concern, then I don't think we should shy away from adding another http api layer (I suppose it would be a module, if we speak in action api terms) to really just get "the one" best ranked statement. But I don't really know if there's a sufficient business case for it in terms of product. I was actually starting to think the same thing: a new `wbgetbeststatements` action could also be an option. (Or `wbgetbestclaims` for consistency, though IMHO we should stop saying “claims” when we really mean “statements”. Claims are main snak + qualifiers, statements are claim + references; both APIs return full statements, not just the claim part.) TASK DETAIL https://phabricator.wikimedia.org/T305535 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Lucas_Werkmeister_WMDE Cc: Addshore, WMDE-leszek, Lydia_Pintscher, Aklapper, Nikki, Mahir256, Bugreporter, Erdinc_Ciftci_WMDE, guergana.tzatchkova, ItamarWMDE, noarave, Michael, Lucas_Werkmeister_WMDE, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, Akuckartz, Nandana, lucamauri, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Bodhisattwa, Scott_WUaS, Wikidata-bugs, aude, Mbch331
_______________________________________________ Wikidata-bugs mailing list -- [email protected] To unsubscribe send an email to [email protected]
