Michael 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. Frankly, this feels a lot like cherry-picking, as you neglected to quote the very next paragraph from DataModel#Ranks_of_Statements <https://www.mediawiki.org/wiki/Wikibase/DataModel#Ranks_of_Statements>: > Another useful concept can be constructed based on the ranks defined above: the "best rank" for the Statements about a given Property with respect to a given Item. If there is at least one Statement with preferred rank about the property (in the context of a given Item), the best rank for that property is preferred. Otherwise, the best rank is normal. Correspondingly, the "best Statements" about a given Property in the context of a given Item are the ones that have the best rank for that Property. You can't just decide that the first two paragraphs a part of some ad hoc "core" of the data-model and the third paragraph is just supplementary and doesn't matter anymore. It has been made clear that the best-rank concept is in practice core to how our data is used and structured. If this wiki page doesn't sufficiently reflect that yet, then, I think, we should adjust the wording on the wiki page instead. In T305535#7847511 <https://phabricator.wikimedia.org/T305535#7847511>, @ItamarWMDE wrote: >> 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. I, as a user of the API, want to get the best rank values for a property from an item, as defined in the data-model. This could explicitly be one or multiple best-ranked values and I already can get this via Lua. Getting a (sorted) list of preferred and normal-ranked statements does not gain me much, as I still have to look at the rank of the statements as I have to figure out which of the values are of preferred rank and which are of normal rank. For this story/subtask we want to get the best-ranked values as defined in the data-model, and then pick the first of it. Getting a (sorted) list of preferred and normal-ranked statements makes things less understandable and hides domain logic instead of making use of it. //Especially// in the action api we should make sure that we are sticking to the domain, //especially// for reasons of understandability. That being said, I don't have a strong opinion yet for whether this should be an extension to `wbgetclaims` or a new `wbgetbeststatements` endpoint or something similar. TASK DETAIL https://phabricator.wikimedia.org/T305535 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Michael 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]
