[Wikidata-bugs] [Maniphest] [Commented On] T126152: [RFC] Design of provider/holder interfaces in Wikibase's data model
daniel added a comment. @adrianheine If you want to set a sitelink, the setter should return a new Item? That sounds rather awkward and inefficient. We could re-design the data model to be immutable. It would mean rewriting a lot of code. I don't see that happening. Generally: Manipulating complex data structures efficiently in a purely functional style means using "zippers" of some kind, which as far as I understand need good reference handling, and good memoization. Both would be a pain to do in PHP. TASK DETAIL https://phabricator.wikimedia.org/T126152 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: adrianheine, daniel, JeroenDeDauw, thiemowmde, Aklapper, Bene, StudiesWorld, Izno, Luke081515, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T121361: Proposal: Rework diff list display in watchlists and recent changes
YMS added a subscriber: YMS. YMS added a comment. I regret possibly being too late, but I have to say that I am a huge fan of Yair rand's approach as demonstrated with the DiffLists.js tool. Actually giving diffs in the recent changes lists instead of summaries that don't give a good view on what changed how is helping so much when patrolling them. TASK DETAIL https://phabricator.wikimedia.org/T121361 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: YMS Cc: YMS, Aklapper, Yair_rand, StudiesWorld, Izno, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T67397: [Story] add a new datatype for formulae
Qgil removed a subscriber: Qgil. TASK DETAIL https://phabricator.wikimedia.org/T67397 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Physikerwelt, Qgil Cc: gerritbot, ArthurPSmith, TomT0m, Llyrian, WickieTheViking, Aklapper, MGChecker, Micru, Sannita, Ricordisamoa, Rits, Liuxinyu970226, Tpt, Physikerwelt, Wikidata-bugs, Bene, Tobias1984, Lydia_Pintscher, daniel, Izno, mobrovac, Prod, aude, fredw, Pkra, scfc, Mbch331, Ltrlg ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Closed] T126671: Quantity values are recorded as 0 because of Munger bug
Smalyshev closed this task as "Resolved". TASK DETAIL https://phabricator.wikimedia.org/T126671 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Smalyshev Cc: gerritbot, Aklapper, Smalyshev, debt, Gehel, Izno, jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T90765: Hacking: Make app Wikidata description editable
Qgil removed a subscriber: Qgil. TASK DETAIL https://phabricator.wikimedia.org/T90765 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Qgil Cc: Matanya, Yair_rand, Ainali, Lydia_Pintscher, kaldari, JKatzWMF, Fjalapeno, jeblad, aude, bearND, Tbayer, Rberchie, hoo, Krenair, Vibhabamba, Mhurd, Aklapper, Izno, AlexWang, Wikidata-bugs, Daniel_Mietchen, Dbrant, Mbch331, Qgil ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T67397: [Story] add a new datatype for formulae
Physikerwelt added subscribers: gerritbot, Qgil. Physikerwelt added a comment. In https://phabricator.wikimedia.org/T67397#2021262, @gerritbot wrote: > Change 269386 merged by jenkins-bot: > Add Math property type to ontology.owl > > https://gerrit.wikimedia.org/r/269386 For the record I think, the patch above should not have been merged yet. I think WMDE should try to respect different opinions, and not classify different opinion as invalid. It is the nature of democracy that one cannot find consensual solutions for all problems, and that things are decided not everybody agrees with. But I will not accept that WMDE classifies opinions as invalid. TASK DETAIL https://phabricator.wikimedia.org/T67397 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Physikerwelt Cc: Qgil, gerritbot, ArthurPSmith, TomT0m, Llyrian, WickieTheViking, Aklapper, MGChecker, Micru, Sannita, Ricordisamoa, Rits, Liuxinyu970226, Tpt, Physikerwelt, Wikidata-bugs, Bene, Tobias1984, Lydia_Pintscher, daniel, Izno, mobrovac, Prod, aude, fredw, Pkra, scfc, Mbch331, Ltrlg ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
Re: [Wikidata] SPARQL CONSTRUCT results truncated
12.02.2016, 10:43, Markus Krötzsch wrote: Restricting queries syntactically to be "simpler" is what we did in Semantic MediaWiki (because MySQL did not support time/memory limits per query). It is a workaround, but it will not prevent long-running queries unless you make the syntactic restrictions really severe (and thereby forbid many simple queries, too). I would not do it if there is support for time/memory limits instead. Would providing a Linked Data Fragments server [1] help here? It seems to be designed exactly for situations like this, where you want to provide a SPARQL query service a large amount of linked data, but are worried about server performance particularly for complex, long-running queries. Linked Data Fragments pushes some of the heavy processing to the client side, which parses and executes the SPARQL queries. Dynamically updating the data might be an issue here, but some of the server implementations support running on top of a SPARQL endpoint [2]. I think that from the perspective of the server this means that a heavy, long-running SPARQL query is broken up already on the client side into several small, simple SPARQL queries that are relatively easy to serve. -Osma [1] http://linkeddatafragments.org/ [2] https://github.com/LinkedDataFragments/Server.js#configure-the-data-sources -- Osma Suominen D.Sc. (Tech), Information Systems Specialist National Library of Finland P.O. Box 26 (Kaikukatu 4) 00014 HELSINGIN YLIOPISTO Tel. +358 50 3199529 osma.suomi...@helsinki.fi http://www.nationallibrary.fi ___ Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
[Wikidata-bugs] [Maniphest] [Commented On] T126152: [RFC] Design of provider/holder interfaces in Wikibase's data model
adrianheine added a comment. I suppose ChangeOps could easily work with immutable objects by having setters return new objects. For deserialization, this would probably produce a lot of objects, though. Can't we deserialize bottom-up to avoid this? TASK DETAIL https://phabricator.wikimedia.org/T126152 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: adrianheine Cc: adrianheine, daniel, JeroenDeDauw, thiemowmde, Aklapper, Bene, StudiesWorld, Izno, Luke081515, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T126597: [Task] Move WikibaseDataModel to Gerrit
Bene added a comment. What I expect is that eventually all our code will be located here on phabricator and integration with our ticket and sprint system will improve significantly. The question is when this transition will happen. I'm all in favour of trying new things out but maybe we shouldn't do that testing with one of our most important components like the data model. TASK DETAIL https://phabricator.wikimedia.org/T126597 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bene Cc: Jonas, hoo, Dereckson, Lydia_Pintscher, MZMcBride, aude, JanZerebecki, JeroenDeDauw, Legoktm, GPHemsley, Tobi_WMDE_SW, adrianheine, daniel, thiemowmde, Aklapper, mmodell, chasemp, Ricordisamoa, Liuxinyu970226, Addshore, Bene, Lazowik, Tpt, Krenair, Izno, Luke081515, Wikidata-bugs, Mbch331, QChris, greg ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T67397: [Story] add a new datatype for formulae
daniel added a comment.
@Physikerwelt I'm confused - what opinion was not respected? Is this about the
TeX vs MathML thing?
I think the "invalid" bit is a misunderstanding. Thiemo said //-1 means "please
improve". A -1 with no reason given is invalid//. This is indeed our policy: A
CR-1 vote needs to come with a reason and way forward, otherwise it's
considered stonewalling, and can be ignored - though it's preferred to ask for
clarification before overriding a CR-1. I suppose you consider your inline
comments to be the reason for the CR-1, but that isn't clear from looking at
the discussion, or the comments.
FWIW, I don't see how the ontology.owl patch is related to the MathML vs TeX
discussion. All ontology.owl does is give a description of the data types, it
doesn't say anything about the format of literals or the structure of values.
We could mention the format in the description of the data type, but we don't
do that for any of the other types, and I would consider it a bad idea. It
would mean mixing two levels of abstraction: the data type is about
interpretation ("mathematical expression"), the literal type is about the
format or encoding (TeX, MathML, etc). The format is specified by the uri given
as the literal's type, and the uri should resolve to a description of the
format.
Btw, I'm not very happy about an extension defined data type being in
ontology.owl, but I don't think it's a disaster either. I tried to come up with
a better mechanism in I7599e7fa5391f9, but using that for math would mean a
breaking change.
TASK DETAIL
https://phabricator.wikimedia.org/T67397
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Physikerwelt, daniel
Cc: gerritbot, ArthurPSmith, TomT0m, Llyrian, WickieTheViking, Aklapper,
MGChecker, Micru, Sannita, Ricordisamoa, Rits, Liuxinyu970226, Tpt,
Physikerwelt, Wikidata-bugs, Bene, Tobias1984, Lydia_Pintscher, daniel, Izno,
mobrovac, Prod, aude, fredw, Pkra, scfc, Mbch331, Ltrlg
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T102476: RFC: Requirements for change propagation
Qgil removed a subscriber: Qgil. TASK DETAIL https://phabricator.wikimedia.org/T102476 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: GWicke, Qgil Cc: ArielGlenn, hoo, Addshore, RobLa-WMF, StudiesWorld, intracer, JanZerebecki, brion, Ltrlg, Anomie, Milimetric, mark, BBlack, aaron, daniel, Eevans, mobrovac, GWicke, Izno, Hardikj, Wikidata-bugs, aude, jayvdb, Mbch331, Jay8g, bd808, Legoktm ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
Re: [Wikidata] SPARQL CONSTRUCT results truncated
On 12.02.2016 00:04, Stas Malyshev wrote: Hi! We basically have two choices: either we offer a limited interface that only allows for a narrow range of queries to be run at all. Or we offer a very general interface that can run arbitrary queries, but we impose limits on time and memory consumption. I would actually prefer the first option, because it's more predictable, and doesn't get people's hopes up too far. What do you think? That would require implementing pretty smart SPARQL parser... I don't think it worth the investment of time. I'd rather put caps on runtime and maybe also on parallel queries per IP, to ensure fair access. We may also have a way to run longer queries - in fact, we'll need it anyway if we want to automate lists - but that is longer term, we'll need to figure out infrastructure for that and how we allocate access. +1 Restricting queries syntactically to be "simpler" is what we did in Semantic MediaWiki (because MySQL did not support time/memory limits per query). It is a workaround, but it will not prevent long-running queries unless you make the syntactic restrictions really severe (and thereby forbid many simple queries, too). I would not do it if there is support for time/memory limits instead. In the end, even the SPARQL engines are not able to predict reliably how complicated a query is going to be -- it's an important part of their work (for optimising query execution), but it is also very difficult. Markus ___ Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
[Wikidata-bugs] [Maniphest] [Commented On] T126730: Caching for results of wikidatasparql queries for Graphs
Yurik added a comment. I think Graph extension was shown as an example that can easily overwhelm the system without proper caching. More elaborate, research-oriented usages are usually different because they are being done interactively by the query developer. TASK DETAIL https://phabricator.wikimedia.org/T126730 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Yurik Cc: Christopher, Yurik, hoo, Aklapper, aude, Izno, Wikidata-bugs, Mbch331, Jay8g, Ltrlg ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T125391: [Task] Investigation: Remove wbentity blob on mobile
daniel added a comment. I suggest to put any data we want to //optionally// serve into the ParserOutput's //extension data// slots. That way, the info is cached, but won't get served to the client, unless we explicitly splice it in via an OutputPage hook. We can do the splicing as appropriate for the specific type of client. We have to be careful though that any distinction we make when constructing the OutputPage from the ParserOutput has to be consistent with how the web cache is split. TASK DETAIL https://phabricator.wikimedia.org/T125391 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: aude, Jdlrobson, daniel, Jonas, adrianheine, thiemowmde, Tobi_WMDE_SW, Aklapper, Izno, Wikidata-bugs, GWicke, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T125050: Add Scribunto to extension-gate in CI
hashar added a blocking task: T126670: Have CI set `$wgScribuntoDefaultEngine = 'luasandbox` to speed up parser tests. TASK DETAIL https://phabricator.wikimedia.org/T125050 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: hashar Cc: Paladox, hoo, gerritbot, Aklapper, JanZerebecki, StudiesWorld, Izno, Wikidata-bugs, aude, Dinoguy1000, jayvdb, MrStradivarius, Anomie, Jackmcbarn, Mbch331, hashar, greg ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T126730: Caching for results of wikidatasparql queries for Graphs
hoo added a comment. Please note that a SPARQL query takes at least a few hundred ms to run (and up to 30s even), thus doing that during page save/ render is not an option. TASK DETAIL https://phabricator.wikimedia.org/T126730 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: hoo Cc: hoo, Aklapper, aude, Izno, Wikidata-bugs, Yurik, Mbch331, Jay8g, Ltrlg ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
Re: [Wikidata] SPARQL CONSTRUCT results truncated
On 12.02.2016 10:01, Osma Suominen wrote: 12.02.2016, 10:43, Markus Krötzsch wrote: Restricting queries syntactically to be "simpler" is what we did in Semantic MediaWiki (because MySQL did not support time/memory limits per query). It is a workaround, but it will not prevent long-running queries unless you make the syntactic restrictions really severe (and thereby forbid many simple queries, too). I would not do it if there is support for time/memory limits instead. Would providing a Linked Data Fragments server [1] help here? It seems to be designed exactly for situations like this, where you want to provide a SPARQL query service a large amount of linked data, but are worried about server performance particularly for complex, long-running queries. Linked Data Fragments pushes some of the heavy processing to the client side, which parses and executes the SPARQL queries. Dynamically updating the data might be an issue here, but some of the server implementations support running on top of a SPARQL endpoint [2]. I think that from the perspective of the server this means that a heavy, long-running SPARQL query is broken up already on the client side into several small, simple SPARQL queries that are relatively easy to serve. There already is such a service for Wikidata (Cristian Consonni has set it up a while ago). You could try if the query would work there. I think that such queries would be rather challenging for a server of this type, since they require you to iterate almost all of the data client-side. Note that both "instance of human" and "has a GND identifier" are not very selective properties. In this sense, the queries may not be "relatively easy to serve" in this particular case. Markus -Osma [1] http://linkeddatafragments.org/ [2] https://github.com/LinkedDataFragments/Server.js#configure-the-data-sources ___ Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
[Wikidata-bugs] [Maniphest] [Commented On] T126152: [RFC] Design of provider/holder interfaces in Wikibase's data model
adrianheine added a comment. In https://phabricator.wikimedia.org/T126152#2021971, @daniel wrote: > In https://phabricator.wikimedia.org/T126152#2021847, @adrianheine wrote: > > > Why would that be awkward? > > > For one thing, because the SiteLinkList (and ReferenceList, etc) would have > to know how to construct an entity, and which concrete type of entity to > construct, and how. I see no good way to do that. Yeah, well, that would be awkward. > Or, if you spread that over multiple levels, you end up with something like > > $statements = $entity->getStatementList(); > $statement = $statements->getStatement( $hash ); > $references = $statement->setReferenceList(); > $entity = $entity->setStatementList( > $statements->updateStatement( > $hash, > $statement->setReferenceList( > $references->addReference( $reference ) ) ) ); That's basically what I would suggest. We could add some delegation methods (`Item::getStatement( $hash )`), but it boils down to this. >> It's another item. Also, you don't need the old one afterwards. > > If you don't need the old one afterwards, why create a new one instead of > recycling the old one? Because it's much easier to reason about immutable data structures, and because immutable data structures can usually be implemented more efficiently. >> I think in ChangeOps it would not look worse. Also, what would be >> inefficient about that? We are neither doing a lot of changes in ChangeOps >> nor are we working a lot with the entities after having changed them, so >> both immediate and lazy manipulations should be efficient enough. > > Duplicating the entire data structure for every change of any part of it > seems rather wasteful. But you are right that it would be acceptable for > edits. It wouldn't be acceptable for filtering or augmenting a data structure > for output. That's where lazy manipulations could be used (`FilteredEntity(Entity, EntityFilter) implements Entity`). Quite difficult without generics. >> If I get this ticket right we'll probably have to rewrite a lot of code >> anyway, and we can think upfront about what it should look like afterwards. > > I don't see that, actually. We are adding interfaces that will mostly just > declare methods that already exist in the implementations. If we change > contracts, we'll have to check where that may cause problems, but this is a > far cry from changing the paradigm from "manipulate a data structure using > methods" to "construct derived data structure using pure functions". We will have to switch stuff from fingerprint to individual term manipulation. It's probably not that much, though. TASK DETAIL https://phabricator.wikimedia.org/T126152 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: adrianheine Cc: adrianheine, daniel, JeroenDeDauw, thiemowmde, Aklapper, Bene, StudiesWorld, Izno, Luke081515, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T126730: Caching for results of wikidatasparql queries for Graphs
aude edited the task description. aude set Security to None. TASK DETAIL https://phabricator.wikimedia.org/T126730 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: aude Cc: Aklapper, aude, Izno, Wikidata-bugs, Yurik, Mbch331, Jay8g, Ltrlg ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T126152: [RFC] Design of provider/holder interfaces in Wikibase's data model
daniel added a comment. @JeroenDeDauw I did get that, but that only works for things that exist on the Entity level. Or you need to have setters for *every* part of the model on the Entity level. Item::addBadgeToSiteLink( $siteId, $badge ), Item::addReferenceToStatement( $hash, $reference ), etc. Which in turn means that everything that modifies badges would have to operate on Items, even though it shouldn't have to know about entities at all. Yes, possible, but awkward. TASK DETAIL https://phabricator.wikimedia.org/T126152 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: adrianheine, daniel, JeroenDeDauw, thiemowmde, Aklapper, Bene, StudiesWorld, Izno, Luke081515, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T126152: [RFC] Design of provider/holder interfaces in Wikibase's data model
daniel added a comment. @adrianheine I basically agree with you that //formally//, that would be really nice. But //practically//, with PHP and the existing code base, it's pretty much out of the question. TASK DETAIL https://phabricator.wikimedia.org/T126152 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: adrianheine, daniel, JeroenDeDauw, thiemowmde, Aklapper, Bene, StudiesWorld, Izno, Luke081515, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T126732: [[MediaWiki:Apihelp-query+pageterms-description/nb]] i18n issue
Aklapper added a comment. "Message definition (Wikibase - Client)" -> https://phabricator.wikimedia.org/tag/mediawiki-extensions-wikibaseclient/ TASK DETAIL https://phabricator.wikimedia.org/T126732 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Aklapper Cc: Aklapper, jeblad, StudiesWorld, Izno, Wikidata-bugs, aude, Gryllida, Shizhao, Arrbee, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T67397: [Story] add a new datatype for formulae
daniel added a comment. In https://phabricator.wikimedia.org/T67397#2021877, @Physikerwelt wrote: > > I would perfere to wait for I15fbeec282868b4267a3e3d15740f2c3ff37ea48 > > I respect people with a different oppinion about that, but I do not > understand why this argumentation is not considered as a reason. From the conversation on the change, I think it was simply unclear that you meant that to be the reason for your CR-1. I now understand that that was your intention, but I still don't understand the connection, since the entry in the owl file says nothing about the format. I understand that you are unhappy about the "your vote invalid" thing, but I believe no harm was done to the codebase. Do you see any concrete problems with the way to code is now? TASK DETAIL https://phabricator.wikimedia.org/T67397 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Physikerwelt, daniel Cc: gerritbot, ArthurPSmith, TomT0m, Llyrian, WickieTheViking, Aklapper, MGChecker, Micru, Sannita, Ricordisamoa, Rits, Liuxinyu970226, Tpt, Physikerwelt, Wikidata-bugs, Bene, Tobias1984, Lydia_Pintscher, daniel, Izno, mobrovac, Prod, aude, fredw, Pkra, scfc, Mbch331, Ltrlg ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T126152: [RFC] Design of provider/holder interfaces in Wikibase's data model
daniel added a comment. In https://phabricator.wikimedia.org/T126152#2021847, @adrianheine wrote: > Why would that be awkward? For one thing, because the SiteLinkList (and ReferenceList, etc) would have to know how to construct an entity, and which concrete type of entity to construct, and how. I see no good way to do that. > It's another item. Also, you don't need the old one afterwards. If you don't need the old one afterwards, why create a new one instead of recycling the old one? > I think in ChangeOps it would not look worse. Also, what would be inefficient > about that? We are neither doing a lot of changes in ChangeOps nor are we > working a lot with the entities after having changed them, so both immediate > and lazy manipulations should be efficient enough. Duplicating the entire data structure for every change of any part of it seems rather wasteful. But you are right that it would be acceptable for edits. It wouldn't be acceptable for filtering or augmenting a data structure for output. > If I get this ticket right we'll probably have to rewrite a lot of code > anyway, and we can think upfront about what it should look like afterwards. I don't see that, actually. We are adding interfaces that will mostly just declare methods that already exist in the implementations. If we change contracts, we'll have to check where that may cause problems, but this is a far cry from changing the paradigm from "manipulate a data structure using methods" to "construct derived data structure using pure functions". TASK DETAIL https://phabricator.wikimedia.org/T126152 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: adrianheine, daniel, JeroenDeDauw, thiemowmde, Aklapper, Bene, StudiesWorld, Izno, Luke081515, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T126152: [RFC] Design of provider/holder interfaces in Wikibase's data model
JeroenDeDauw added a comment.
@daniel I think you're not getting what Adrian means.
class Item {
public function withSiteLink( SiteLink $link ) {
return new Item( /* stuff with new link added */ );
}
}
You'd not get dependencies from the smaller objects onto the bigger ones.
Making all model objects immutable is not what this issue is about though. This
is however something that we've been "oh that would be nice" at since the start
of the project (long before we had a DataModel component), though something
that while nice in theory, does not seem practical in PHP.
TASK DETAIL
https://phabricator.wikimedia.org/T126152
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: JeroenDeDauw
Cc: adrianheine, daniel, JeroenDeDauw, thiemowmde, Aklapper, Bene,
StudiesWorld, Izno, Luke081515, Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T126730: Caching for results of wikidatasparql queries for Graphs
aude created this task. aude added a subscriber: aude. aude added projects: Wikidata, Graph. Herald added a subscriber: Aklapper. TASK DESCRIPTION Wikidata Query Service is still beta and maybe not reliable enough + perhaps limited capacity currently. Stuff like http://en.wikipedia.beta.wmflabs.org/wiki/Sparql is definitely nice, but maybe we need some form of caching of the query results. (I'm not yet sure where?) Think we should figure this out before we enable this beyond beta. TASK DETAIL https://phabricator.wikimedia.org/T126730 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: aude Cc: Aklapper, aude, Izno, Wikidata-bugs, Yurik, Mbch331, Jay8g, Ltrlg ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T125050: Add Scribunto to extension-gate in CI
hashar edited the task description. TASK DETAIL https://phabricator.wikimedia.org/T125050 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: hashar Cc: Paladox, hoo, gerritbot, Aklapper, JanZerebecki, StudiesWorld, Izno, Wikidata-bugs, aude, Dinoguy1000, jayvdb, MrStradivarius, Anomie, Jackmcbarn, Mbch331, hashar, greg ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T126730: Caching for results of wikidatasparql queries for Graphs
hoo added a subscriber: hoo. TASK DETAIL https://phabricator.wikimedia.org/T126730 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: hoo Cc: hoo, Aklapper, aude, Izno, Wikidata-bugs, Yurik, Mbch331, Jay8g, Ltrlg ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T126730: Caching for results of wikidatasparql queries for Graphs
Yurik added a subscriber: Yurik. Yurik added a comment. I agree that the query should go through varnish, but as usual - what is the purging policy? It will be very complicated to track each piece of data that appears in the result back to the original, and to invalidate it when original changes. We could introduce "its ok to be stale" argument, and allow manual cache flushing. - In VCL, check if request headers `Allow-Stale` is set, return the cached value. Or use some max age setting. - If request has no special headers, treat it as "cache for a minute maximum" - to prevent DOSing TASK DETAIL https://phabricator.wikimedia.org/T126730 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Yurik Cc: Yurik, hoo, Aklapper, aude, Izno, Wikidata-bugs, Mbch331, Jay8g, Ltrlg ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Assigned] T126441: Support PHP 5.5 in CI for Wikidata stuff
hashar assigned this task to JanZerebecki. hashar added a subscriber: hashar. TASK DETAIL https://phabricator.wikimedia.org/T126441 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: JanZerebecki, hashar Cc: hashar, Ricordisamoa, gerritbot, Aklapper, JanZerebecki, StudiesWorld, Izno, Wikidata-bugs, aude, Mbch331, greg ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T126730: Caching for results of wikidatasparql queries for Graphs
Christopher added a subscriber: Christopher. Christopher added a comment. question: why is this task limited in scope to the Graph extension? TASK DETAIL https://phabricator.wikimedia.org/T126730 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Christopher Cc: Christopher, Yurik, hoo, Aklapper, aude, Izno, Wikidata-bugs, Mbch331, Jay8g, Ltrlg ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T126732: [[MediaWiki:Apihelp-query+pageterms-description/nb]] i18n issue
Aklapper edited projects, added MediaWiki-extensions-WikibaseClient; removed MediaWiki-General-or-Unknown. Aklapper set Security to None. Herald added a project: Wikidata. TASK DETAIL https://phabricator.wikimedia.org/T126732 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Aklapper Cc: Aklapper, jeblad, StudiesWorld, Izno, Wikidata-bugs, aude, Gryllida, Shizhao, Arrbee, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Claimed] T114251: [RFC] Magic Infobox implementation
hoo claimed this task. TASK DETAIL https://phabricator.wikimedia.org/T114251 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: hoo Cc: FreedomFighterSparrow, jmadler, Trizek-WMF, Bianjiang, Ricordisamoa, He7d3r, Izno, StudiesWorld, brion, Krenair, Addshore, Smalyshev, Qgil, Lucie, MrStradivarius, Aklapper, Lydia_Pintscher, aude, GWicke, Jdforrester-WMF, cscott, daniel, hoo, Wikidata-bugs, Dinoguy1000, jayvdb, Jackmcbarn, Mbch331, Jay8g, Ltrlg, bd808, Legoktm ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T69122: [Story] Remove assertTag usages from tests
gerritbot added a comment. Change 270278 had a related patch set uploaded (by Ricordisamoa): Add DOMTestTrait to replace deprecated assertTag() https://gerrit.wikimedia.org/r/270278 TASK DETAIL https://phabricator.wikimedia.org/T69122 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: gerritbot Cc: JanZerebecki, Ricordisamoa, gerritbot, Aklapper, Wikidata-bugs, Bene, Tobi_WMDE_SW, JeroenDeDauw, adrianheine, Lydia_Pintscher, daniel, Izno, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Retitled] T126730: [RFC] Caching for results of wikidatasparql queries for Graphs
Jonas changed the title from "Caching for results of wikidatasparql queries for Graphs" to "[RFC] Caching for results of wikidatasparql queries for Graphs". Jonas added projects: RfC, Wikidata-Query-Service. Herald added a project: Discovery. TASK DETAIL https://phabricator.wikimedia.org/T126730 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jonas Cc: Christopher, Yurik, hoo, Aklapper, aude, debt, Gehel, Izno, Luke081515, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, Deskana, Manybubbles, Mbch331, Jay8g, Ltrlg ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T67397: [Story] add a new datatype for formulae
Physikerwelt added a comment. For example quantity simply avoids the problem Quantity Type for numerical quantity. In the same way one could write Type for mathematical expression. That way those types are described after the same pattern and we would avoid the problem at all. TASK DETAIL https://phabricator.wikimedia.org/T67397 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Physikerwelt Cc: gerritbot, ArthurPSmith, TomT0m, Llyrian, WickieTheViking, Aklapper, MGChecker, Micru, Sannita, Ricordisamoa, Rits, Liuxinyu970226, Tpt, Physikerwelt, Wikidata-bugs, Bene, Tobias1984, Lydia_Pintscher, daniel, Izno, mobrovac, Prod, aude, fredw, Pkra, scfc, Mbch331, Ltrlg ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Project Column] T126706: Allow creation of Wikidata descriptions by highlighting words in the app
Dbrant moved this task to Tracking on the Wikipedia-Android-App workboard. TASK DETAIL https://phabricator.wikimedia.org/T126706 WORKBOARD https://phabricator.wikimedia.org/project/board/489/ EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Dbrant Cc: Aklapper, StudiesWorld, Josve05a, Izno, Wikidata-bugs, bearND, aude, Dbrant, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T67397: [Story] add a new datatype for formulae
daniel added a comment. @Physikerwelt Ah, I see what you mean. Perhaps that line should read: //"Type for mathematical expressions as defined by the Math extension."// Then it's clear that we are talking about a data type defined by an extension, not about a format. The description of the data type says nothing about how the value is represented (just like we don't say anything about how other kinds of values are represented). TASK DETAIL https://phabricator.wikimedia.org/T67397 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Physikerwelt, daniel Cc: gerritbot, ArthurPSmith, TomT0m, Llyrian, WickieTheViking, Aklapper, MGChecker, Micru, Sannita, Ricordisamoa, Rits, Liuxinyu970226, Tpt, Physikerwelt, Wikidata-bugs, Bene, Tobias1984, Lydia_Pintscher, daniel, Izno, mobrovac, Prod, aude, fredw, Pkra, scfc, Mbch331, Ltrlg ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T126730: Caching for results of wikidatasparql queries for Graphs
hoo added a comment. If we want a broad solution (and not just a stop gap, that might work for graphs), I think we should go for Query entities again. These would address the problems brought up over here and should also allow for better maintainability. TASK DETAIL https://phabricator.wikimedia.org/T126730 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: hoo Cc: Christopher, Yurik, hoo, Aklapper, aude, Izno, Wikidata-bugs, Mbch331, Jay8g, Ltrlg ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T67397: [Story] add a new datatype for formulae
Physikerwelt added a comment. The problematic thing is that the description says "as supported by the Math extension". I'm afraid that this might raise questions, bug reports and service requests like: - "What is supported by the math extension?" - "Why is X supported but not Y? - "Please enable support of Z." Answering those requests consumes much more time compared to a simple bug that can be fixed by changing the source code. My experience in with the wikimedia services team is that it's common to discuss those effects on the community before merging and that people try to avoid to use override negative votes. For people not working full time on MediaWiki projects it's much more comfortable, if changes get merged once they are ready and well discussed even if that consumes more time. TASK DETAIL https://phabricator.wikimedia.org/T67397 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Physikerwelt Cc: gerritbot, ArthurPSmith, TomT0m, Llyrian, WickieTheViking, Aklapper, MGChecker, Micru, Sannita, Ricordisamoa, Rits, Liuxinyu970226, Tpt, Physikerwelt, Wikidata-bugs, Bene, Tobias1984, Lydia_Pintscher, daniel, Izno, mobrovac, Prod, aude, fredw, Pkra, scfc, Mbch331, Ltrlg ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T126152: [RFC] Design of provider/holder interfaces in Wikibase's data model
adrianheine added a comment. Why would that be awkward? It's another item. Also, you don't need the old one afterwards. I think in ChangeOps it would not look worse. Also, what would be inefficient about that? We are neither doing a lot of changes in ChangeOps nor are we working a lot with the entities after having changed them, so both immediate and lazy manipulations should be efficient enough. If I get this ticket right we'll probably have to rewrite a lot of code anyway, and we can think upfront about what it should look like afterwards. TASK DETAIL https://phabricator.wikimedia.org/T126152 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: adrianheine Cc: adrianheine, daniel, JeroenDeDauw, thiemowmde, Aklapper, Bene, StudiesWorld, Izno, Luke081515, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T67397: [Story] add a new datatype for formulae
Physikerwelt added a comment. I wrote > I think documenting an unintended behaviour makes it worse. People might read > the documentation and adjust to this unintended behaviour. That's the reason, > why I think this should not be merged. In the inline comment I proposed how to proceed > I would perfere to wait for I15fbeec282868b4267a3e3d15740f2c3ff37ea48 I respect people with a different oppinion about that, but I do not understand why this argumentation is not considered as a reason. TASK DETAIL https://phabricator.wikimedia.org/T67397 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Physikerwelt Cc: gerritbot, ArthurPSmith, TomT0m, Llyrian, WickieTheViking, Aklapper, MGChecker, Micru, Sannita, Ricordisamoa, Rits, Liuxinyu970226, Tpt, Physikerwelt, Wikidata-bugs, Bene, Tobias1984, Lydia_Pintscher, daniel, Izno, mobrovac, Prod, aude, fredw, Pkra, scfc, Mbch331, Ltrlg ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Declined] T78291: [Task] Remove deprecated term methods from Entity
Bene closed this task as "Declined". Bene claimed this task. TASK DETAIL https://phabricator.wikimedia.org/T78291 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bene Cc: thiemowmde, JeroenDeDauw, Bene, Aklapper, Lucie, Izno, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Unblock] T98290: [Task] Remove deprecated methods from Entity and subtypes
Bene closed blocking task T78291: [Task] Remove deprecated term methods from Entity as "Declined". TASK DETAIL https://phabricator.wikimedia.org/T98290 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bene Cc: Ricordisamoa, JanZerebecki, daniel, JeroenDeDauw, thiemowmde, Bene, Aklapper, Izno, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T126771: [Task] Use EntityDocument in ChangeOps
Bene created this task. Bene claimed this task. Bene added projects: Wikidata-Sprint-2016-02-02, MediaWiki-extensions-WikibaseRepository, Wikidata. Herald added a subscriber: Aklapper. TASK DESCRIPTION TASK DETAIL https://phabricator.wikimedia.org/T126771 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bene Cc: Aklapper, Izno, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Project Column] T126771: [Task] Use EntityDocument in ChangeOps
Bene moved this task to Done on the Wikidata-Sprint-2016-02-02 workboard. TASK DETAIL https://phabricator.wikimedia.org/T126771 WORKBOARD https://phabricator.wikimedia.org/project/board/1722/ EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bene Cc: Aklapper, Izno, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T126769: [Task] Don't typehint againts Entity
Bene edited projects, added Tracking; removed Patch-For-Review. Bene set Security to None. TASK DETAIL https://phabricator.wikimedia.org/T126769 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bene Cc: hoo, daniel, Lydia_Pintscher, aude, JanZerebecki, JeroenDeDauw, thiemowmde, GPHemsley, adrianheine, Aklapper, Ricordisamoa, Bene, Izno, Wikidata-bugs, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Unblock] T78287: Remove deprecated Entity
Bene closed blocking task T78291: [Task] Remove deprecated term methods from Entity as "Declined". TASK DETAIL https://phabricator.wikimedia.org/T78287 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bene Cc: Bene, StudiesWorld, JeroenDeDauw, Aklapper, Lucie, Izno, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Unblock] T78300: [Task] Remove code and behavior sharing by inheritance in EntityTest
Bene closed blocking task T98290: [Task] Remove deprecated methods from Entity and subtypes as "Declined". TASK DETAIL https://phabricator.wikimedia.org/T78300 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bene Cc: Bene, JeroenDeDauw, Aklapper, Lucie, Izno, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Declined] T98290: [Task] Remove deprecated methods from Entity and subtypes
Bene closed this task as "Declined". Bene claimed this task. TASK DETAIL https://phabricator.wikimedia.org/T98290 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bene Cc: Ricordisamoa, JanZerebecki, daniel, JeroenDeDauw, thiemowmde, Bene, Aklapper, Izno, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Unblock] T75496: [Epic] Support new types of Entities in Wikibase Repository
Bene closed blocking task T98290: [Task] Remove deprecated methods from Entity and subtypes as "Declined". TASK DETAIL https://phabricator.wikimedia.org/T75496 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bene Cc: Bene, Ricordisamoa, Aklapper, adrianheine, GPHemsley, thiemowmde, JeroenDeDauw, JanZerebecki, aude, Lydia_Pintscher, daniel, hoo, Izno, Wikidata-bugs, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Unblock] T126769: [Task] Don't typehint againts Entity
Bene closed blocking task T126771: [Task] Use EntityDocument in ChangeOps as "Resolved". TASK DETAIL https://phabricator.wikimedia.org/T126769 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bene Cc: hoo, daniel, Lydia_Pintscher, aude, JanZerebecki, JeroenDeDauw, thiemowmde, GPHemsley, adrianheine, Aklapper, Ricordisamoa, Bene, Izno, Wikidata-bugs, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T126773: [Task] Use EntityDocument in special pages
Bene added a comment. Patches on gerrit: - https://gerrit.wikimedia.org/r/#/c/268964/ - https://gerrit.wikimedia.org/r/#/c/268967/ TASK DETAIL https://phabricator.wikimedia.org/T126773 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bene Cc: Aklapper, Izno, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T126773: [Task] Use EntityDocument in special pages
Bene created this task. Bene claimed this task. Bene added projects: Wikidata-Sprint-2016-02-02, MediaWiki-extensions-WikibaseRepository, Wikidata, Patch-For-Review. Herald added a subscriber: Aklapper. TASK DESCRIPTION TASK DETAIL https://phabricator.wikimedia.org/T126773 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bene Cc: Aklapper, Izno, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T125668: Mismatch of merge edits when merging items
matej_suchanek removed a subscriber: matej_suchanek. TASK DETAIL https://phabricator.wikimedia.org/T125668 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: matej_suchanek Cc: Addshore, Mbch331, Lydia_Pintscher, Aklapper, XXN, StudiesWorld, Izno, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T126775: [Task] Use EntityDocument in api modules
Bene added a blocking task: T126771: [Task] Use EntityDocument in ChangeOps. TASK DETAIL https://phabricator.wikimedia.org/T126775 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bene Cc: Aklapper, Izno, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T126775: [Task] Use EntityDocument in api modules
Bene created this task. Bene claimed this task. Bene added projects: Wikidata-Sprint-2016-02-02, MediaWiki-extensions-WikibaseRepository, Wikidata. Herald added a subscriber: Aklapper. TASK DESCRIPTION TASK DETAIL https://phabricator.wikimedia.org/T126775 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bene Cc: Aklapper, Izno, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T126771: [Task] Use EntityDocument in ChangeOps
Bene added a blocked task: T126775: [Task] Use EntityDocument in api modules. TASK DETAIL https://phabricator.wikimedia.org/T126771 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bene Cc: Aklapper, Izno, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Up For Grabs] T78287: Remove deprecated Entity
Bene placed this task up for grabs. Bene added a project: Wikibase-DataModel-Release-6.0.0. TASK DETAIL https://phabricator.wikimedia.org/T78287 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bene Cc: Bene, StudiesWorld, JeroenDeDauw, Aklapper, Lucie, Izno, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Reopened] T78287: Remove deprecated Entity
Bene reopened this task as "Open". Bene added a subscriber: Bene. Herald added a subscriber: StudiesWorld. TASK DETAIL https://phabricator.wikimedia.org/T78287 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: JeroenDeDauw, Bene Cc: Bene, StudiesWorld, JeroenDeDauw, Aklapper, Lucie, Izno, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T126769: [Task] Don't typehint againts Entity
Bene created this task. Bene claimed this task. Bene added subscribers: Bene, Ricordisamoa, Aklapper, adrianheine, GPHemsley, thiemowmde, JeroenDeDauw, JanZerebecki, aude, Lydia_Pintscher, daniel, hoo. Bene added projects: Wikidata, MediaWiki-extensions-WikibaseRepository, Wikidata-Sprint-2016-02-02, Patch-For-Review. TASK DESCRIPTION Entity is deprecated since 1.0 - do not type hint against Entity. See https://lists.wikimedia.org/pipermail/wikidata-tech/2014-June/000489.html TASK DETAIL https://phabricator.wikimedia.org/T126769 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bene Cc: hoo, daniel, Lydia_Pintscher, aude, JanZerebecki, JeroenDeDauw, thiemowmde, GPHemsley, adrianheine, Aklapper, Ricordisamoa, Bene, Izno, Wikidata-bugs, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Closed] T126771: [Task] Use EntityDocument in ChangeOps
Bene closed this task as "Resolved". Bene added a comment. Patch on gerrit: https://gerrit.wikimedia.org/r/#/c/268953/ TASK DETAIL https://phabricator.wikimedia.org/T126771 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bene Cc: Aklapper, Izno, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Project Column] T126773: [Task] Use EntityDocument in special pages
Bene moved this task to Review on the Wikidata-Sprint-2016-02-02 workboard. TASK DETAIL https://phabricator.wikimedia.org/T126773 WORKBOARD https://phabricator.wikimedia.org/project/board/1722/ EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bene Cc: Aklapper, Izno, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T126773: [Task] Use EntityDocument in special pages
Bene added a blocking task: T126771: [Task] Use EntityDocument in ChangeOps. TASK DETAIL https://phabricator.wikimedia.org/T126773 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bene Cc: Aklapper, Izno, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T126771: [Task] Use EntityDocument in ChangeOps
Bene added a blocked task: T126773: [Task] Use EntityDocument in special pages. TASK DETAIL https://phabricator.wikimedia.org/T126771 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bene Cc: Aklapper, Izno, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T126741: Add support for the wikidata's Sparql queries to graphs
Yurik added a project: Wikidata-Query-Service. Yurik set Security to None. Herald added projects: Wikidata, Discovery. TASK DETAIL https://phabricator.wikimedia.org/T126741 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Yurik Cc: Ricordisamoa, Smalyshev, aude, Aklapper, Yurik, StudiesWorld, debt, Gehel, Izno, jkroll, Wikidata-bugs, Jdouglas, Deskana, Manybubbles, Mbch331, Jay8g, Ltrlg ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T126741: Add support for the wikidata's Sparql queries to graphs
aude added a blocking task: T126730: [RFC] Caching for results of wikidatasparql queries for Graphs. TASK DETAIL https://phabricator.wikimedia.org/T126741 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Yurik, aude Cc: Ricordisamoa, Smalyshev, aude, Aklapper, Yurik, StudiesWorld, debt, Gehel, Izno, jkroll, Wikidata-bugs, Jdouglas, Deskana, Manybubbles, Mbch331, Jay8g, Ltrlg ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T126730: [RFC] Caching for results of wikidatasparql queries for Graphs
aude added a comment. we might want to track entity usage of whatever entities are used and that could be incorporated into cache invalidation (essentially it's arbitrary access) TASK DETAIL https://phabricator.wikimedia.org/T126730 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: aude Cc: Ricordisamoa, daniel, Lydia_Pintscher, Smalyshev, Jonas, Christopher, Yurik, hoo, Aklapper, aude, debt, Gehel, Izno, Luke081515, jkroll, Wikidata-bugs, Jdouglas, Deskana, Manybubbles, Mbch331, Jay8g, Ltrlg ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T126730: [RFC] Caching for results of wikidatasparql queries for Graphs
hoo added a comment. In https://phabricator.wikimedia.org/T126730#2022524, @Jonas wrote: > I think it is quite obvious that we need at least some caching before the > Query entities are finally deployed, because Graph extension is not the only > possible source of DoS requests. I didn't quite get what you're trying to say… Query entities would inherently give us a way to cache results and they could easily use their own (private) blazegraph instance which would protect (to a certain degree) them from public service outages (which is something you could of course do for all kinds of internal querying). Protecting us from a DoS from Graph queries or query entities queries specifically shouldn't be too hard: We can control how often we allow users to purge the data and all query changes need an edit at some point (which is obviously visible). TASK DETAIL https://phabricator.wikimedia.org/T126730 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: hoo Cc: daniel, Lydia_Pintscher, Smalyshev, Jonas, Christopher, Yurik, hoo, Aklapper, aude, debt, Gehel, Izno, Luke081515, jkroll, Wikidata-bugs, Jdouglas, Deskana, Manybubbles, Mbch331, Jay8g, Ltrlg ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T126730: [RFC] Caching for results of wikidatasparql queries for Graphs
Ricordisamoa added a subscriber: Ricordisamoa. Ricordisamoa added a comment. If a good caching strategy can be made to work without Query entities, why not reuse it for Scribunto access? TASK DETAIL https://phabricator.wikimedia.org/T126730 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Ricordisamoa Cc: Ricordisamoa, daniel, Lydia_Pintscher, Smalyshev, Jonas, Christopher, Yurik, hoo, Aklapper, aude, debt, Gehel, Izno, Luke081515, jkroll, Wikidata-bugs, Jdouglas, Deskana, Manybubbles, Mbch331, Jay8g, Ltrlg ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
Re: [Wikidata] SPARQL CONSTRUCT results truncated
It's great how this discussion evolves - thanks to everybody! Technically, I completely agree that in practice it may prove impossible to predict the load a query will produce. Relational databases have invested years and years in query optimization (e.g., Oracles cost based optimizer, which relies on extended statistics gathered during runtime), and I can't see that similar investments are possible for triple stores. What I could imagine for public endpoints is the SPARQL engine monitoring and prioritizing queries: the longer a query already runs, or the more resources it has already used, the lower its priority is re-scheduled (up to some final limit). But this is just a theoretical consideration, I'm not aware of any system that implements anything like this - and it could be implemented only in the engine itself. For ZBWs SPARQL endpoints, I've implemented a much simpler three-level strategy, which does not involve the engine at all: 1. Endpoints which drive production-level services (e.g. autosuggest or retrieval enhancement functions). These endpoints run on separate machines and offer completely encapsulated services via a public API (http://zbw.eu/beta/econ-ws), without any direct SPARQL access. 2. Public "beta" endpoints (http://zbw.eu/beta/sparql). These offer unrestricted SPARQL access, but without any garanties about performance or availability - though of course I do my best to keep these up and running. They run on an own virtual machine, and should not hurt any other parts of the infrastructure when getting overloaded or out of control. 3. Public "experimental" endpoints. These include in particular an endpoint for the GND dataset with 130m triples. It was mainly created for internal use because (to my best knowledge) no other public GND endpoint exists. The endpoint is not linked from the GND pages of DNB, and I've advertised it very low-key on a few mailing lists. For these experimental endpoints, we reserve the right to shut them down for the public if they get flooded with more requests than they can handle. It may be of interest, that up to now, on none of these public endpoints we came across issues with attacks or evil-minded queries (which were a matter of concern when I started this in 2009), nor with longer-lasting massive access. Of course, that is different for Wikidata, where the data is of interest for _much_ more people. But if anyhow affordable, I'd like to encourage offering some kind of experimental access with really wide limits in an "unstable" setting, in addition to the reliable services. For most people who just want to check out something, it's not an option to download the whole dataset and set up an infrastructure for it. For us, this was an issue with even the much smaller GND set. The Linked data fragments approach Osma mentioned is very interesting (particularly the bit about setting it up on top of an regularily updated existing endpoint), and could provide another alternative, but I have not yet experimented with it. Have a fine weekend - Joachim -Ursprüngliche Nachricht- Von: Wikidata [mailto:wikidata-boun...@lists.wikimedia.org] Im Auftrag von Markus Krötzsch Gesendet: Freitag, 12. Februar 2016 09:44 An: Discussion list for the Wikidata project. Betreff: Re: [Wikidata] SPARQL CONSTRUCT results truncated On 12.02.2016 00:04, Stas Malyshev wrote: > Hi! > >> We basically have two choices: either we offer a limited interface >> that only allows for a narrow range of queries to be run at all. Or >> we offer a very general interface that can run arbitrary queries, but >> we impose limits on time and memory consumption. I would actually >> prefer the first option, because it's more predictable, and doesn't get >> people's hopes up too far. What do you think? > > That would require implementing pretty smart SPARQL parser... I don't > think it worth the investment of time. I'd rather put caps on runtime > and maybe also on parallel queries per IP, to ensure fair access. We > may also have a way to run longer queries - in fact, we'll need it > anyway if we want to automate lists - but that is longer term, we'll > need to figure out infrastructure for that and how we allocate access. +1 Restricting queries syntactically to be "simpler" is what we did in Semantic MediaWiki (because MySQL did not support time/memory limits per query). It is a workaround, but it will not prevent long-running queries unless you make the syntactic restrictions really severe (and thereby forbid many simple queries, too). I would not do it if there is support for time/memory limits instead. In the end, even the SPARQL engines are not able to predict reliably how complicated a query is going to be -- it's an important part of their work (for optimising query execution), but it is also very difficult. Markus > ___ Wikidata mailing list Wikidata@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T126730: [RFC] Caching for results of wikidatasparql queries for Graphs
Jonas added subscribers: Smalyshev, Lydia_Pintscher, daniel. TASK DETAIL https://phabricator.wikimedia.org/T126730 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jonas Cc: daniel, Lydia_Pintscher, Smalyshev, Jonas, Christopher, Yurik, hoo, Aklapper, aude, debt, Gehel, Izno, Luke081515, jkroll, Wikidata-bugs, Jdouglas, Deskana, Manybubbles, Mbch331, Jay8g, Ltrlg ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T126730: [RFC] Caching for results of wikidatasparql queries for Graphs
Jonas added a comment. I think it is quite obvious that we need at least some caching before the Query entities are finally deployed, because Graph extension is not the only possible source of DoS requests. There are a lot of use cases were we are fine with cached (old) results. We could make a lot of people very happy with this. TASK DETAIL https://phabricator.wikimedia.org/T126730 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jonas Cc: daniel, Lydia_Pintscher, Smalyshev, Jonas, Christopher, Yurik, hoo, Aklapper, aude, debt, Gehel, Izno, Luke081515, jkroll, Wikidata-bugs, Jdouglas, Deskana, Manybubbles, Mbch331, Jay8g, Ltrlg ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T126730: [RFC] Caching for results of wikidatasparql queries for Graphs
aude added a blocked task: T126741: Add support for the wikidata's Sparql queries to graphs. TASK DETAIL https://phabricator.wikimedia.org/T126730 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: aude Cc: daniel, Lydia_Pintscher, Smalyshev, Jonas, Christopher, Yurik, hoo, Aklapper, aude, debt, Gehel, Izno, Luke081515, jkroll, Wikidata-bugs, Jdouglas, Deskana, Manybubbles, Mbch331, Jay8g, Ltrlg ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T67397: [Story] add a new datatype for formulae
daniel added a comment. @Physikerwelt yes, that's what I mean. There isn't supposed to be any info about the format here. However, I do find it useful to explicitly say that this type is defined by the Math extension. Otherwise, someone might remove it, since it does not seem to be used in Wikibase at all. TASK DETAIL https://phabricator.wikimedia.org/T67397 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Physikerwelt, daniel Cc: gerritbot, ArthurPSmith, TomT0m, Llyrian, WickieTheViking, Aklapper, MGChecker, Micru, Sannita, Ricordisamoa, Rits, Liuxinyu970226, Tpt, Physikerwelt, Wikidata-bugs, Bene, Tobias1984, Lydia_Pintscher, daniel, Izno, mobrovac, Prod, aude, fredw, Pkra, scfc, Mbch331, Ltrlg ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T126730: [RFC] Caching for results of wikidatasparql queries for Graphs
Jonas added a subscriber: Jonas. TASK DETAIL https://phabricator.wikimedia.org/T126730 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jonas Cc: Jonas, Christopher, Yurik, hoo, Aklapper, aude, debt, Gehel, Izno, Luke081515, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, Deskana, Manybubbles, Mbch331, Jay8g, Ltrlg ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T67397: [Story] add a new datatype for formulae
Physikerwelt added a comment. @daniel: That's another point. This is indeed helpful for users that are aware of MediaWiki and that there are extensions and so on. However, if this text is displayed to users that are not aware of the technicalities, it might also cause confusion. But on a meta level I think those questions should be discussed before things are merged. TASK DETAIL https://phabricator.wikimedia.org/T67397 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Physikerwelt Cc: gerritbot, ArthurPSmith, TomT0m, Llyrian, WickieTheViking, Aklapper, MGChecker, Micru, Sannita, Ricordisamoa, Rits, Liuxinyu970226, Tpt, Physikerwelt, Wikidata-bugs, Bene, Tobias1984, Lydia_Pintscher, daniel, Izno, mobrovac, Prod, aude, fredw, Pkra, scfc, Mbch331, Ltrlg ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T126730: [RFC] Caching for results of wikidatasparql queries for Graphs
hoo added a comment. In https://phabricator.wikimedia.org/T126730#2022680, @Ricordisamoa wrote: > If a good caching strategy can be made to work without Query entities, why > not reuse it for Scribunto access? Inline queries have a potentially high maintenance cost and don't have a history, therefore I would prefer not to do that without Query entities, even if we can address the performance issues. TASK DETAIL https://phabricator.wikimedia.org/T126730 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: hoo Cc: Ricordisamoa, daniel, Lydia_Pintscher, Smalyshev, Jonas, Christopher, Yurik, hoo, Aklapper, aude, debt, Gehel, Izno, Luke081515, jkroll, Wikidata-bugs, Jdouglas, Deskana, Manybubbles, Mbch331, Jay8g, Ltrlg ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T126789: [Task] Remove references to Entity in tests
Bene created this task. Bene claimed this task. Bene added projects: MediaWiki-extensions-WikibaseRepository, Wikidata. Herald added a subscriber: Aklapper. TASK DESCRIPTION There are still lots of references to Entity in our tests. Most of them should be easily removable since we know which entity types we use in our tests. TASK DETAIL https://phabricator.wikimedia.org/T126789 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bene Cc: Aklapper, Izno, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Retitled] T126769: [Tracking] Don't typehint against Entity
Bene changed the title from "[Tracking] Don't typehint againts Entity" to "[Tracking] Don't typehint against Entity". TASK DETAIL https://phabricator.wikimedia.org/T126769 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bene Cc: hoo, daniel, Lydia_Pintscher, aude, JanZerebecki, JeroenDeDauw, thiemowmde, GPHemsley, adrianheine, Aklapper, Ricordisamoa, Bene, Izno, Wikidata-bugs, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Project Column] T126775: [Task] Use EntityDocument in api modules
Bene moved this task to Review on the Wikidata-Sprint-2016-02-02 workboard. TASK DETAIL https://phabricator.wikimedia.org/T126775 WORKBOARD https://phabricator.wikimedia.org/project/board/1722/ EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bene Cc: Aklapper, Izno, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T126775: [Task] Use EntityDocument in api modules
Bene added a project: Patch-For-Review. Bene added a comment. Patches on gerrit: - https://gerrit.wikimedia.org/r/#/c/268970/ - https://gerrit.wikimedia.org/r/#/c/268668/ - https://gerrit.wikimedia.org/r/#/c/270289/ - https://gerrit.wikimedia.org/r/#/c/268976/ TASK DETAIL https://phabricator.wikimedia.org/T126775 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bene Cc: Aklapper, Izno, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T125636: [Task] Release Wikibase DataModel 5.0
Bene added a blocked task: T126779: [Task] Refactor EntityContent to not depend on Entity. TASK DETAIL https://phabricator.wikimedia.org/T125636 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bene Cc: Aklapper, daniel, adrianheine, JeroenDeDauw, Bene, thiemowmde, Tobi_WMDE_SW, Izno, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T126779: [Task] Refactor EntityContent to not depend on Entity
Bene added a blocking task: T125636: [Task] Release Wikibase DataModel 5.0. TASK DETAIL https://phabricator.wikimedia.org/T126779 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bene Cc: Aklapper, Izno, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T126779: [Task] Refactor EntityContent to not depend on Entity
Bene created this task. Bene claimed this task. Bene added projects: Wikidata-Sprint-2016-02-02, MediaWiki-extensions-WikibaseRepository, Wikidata, Patch-For-Review. Herald added a subscriber: Aklapper. TASK DESCRIPTION TASK DETAIL https://phabricator.wikimedia.org/T126779 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bene Cc: Aklapper, Izno, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Project Column] T126779: [Task] Refactor EntityContent to not depend on Entity
Bene moved this task to Review on the Wikidata-Sprint-2016-02-02 workboard. TASK DETAIL https://phabricator.wikimedia.org/T126779 WORKBOARD https://phabricator.wikimedia.org/project/board/1722/ EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bene Cc: Aklapper, Izno, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Project Column] T126769: [Task] Don't typehint againts Entity
Bene moved this task to Review on the Wikidata-Sprint-2016-02-02 workboard. TASK DETAIL https://phabricator.wikimedia.org/T126769 WORKBOARD https://phabricator.wikimedia.org/project/board/1722/ EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bene Cc: hoo, daniel, Lydia_Pintscher, aude, JanZerebecki, JeroenDeDauw, thiemowmde, GPHemsley, adrianheine, Aklapper, Ricordisamoa, Bene, Izno, Wikidata-bugs, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Retitled] T126769: [Tracking] Don't typehint againts Entity
Bene changed the title from "[Task] Don't typehint againts Entity" to "[Tracking] Don't typehint againts Entity". TASK DETAIL https://phabricator.wikimedia.org/T126769 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bene Cc: hoo, daniel, Lydia_Pintscher, aude, JanZerebecki, JeroenDeDauw, thiemowmde, GPHemsley, adrianheine, Aklapper, Ricordisamoa, Bene, Izno, Wikidata-bugs, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Up For Grabs] T126789: [Task] Remove references to Entity in tests
Bene placed this task up for grabs. Bene set Security to None. TASK DETAIL https://phabricator.wikimedia.org/T126789 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bene Cc: Aklapper, Izno, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T126795: [Task] Improve copy mechanism for EntityDocuments
Bene added a comment. Patch on Github: https://github.com/wmde/WikibaseDataModel/pull/626 TASK DETAIL https://phabricator.wikimedia.org/T126795 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bene Cc: Aklapper, StudiesWorld, thiemowmde, daniel, Bene, Izno, Wikidata-bugs, aude, JeroenDeDauw, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Assigned] T125636: [Task] Release Wikibase DataModel 5.0
Bene assigned this task to thiemowmde. Bene added a comment. All blockers have been resolved (besides one single comment in the release patch itself). We can finally do the release \o/ TASK DETAIL https://phabricator.wikimedia.org/T125636 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: thiemowmde, Bene Cc: Aklapper, daniel, adrianheine, JeroenDeDauw, Bene, thiemowmde, Tobi_WMDE_SW, Izno, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Project Column] T126795: [Task] Improve copy mechanism for EntityDocuments
Bene moved this task to consider for next sprint on the Wikidata workboard. TASK DETAIL https://phabricator.wikimedia.org/T126795 WORKBOARD https://phabricator.wikimedia.org/project/board/71/ EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bene Cc: Aklapper, StudiesWorld, thiemowmde, daniel, Bene, Izno, Wikidata-bugs, aude, JeroenDeDauw, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T126795: [Task] Improve copy mechanism for EntityDocuments
Bene created this task. Bene added subscribers: Bene, daniel, thiemowmde. Bene added projects: Wikidata, Wikibase-DataModel, Wikibase-DataModel-Release-6.0.0. Herald added subscribers: StudiesWorld, Aklapper. TASK DESCRIPTION Currently, `Entity::clone` calls `unserialize( serialize( $this ) )` which is very bad performance-wise. We only want to clone objects that are mutable and keep references to the immutable objects. TASK DETAIL https://phabricator.wikimedia.org/T126795 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bene Cc: Aklapper, StudiesWorld, thiemowmde, daniel, Bene, Izno, Wikidata-bugs, aude, JeroenDeDauw, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T126795: [Task] Improve copy mechanism for EntityDocuments
Bene removed a project: Wikibase-DataModel-Release-6.0.0. Bene set Security to None. TASK DETAIL https://phabricator.wikimedia.org/T126795 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bene Cc: Aklapper, StudiesWorld, thiemowmde, daniel, Bene, Izno, Wikidata-bugs, aude, JeroenDeDauw, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T126730: [RFC] Caching for results of wikidatasparql queries for Graphs
Smalyshev added a comment. Hmm... I'm not sure I want to do this in generic case. Not all queries should be cached - in fact, there are plenty of queries that change and should **not** be cached, and that's the whole point - such as data quality queries that may drive bots, etc. On the other hand, there are queries that **can** be cached. So I wonder what if we make some path parameter of header that would control which caching header nginx returns? So that the client could control whether they want cached or uncached result (with the default being the current state of affairs). On a more general note, I think the better solution for this would be to have some kind of intermediate data store (either on wiki or maybe in restBase?) that would fetch query data and cache it with various times and the graphs would use that store. TASK DETAIL https://phabricator.wikimedia.org/T126730 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Smalyshev Cc: Ricordisamoa, daniel, Lydia_Pintscher, Smalyshev, Jonas, Christopher, Yurik, hoo, Aklapper, aude, debt, Gehel, Izno, Luke081515, jkroll, Wikidata-bugs, Jdouglas, Deskana, Manybubbles, Mbch331, Jay8g, Ltrlg ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T96490: [Story] Blazegraph support for owl:sameAs and redirects
Yurik added a subscriber: Yurik. TASK DETAIL https://phabricator.wikimedia.org/T96490 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Yurik Cc: Yurik, JanZerebecki, Denny, mkroetzsch, Lydia_Pintscher, M.schmidt00, Beebs.systap, Haasepeter, Thompsonbry.systap, Thompsonbry, daniel, Manybubbles, Aklapper, Smalyshev, debt, Gehel, Izno, jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Project Column] T109675: [Task] Enable phase 1 for Wikiversity
Quiddity moved this task to Announce in next Tech/News on the user-notice workboard. TASK DETAIL https://phabricator.wikimedia.org/T109675 WORKBOARD https://phabricator.wikimedia.org/project/board/1097/ EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Quiddity Cc: Lydia_Pintscher, Lsanabria, Ricordisamoa, Liuxinyu970226, Bugreporter, Aklapper, TerraCodes, Johan, Izno, Luke081515, Wikidata-bugs, aude, TheDJ, Mbch331, Jay8g ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T126349: RDF export for the math data type should not export input texvc string but its MathML representation
gerritbot added a comment. Change 269473 merged by Mobrovac: RDF Formatter for Math data type https://gerrit.wikimedia.org/r/269473 TASK DETAIL https://phabricator.wikimedia.org/T126349 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Physikerwelt, gerritbot Cc: thiemowmde, mkroetzsch, fredw, gerritbot, daniel, Lydia_Pintscher, Tobias1984, Bene, Wikidata-bugs, Physikerwelt, Tpt, Liuxinyu970226, Rits, Ricordisamoa, Sannita, Micru, MGChecker, Aklapper, WickieTheViking, Llyrian, TomT0m, ArthurPSmith, Izno, Prod, aude, Pkra, scfc, Mbch331, Ltrlg ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T18976: Wikis waiting for creation (tracking)
Liuxinyu970226 added a blocking task: T126832: create a wiki for Wikimedia Portugal. TASK DETAIL https://phabricator.wikimedia.org/T18976 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Liuxinyu970226 Cc: JEumerus, greg, Krenair, Aklapper, Meno25, Matanya, Arseny1992, aude, brion, Amire80, Ebe123, SPQRobin, mxn, TTO, Az1568, Pathoschild, Merl, Petrb, Steinsplitter, revi, Glaisher, Rschen7754, Peachey88, Kanjy, Snowolf, Hkjacksonhk, Liuxinyu970226, jeremyb, MF-Warburg, Stryn, zhuyifei1999, Dcljr, Dereckson, JohnLewis, Izno, Luke081515, Wikidata-bugs, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Closed] T103346: phpunit hhvm failure: LuaSandbox: TextLibraryTests[87]: json decode, invalid values (trailing comma)
Catrope closed this task as "Resolved". Catrope added a subscriber: Catrope. TASK DETAIL https://phabricator.wikimedia.org/T103346 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Mattflaschen, Catrope Cc: Catrope, Mattflaschen, gerritbot, StudiesWorld, daniel, Anomie, JanZerebecki, Aklapper, Izno, Luke081515, Wikidata-bugs, aude, Dinoguy1000, jayvdb, MrStradivarius, Jackmcbarn, Mbch331, Krenair, Joe, jeremyb ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
