ItamarWMDE added a comment.
> 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. > In my opinion, any solution here that still requires me to look at the rank adds very little value 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. Also, I'm not sure if it's as subjective as just saying "adds very little value" and having a done deal. Which value are you trying to extract here? In my case, I'd like to bring this task forward, and within the scope of this sprint, as it means that the client (and any future clients we develop) will not have to be responsible for logic that doesn't belong in them (order and filter belong at the API level, and I don't think this is really controversial either). 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. TASK DETAIL https://phabricator.wikimedia.org/T305535 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: ItamarWMDE 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]
