[Wikidata-bugs] [Maniphest] [Changed CC] T62369: Make in other language box configurable
Nemo_bis added a subscriber: Nemo_bis. Nemo_bis added a comment. This is about the repo only, right? That is, https://phabricator.wikimedia.org/T41190 TASK DETAIL https://phabricator.wikimedia.org/T62369 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nemo_bis Cc: Lydia_Pintscher, siebrand, Amire80, deryckchan, Snaterlicious, adrianheine, thiemowmde, Nemo_bis, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed CC] T86191: Give user indication how to influence preferred language selection
Nemo_bis added a subscriber: Nemo_bis. Nemo_bis added a comment. Is this about the languages shown on Wikidata items for labels and descriptions, AKA https://phabricator.wikimedia.org/T56734? TASK DETAIL https://phabricator.wikimedia.org/T86191 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nemo_bis Cc: Aklapper, Lydia_Pintscher, siebrand, Amire80, deryckchan, Snaterlicious, adrianheine, thiemowmde, Tobi_WMDE_SW, Nemo_bis, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T62369: Make in other language box configurable
Lydia_Pintscher added a comment. It is about the repository. TASK DETAIL https://phabricator.wikimedia.org/T62369 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Lydia_Pintscher Cc: Lydia_Pintscher, siebrand, Amire80, deryckchan, Snaterlicious, adrianheine, thiemowmde, Nemo_bis, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T62369: Make in other language box configurable
Nemo_bis edited the task description. TASK DETAIL https://phabricator.wikimedia.org/T62369 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nemo_bis Cc: Lydia_Pintscher, siebrand, Amire80, deryckchan, Snaterlicious, adrianheine, thiemowmde, Nemo_bis, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T86278: Define which data the query service would store
Multichill added a comment. I would like to turn it around. We should support indexing everything: - Labels - Aliases - Descriptions - Sitelinks - Including badges - Statements - Including ranks etc - Including qualifiers - Including references (probably forgot something) We should have a good reason to not index something. The fact that we're not creative enough to make up queries for everything doesn't mean it isn't useful. TASK DETAIL https://phabricator.wikimedia.org/T86278 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Smalyshev, Multichill Cc: Aklapper, Smalyshev, Lydia_Pintscher, Multichill, Magnus, daniel, JeroenDeDauw, JanZerebecki, aude, mkroetzsch, Denny, Sjoerddebruin, Tobi_WMDE_SW, jkroll, Wikidata-bugs, GWicke, Manybubbles ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T85347: Automatically drop redundant sitelink to redirect when merging in wbmergeitems api module
Multichill added a comment. All sounds good! Should make it easier to clean up duplicates/Wikipedia article merges. TASK DETAIL https://phabricator.wikimedia.org/T85347 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Multichill Cc: Aklapper, petr.matas, hoo, daniel, Lydia_Pintscher, Addshore, Multichill, Sjoerddebruin, Legoktm, matej_suchanek, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Project Column] T86453: Cannot add url values as an anonymous or unconfirmed user
Lydia_Pintscher moved this task to consider for next sprint on the Wikidata workboard. TASK DETAIL https://phabricator.wikimedia.org/T86453 WORKBOARD https://phabricator.wikimedia.org/project/board/71/ REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Lydia_Pintscher Cc: Aklapper, aude, tstarling, Wikidata-bugs ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Triaged] T86453: Cannot add url values as an anonymous or unconfirmed user
Lydia_Pintscher triaged this task as High priority. Lydia_Pintscher added a subscriber: tstarling. TASK DETAIL https://phabricator.wikimedia.org/T86453 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Lydia_Pintscher Cc: Aklapper, aude, tstarling, Wikidata-bugs ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T86191: Give user indication how to influence preferred language selection
Nemo_bis edited the task description. Nemo_bis set Security to none. TASK DETAIL https://phabricator.wikimedia.org/T86191 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nemo_bis Cc: Aklapper, Lydia_Pintscher, siebrand, Amire80, deryckchan, Snaterlicious, adrianheine, thiemowmde, Tobi_WMDE_SW, Nemo_bis, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T85347: Automatically drop redundant sitelink to redirect when merging in wbmergeitems api module
Addshore added a comment. So the bit of code we would need to touch is this method https://github.com/wikimedia/mediawiki-extensions-Wikibase/blob/master/repo/includes/ChangeOp/ChangeOpsMerge.php#L199 I guess it would be, If there are conflicts for a site then find the actual final target of both sitelinks (the one we are trying to add and the one already there). If both targets match then remove both sitelinks from both items and add the final target (Thus also resolving redirects) TASK DETAIL https://phabricator.wikimedia.org/T85347 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Addshore Cc: Aklapper, petr.matas, hoo, daniel, Lydia_Pintscher, Addshore, Multichill, Sjoerddebruin, Legoktm, matej_suchanek, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T86278: Define which data the query service would store
mkroetzsch added a comment. In https://phabricator.wikimedia.org/T86278#969184, @Multichill wrote: I would like to turn it around. We should support indexing everything: ... The fact that we're not creative enough to make up queries for everything doesn't mean it isn't useful. I have to disagree with this approach of designing a (query) system. Of course supporting everything would be nice, but indexing always needs to be viewed in the context of a query language. Depending on the query features you support, indexing may mean completely different things. The requirement that everything should be indexed is fuzzy and vague. For example, Wikidata Query supports regular path queries (in Wikidata, Kleene-star recursion is accessed with an operator called TREE). When you say that references should be indexed, do you mean that it should be possible to navigate through references within regular path expressions? How about qualifiers? I think Wikidata query only supports TREE in the main statements. On the other hand, Wikidata query does not support any kind of cyclic queries (Find people whose parents are married to each other.) even though the relevant data is indexed. The point is that you need adequate index structures for each query feature. You may have indexed everything and still not be able to do the queries you want. Moreover, I am creative enough to come up with queries that would be very hard to implement, yet this does not mean that we should do it. Both everything and everything we are creative enough for are poor design principles. So how to move forward? The usual approach to design a practical system is to collect use cases and requirements (example queries) and then make a clear decision what should be supported and what shouldn't. One can always revise this decision later, but it's still much better to make it explicit than to just go along and see what we get. In all of this, it must be understood that supporting everything is an impossible task. The question is merely where to draw the line(s). TASK DETAIL https://phabricator.wikimedia.org/T86278 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Smalyshev, mkroetzsch Cc: Aklapper, Smalyshev, Lydia_Pintscher, Multichill, Magnus, daniel, JeroenDeDauw, JanZerebecki, aude, mkroetzsch, Denny, Sjoerddebruin, Tobi_WMDE_SW, jkroll, Wikidata-bugs, GWicke, Manybubbles ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T86439: Create new item from client js does use no-lang tag
hoo added a comment. Mh... I thought we automatically fix that (server side) on some level... didn't we at some point? I'm not sure whether this should be solved in JavaScript. TASK DETAIL https://phabricator.wikimedia.org/T86439 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: hoo Cc: Aklapper, jeblad, hoo, thiemowmde, JanZerebecki, adrianheine, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T86278: Define which data the query service would store
JanZerebecki added a comment. I understood indexing everything to mean that at least support answering a query for it with an exact value and traversing to things it is connected to without iterating over anything else. (Technically for Titan a composite index over one key, see http://s3.thinkaurelius.com/docs/titan/current/indexes.html#_composite_index .) I.e. support finding badges Featured Article and also support traversing to the site link one is connected to and then which item that is connected to. So this does not imply any fancy indices (like over functions) nor even full text, prefix or range indices. Does it sound OK to have this as a baseline? If there are no other indices that means e.g. that we can answer Find people whose parents are married to each other. only by looking at every human that is married (which so far is indexed by exact value for each of the lookups on its own; i.e. no combined index for married humans) and then traversing to their children where both parents are in the previous set of humans (which is AFAIK currently not helped by any index). A question about qualifiers: currently if there are two qualifiers with the same property on the same statement, it will be split when importing into Titan like as if it were two statements, is this something that is acceptable or should we correct this now? TASK DETAIL https://phabricator.wikimedia.org/T86278 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Smalyshev, JanZerebecki Cc: Aklapper, Smalyshev, Lydia_Pintscher, Multichill, Magnus, daniel, JeroenDeDauw, JanZerebecki, aude, mkroetzsch, Denny, Sjoerddebruin, Tobi_WMDE_SW, jkroll, Wikidata-bugs, GWicke, Manybubbles ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Reopened] T85407: improve dump documentation
hoo reopened this task as Open. hoo added a comment. Given that people end up on IRC asking basic questions about the json dumps, I guess we need a bit more here: Link the dump documentation page more prominently (Main page? Sidebar? Footer?) and shortly explain how the dumps look like (json list, one entity per line, entities look like https://www.wikidata.org/wiki/Special:EntityData/Q183.xml). TASK DETAIL https://phabricator.wikimedia.org/T85407 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Lucie, hoo Cc: Aklapper, Lydia_Pintscher, hoo, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T86278: Define which data the query service would store
Smalyshev added a comment. **This changes the structure, and the original structure is no longer represented and can no longer be faithfully recovered.** This is not correct, original structure can be recovered, though I see no reason why would you want to do so. Can you name one? **a mere 40 qualifiers (20 properties, each with two values) on one forged statement, I could create a million statements in your index -- a possible DOS attack vector** Scan of the database shows there are no entries generating more than 15 qualifier splits (at least I couldn't find any a month ago). If it ever becomes a problem, we could easily institute limits, but I think vandalism is better handled on other levels than changing our data model to avoid vandals. I see no case where 20 duplicate qualifiers would legitimately be required - duplicate qualifier is usually a wrong way to represent the claim, since it essentially claims that the same event happened in two places, two times, etc. - which usually means what should there be is two separate claims, as event happening two times is two different instances of the event. So I would claim even most existing duplicates look like data errors. TASK DETAIL https://phabricator.wikimedia.org/T86278 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Smalyshev Cc: Aklapper, Smalyshev, Lydia_Pintscher, Multichill, Magnus, daniel, JeroenDeDauw, JanZerebecki, aude, mkroetzsch, Denny, Sjoerddebruin, Tobi_WMDE_SW, jkroll, Wikidata-bugs, GWicke, Manybubbles ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T86278: Define which data the query service would store
Smalyshev added a comment. **This changes the structure, and the original structure is no longer represented and can no longer be faithfully recovered.** This is not correct, original structure can be recovered, though I see no reason why would you want to do so. Can you name one? **a mere 40 qualifiers (20 properties, each with two values) on one forged statement, I could create a million statements in your index -- a possible DOS attack vector** Scan of the database shows there are no entries generating more than 15 qualifier splits (at least I couldn't find any a month ago). If it ever becomes a problem, we could easily institute limits, but I think vandalism is better handled on other levels than changing our data model to avoid vandals. I see no case where 20 duplicate qualifiers would legitimately be required - duplicate qualifier is usually a wrong way to represent the claim, since it essentially claims that the same event happened in two places, two times, etc. - which usually means what should there be is two separate claims, as event happening two times is two different instances of the event. So I would claim even most existing duplicates look like data errors. TASK DETAIL https://phabricator.wikimedia.org/T86278 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Smalyshev Cc: Aklapper, Smalyshev, Lydia_Pintscher, Multichill, Magnus, daniel, JeroenDeDauw, JanZerebecki, aude, mkroetzsch, Denny, Sjoerddebruin, Tobi_WMDE_SW, jkroll, Wikidata-bugs, GWicke, Manybubbles ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T86278: Define which data the query service would store
mkroetzsch added a comment. @Smalyshev My suggestion was just about the surface appearance, not about the inner workings. I am saying that the following two phrases have the same structure: - Find things with a *sitelink* that *has badge* *featured*. - Find things with a *population* that has *point in time* *2014*. If you look at it like this, you use badge like a (special) qualifier property and featured like a value. This does not mean that the query answering will be any less efficient than with another syntax. The query engine would easily parse the queries in any case, without ambiguity, and know that sitelinks are (possibly) stored in a different way internally. Same for labels. The reason I was suggesting this unification here was that it also somehow answers the question what do we mean by 'indexing' this data?: any query that would work over statements would also be expected to work for sitelinks, even if different structures are used internally. TASK DETAIL https://phabricator.wikimedia.org/T86278 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Smalyshev, mkroetzsch Cc: Aklapper, Smalyshev, Lydia_Pintscher, Multichill, Magnus, daniel, JeroenDeDauw, JanZerebecki, aude, mkroetzsch, Denny, Sjoerddebruin, Tobi_WMDE_SW, jkroll, Wikidata-bugs, GWicke, Manybubbles ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T86278: Define which data the query service would store
Smalyshev added a comment. @mkroetzsch the issue is that //point in time// is an official property in wikidata, which can be looked up and associated with property //P585//. However, //has badge// is not a property and as such can not be expressed in these terms. Of course, we can make a language that would have some logic - either database-backed or just whitelist-based - that would identify that //has badge// is a special case and create special translation for it. That would complicate the engine, but it's not the main issue. I wonder if it is really what the expectations of the users would be. After all, we display links and badges in different form than claims in the main wikidata UI - wouldn't the users of the same UI expect different handling of the sitelinks and badges in the query API too? **any query that would work over statements would also be expected to work for sitelinks** I'm not sure we want to make that claim, because I don't think it is true. The data model is different for sitelinks as opposed to claims - claims have values, qualifiers and references, while sitelinks have badges. In fact, there's very little in common between the two of them except for the fact that they are both attached to items. So I am concerned that claiming that would be rather confusing. TASK DETAIL https://phabricator.wikimedia.org/T86278 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Smalyshev Cc: Aklapper, Smalyshev, Lydia_Pintscher, Multichill, Magnus, daniel, JeroenDeDauw, JanZerebecki, aude, mkroetzsch, Denny, Sjoerddebruin, Tobi_WMDE_SW, jkroll, Wikidata-bugs, GWicke, Manybubbles ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T86278: Define which data the query service would store
mkroetzsch added a comment. This is not correct, original structure can be recovered Then I misunderstood the transformation that was proposed. My impression was that a statement with three qualifier snaks: P1 V1, P1 V2, https://phabricator.wikimedia.org/P2 V3 would be stored as two statements, one with qualifiers P1 V1, https://phabricator.wikimedia.org/P2 V3, and one with qualifiers P1 V2, https://phabricator.wikimedia.org/P2 V3. In this case, one would not be able to distinguish this from the case where two statements with two qualifiers each had been given originally. Could you explain what kind of transformation you had in mind? Scan of the database shows there are no entries generating more than 15 qualifier splits My point was that an attacker could craft a single statement that makes you index millions of statements. It's clear that such statements are not in the current data, since they are hopefully not needed. Again this depends on my (possibly incorrect) understanding of your intended transformation. TASK DETAIL https://phabricator.wikimedia.org/T86278 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Smalyshev, mkroetzsch Cc: Aklapper, Smalyshev, Lydia_Pintscher, Multichill, Magnus, daniel, JeroenDeDauw, JanZerebecki, aude, mkroetzsch, Denny, Sjoerddebruin, Tobi_WMDE_SW, jkroll, Wikidata-bugs, GWicke, Manybubbles ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T86278: Define which data the query service would store
mkroetzsch added a comment. @JanZerebecki I understand what you are saying about what indexing means here. Makes sense to me. What you are saying about my example query sounds as if you are planning to implement query execution manually. I hope this is not the case and you can just give the query to Titan to get it answered for you. You mentioned splitting certain statements with duplicate qualifiers. This changes the structure, and the original structure is no longer represented and can no longer be faithfully recovered. I don't know if this is an issue with the current data (which duplicate qualifiers are actually used?) but it is an issue in general. It also means that with a mere 40 qualifiers (20 properties, each with two values) on one forged statement, I could create a million statements in your index -- a possible DOS attack vector? An alternative technique for handling such cases is to use a special encoding for overflowing values. This is done successfully in some database implementations, but it may mean additional checks during query answering, and depending on how low in the query answering process you can do these checks, they may or may not add significant cost (hence it's a pity that Titan does not support this efficiently out of the box). TASK DETAIL https://phabricator.wikimedia.org/T86278 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Smalyshev, mkroetzsch Cc: Aklapper, Smalyshev, Lydia_Pintscher, Multichill, Magnus, daniel, JeroenDeDauw, JanZerebecki, aude, mkroetzsch, Denny, Sjoerddebruin, Tobi_WMDE_SW, jkroll, Wikidata-bugs, GWicke, Manybubbles ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T85347: Automatically drop redundant sitelink to redirect when merging in wbmergeitems api module
petr.matas added a comment. In https://phabricator.wikimedia.org/T85347#969150, @Addshore wrote: I guess it would be, If there are conflicts for a site then find the actual final target of both sitelinks (the one we are trying to add and the one already there). If both targets match then remove both sitelinks from both items and add the final target (Thus also resolving redirects) This is too strong in my oppinion. Suppose that you are trying to merge the following items: - Bonnie (Q1) with sitelink [[en:Bonnie]], which is redirect to [[Bonnie and Clyde]] - Clyde (Q2) with sitelink [[en:Clyde]], which is also a redirect to [[Bonnie and Clyde]] Although the final targets are identical, neither of the redirect chains passes through the other sitelink. This indicates that Bonnie (Q1) and Clyde (Q2) may be different concepts and they should not be merged. TASK DETAIL https://phabricator.wikimedia.org/T85347 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: petr.matas Cc: Aklapper, petr.matas, hoo, daniel, Lydia_Pintscher, Addshore, Multichill, Sjoerddebruin, Legoktm, matej_suchanek, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T86278: Define which data the query service would store
mkroetzsch added a comment. @Smalyshev My point is merely that sitelinks and labels //can// be handled like statements. Since statements must be supported anyway, it would be sensible to reuse the data structures and query expressions defined for them. I don't think that confusion is likely, since the query language will not use the colloquial names as my examples. Properties of Wikidata will always be referred to by their Pid, whereas something like has badge would not have an id of this form. So it's not like having a reserved label has badge that competes with Wikidata property labels. Structurally, however, statements and sitelinks can all be represented in the same data structure as far as querying is concerned. Maybe you would like it better if you viewed it as a separate, independent data structure qualified triple that we would use to represent statements, sitelinks, and labels? There is no conceptual mix-up between the high-level terms here, just taking advantage of similar structure at a low level. If you look at common query languages like SQL, SPARQL, Cypher, etc. then you can see that they are always based on a relatively small set of structural primitives that do not have a domain-specific meaning. You can always build UIs that use domain specific terms like sitelink and that make them appear separate, but for implementers and API users it is very useful if some things can be unified. TASK DETAIL https://phabricator.wikimedia.org/T86278 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Smalyshev, mkroetzsch Cc: Aklapper, Smalyshev, Lydia_Pintscher, Multichill, Magnus, daniel, JeroenDeDauw, JanZerebecki, aude, mkroetzsch, Denny, Sjoerddebruin, Tobi_WMDE_SW, jkroll, Wikidata-bugs, GWicke, Manybubbles ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed CC] T46874: Full support for wikibase edits in enhanced changes format (Group changes by page in recent changes and watchlist [usenewrc])
Liuxinyu970226 added a subscriber: Liuxinyu970226. TASK DETAIL https://phabricator.wikimedia.org/T46874 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Liuxinyu970226 Cc: Tgr, Ltrlg, Jdforrester-WMF, He7d3r, Lydia_Pintscher, Tobi_WMDE_SW, Schnark, liangent, Abraham, Raymond, Nemo_bis, matmarex, aude, Liuxinyu970226, Wikidata-bugs ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed CC] T76232: nudge when editing a statement to check reference
Liuxinyu970226 added a subscriber: Liuxinyu970226. TASK DETAIL https://phabricator.wikimedia.org/T76232 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Liuxinyu970226 Cc: Lydia_Pintscher, Snaterlicious, adrianheine, thiemowmde, Liuxinyu970226, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed CC] T50143: Implement complete RDF mapping for entities (tracking)
Liuxinyu970226 added a subscriber: Liuxinyu970226. TASK DETAIL https://phabricator.wikimedia.org/T50143 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Liuxinyu970226 Cc: adrianheine, Lydia_Pintscher, daniel, jayvdb, Wikidata-bugs, Liuxinyu970226, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed CC] T986: Use structured data on Wiktionary
Liuxinyu970226 added a subscriber: Liuxinyu970226. TASK DETAIL https://phabricator.wikimedia.org/T986 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Liuxinyu970226 Cc: GPHemsley, Gilles, JanZerebecki, Ricordisamoa, Liuxinyu970226, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed CC] T67626: support for complex queries
Liuxinyu970226 added a subscriber: Liuxinyu970226. TASK DETAIL https://phabricator.wikimedia.org/T67626 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Liuxinyu970226 Cc: Eloquence, Lydia_Pintscher, -jem-, Zellfaze, Liuxinyu970226, jkroll, Smalyshev, Wikidata-bugs, aude, GWicke, Manybubbles, daniel ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed CC] T42358: Wikidata changes in article history
Liuxinyu970226 added a subscriber: Liuxinyu970226. TASK DETAIL https://phabricator.wikimedia.org/T42358 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Liuxinyu970226 Cc: Tgr, Arkanosis, Lydia_Pintscher, Ainali, Stryn, matmarex, jeblad, SPQRobin, matej_suchanek, aude, Wikidata-bugs, SJu, KTC, Denny, Liuxinyu970226 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed CC] T57549: Add support for geoshapes as a datatype
Liuxinyu970226 added a subscriber: Liuxinyu970226. TASK DETAIL https://phabricator.wikimedia.org/T57549 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Liuxinyu970226 Cc: Rschen7754, Lydia_Pintscher, Ainali, Tobias1984, aude, Wikidata-bugs, Liuxinyu970226 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed CC] T59589: make it possible to show the + sign in quantities on item pages
Liuxinyu970226 added a subscriber: Liuxinyu970226. TASK DETAIL https://phabricator.wikimedia.org/T59589 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Liuxinyu970226 Cc: Lydia_Pintscher, Tobi_WMDE_SW, daniel, Micru, Wikidata-bugs, Liuxinyu970226, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T86278: Define which data the query service would store
Smalyshev added a comment. In this case, one would not be able to distinguish this from the case where two statements with two qualifiers each had been given originally It is possible to distinguish them since claim IDs are recorded too for bookkeeping, so the split claim would have same IDs while different claims would have different IDs. I'm still not sure why this distinction is important though. My point was that an attacker could craft a single statement that makes you index millions of statements. It is easy to introduce limits if this would be of any concern. Since our data does not have any large numbers, limiting expansion factor by, say, 50 or so would not impact the system and would prevent such problems. TASK DETAIL https://phabricator.wikimedia.org/T86278 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Smalyshev Cc: Aklapper, Smalyshev, Lydia_Pintscher, Multichill, Magnus, daniel, JeroenDeDauw, JanZerebecki, aude, mkroetzsch, Denny, Sjoerddebruin, Tobi_WMDE_SW, jkroll, Wikidata-bugs, GWicke, Manybubbles ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed CC] T76231: nudge editors to add a reference when adding a new claim
Liuxinyu970226 added a subscriber: Liuxinyu970226. TASK DETAIL https://phabricator.wikimedia.org/T76231 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Liuxinyu970226 Cc: Lydia_Pintscher, Snaterlicious, thiemowmde, adrianheine, Liuxinyu970226, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed CC] T49288: track entity usage on client pages
Liuxinyu970226 added a subscriber: Liuxinyu970226. TASK DETAIL https://phabricator.wikimedia.org/T49288 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Liuxinyu970226 Cc: Eloquence, Legoktm, hoo, Lydia_Pintscher, Tobi_WMDE_SW, Ainali, liangent, Abraham, zhuyifei1999, daniel, Sannita, Ricordisamoa, MZMcBride, jayvdb, Micru, Daniel_Mietchen, Wikidata-bugs, greg, Liuxinyu970226, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed CC] T68108: Store media information for files on Wikimedia Commons as structured data
Liuxinyu970226 added a subscriber: Liuxinyu970226. TASK DETAIL https://phabricator.wikimedia.org/T68108 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Liuxinyu970226 Cc: Tgr, JeanFred, Jdforrester-WMF, Legoktm, MarkTraceur, JohnLewis, Fabrice_Florin, Steinsplitter, Stryn, Gilles, Lydia_Pintscher, jeremyb, Bene, Lokal_Profil, jayvdb, Petrb, Dereckson, Snowolf, Ltrlg, He7d3r, Tobi_WMDE_SW, Ainali, Kelson, Nemo_bis, daniel, Multichill, Ricordisamoa, Micru, Bawolff, GPHemsley, JeroenDeDauw, Rillke, JanZerebecki, Revi, Keegan, Liuxinyu970226, Wikidata-bugs, aude, Aklapper ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed CC] T76229: create demo infoboxes
Liuxinyu970226 added a subscriber: Liuxinyu970226. TASK DETAIL https://phabricator.wikimedia.org/T76229 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Liuxinyu970226 Cc: Lydia_Pintscher, hoo, Snipre, Liuxinyu970226, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed CC] T69434: make hover cards work on item links
Liuxinyu970226 added a subscriber: Liuxinyu970226. TASK DETAIL https://phabricator.wikimedia.org/T69434 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Liuxinyu970226 Cc: Jdforrester-WMF, Lydia_Pintscher, hoo, Prtksxna, Vibhabamba, Wikidata-bugs, Liuxinyu970226, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Closed] T86134: Autolist keeps dying
yuvipanda closed this task as Resolved. yuvipanda claimed this task. yuvipanda added a comment. Yup, closing as fixed now. TASK DETAIL https://phabricator.wikimedia.org/T86134 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: yuvipanda Cc: Aklapper, yuvipanda, Lydia_Pintscher, Sjoerddebruin, scfc, GerardM, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
