Lucas_Werkmeister_WMDE added a comment.
In T305535#7847511 <https://phabricator.wikimedia.org/T305535#7847511>, @ItamarWMDE wrote: >> why is this “core” subset of the data model so important now? > > The requirements document states that quite clearly (emphasis mine). > >> "There are **three** possible ranks" > > and > >> "This model is **intentionally left coarse and simple**. The three levels translate to different treatments in data access, UI (e.g., what is displayed by default), and export (one could, e.g., have an export with only the preferred and normal Statements). The ranks may also be useful for protecting Statements from editing (e.g., by protecting only preferred and normal statements). **More fine-grained rankings do not seem to have such a clear interpretation** and would thus increase the UI complexity unnecessarily. Having only two ranks (or no ranks at all), on the other hand, would make it harder to cope with Statements that are not trusted, known to contain wrong claims, or simply unpatrolled (if ranks are used for protection)." > > For all I can see you can replace UI with any interface for that matter, users are users no matter what interface they choose to access the program's data and models with. I think we need to distinguish here between the ranks a statement can have, and how you can filter statements by rank. This task isn’t proposing to add a new rank that a statement can actually have (there are such proposals in the community, including also T210961 <https://phabricator.wikimedia.org/T210961>, but as far as I’m aware none of the proposed ranks are intended to be truthy / included in best-rank, so I would leave them aside here). But when it comes to filtering statements by rank, best-rank is a useful concept, and it’s part of the data model too. In fact I would argue it’s more useful than filtering by any single rank value (or list of rank values): in Lua, we have `getBestStatements()` and `getAllStatements()`, but `getAllStatements()` doesn’t have a rank filter, so best-rank filtering is the only kind of rank filter we make easy. > What do you mean by "requires me to look at the rank"? In the ordered solution, you don't really have to look at the rank if you're only interested in "one" preferred statement (which is the actual implementation requirement that brought us to this point), if you mean "know about rank" in general, then neither solution applies, and we should really just go with this additional API layer. But there’s a difference between //expecting// only a single best-rank statement (while still being able to detect other best-rank statements, to flag such cases as unexpected, e.g. putting them in a maintenance category: that’s why Module:Statement <https://commons.wikimedia.org/wiki/Module:Statement> returns a `hasOther` flag), and always picking the first best-rank statement regardless of whether any others exist. Also, there are plenty of use cases for multiple best-rank statements too, even if that’s not what we happen to need in T298142 <https://phabricator.wikimedia.org/T298142>. All the other best-rank interfaces we provide that I’m aware of – in Lua and RDF – produce a list of best-rank statements, not a single one. > The value I emphasize here is complexity, or to be more exact, maintainability and understandability of that particular client system and context, as well as that of the HTTP API. I think it’s likely that adding support for filtering by multiple ranks, and then also sorting by rank, actually adds //more// complexity to the system than returning best-rank statements (which we already have code for: `StatementList::getBestStatements()`). 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 -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
