Hi, I don't see any of my previously mentioned bugs fixed... But I found new ones ;) * I tried to remove lots of links and after a few the message: "An error occurred while trying to perform remove, and because of this your changes could not be completed Details Attempted modification of the item failed." appears - the details are not very detailed ;) - I can only remove items, that I have added or edited * when I try to add a language, that is already in the list (but I can't find, because the list has no order) there should be a info-box "a link to this language already exists" * the "x + 1 entries" lable when adding a new one is useless, because you are not able to add more than one item at once - it would be, if other users can see the information of not saved items * for "also known as" there is only a "edit"- but no "add"-link * there are edit-links everywhere instead of next to the language links - to fix that you can remove the "visibility: hidden;" property in wikibase.ui.PropertyEditTool.css [Line 51] LB

Hello, For the current demo system, how many triple store retrievals are being performed per Statement per page? Is this more or less or the same as expected under the final design? Under the suggested pure-transclusion approach, I believe the answer is "zero" since all retrievals are performed asynchronously* with respect to client wiki transclusion requests. Are additional triple store retrievals (or updates) occurring? Such as ones to inform a client wikipedia about the currency of Statements previously retrieved from wikidata? In a pure-transclusion approach, such info is "easy" to get at: clients query the [[modification date::]] of each transclusion. Can you point me to a (transaction-level) design for keeping client wikis in sync with Statement-level wikidata content? I'm also concerned about stability & scalability. What happens to the performance of client wikis should the wikidata host be hobbled by DOS attacks, or inadvertent long-running queries, or command line maintenance scripts, or poorly designed wikibots or, as expected, by possilby tens of thousands of wikis accessing the central wikidata host? Under the pure-transclusion approach, my concerns are not nearly the same since all transcludable content is cached on squid servers.... Thanks - john

Hello Martynas, Interesting to read about ESI at http://en.wikipedia.org/wiki/Edge_Side_Includes. I recall that a query facility is intended for Phase 3, but I have no idea the kind of store. I'd think that a quad-store is appropriate to storing provenance data in mind for each triple. It'd be interesting to know whether existing quad-stores can handle the PROV namespace; I see some interesting references at the end of http://www.w3.org/TR/2012/WD-prov-aq-20120619/ to explore! Best - john On 21.06.2012 14:27, Martynas Jusevičius wrote: know Edge Side Includes (ESI)? I was thinking about using them XSLT and Varnish to compose pages from remote XHTML fragments. Regarding scalability -- I can only see those possible cases: either Wikidata will not have any query language, or it's query language will be SQL with never ending JOINs too complicated to be useful, or it's gonna be another query language translated to SQL -- for example SPARQL, which is doable but attempts have shown it doesn't scale. A native RDF store is much more performant. > > Martynas > graphity.org > On Thu, Jun 21, 2012 at 11:34 PM, <jmcclure(a)hypergrove.com> wrote: are being performed per Statement per page? Is this more or less or the same as expected under the final design? Under the suggested pure-transclusion approach, I believe the answer is "zero" since all retrievals are performed asynchronously* with respect to client wiki transclusion requests. Are additional triple store retrievals (or updates) occurring? Such as ones to inform a client wikipedia about the currency of Statements previously retrieved from wikidata? In a pure-transclusion approach, such info is "easy" to get at: clients query the [[modification date::]] of each transclusion. Can you point me to a (transaction-level) design for keeping client wikis in sync with Statement-level wikidata content? I'm also concerned about stability & scalability. What happens to the performance of client wikis should the wikidata host be hobbled by DOS attacks, or inadvertent long-running queries, or command line maintenance scripts, or poorly designed wikibots or, as expected, by possilby tens of thousands of wikis accessing the central wikidata host? Under the pure-transclusion approach, my concerns are not nearly the same since all transcludable content is cached on squid servers.... Thanks - john _______________________________________________ Wikidata-l mailing list Wikidata-l(a)lists.wikimedia.org [1] https://lists.wikimedia.org/mailman/listinfo/wikidata-l [2] _______________________________________________ list > Wikidata-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l Links: ------ [1] mailto:Wikidata-l@lists.wikimedia.org [2] https://lists.wikimedia.org/mailman/listinfo/wikidata-l