Hey :)
The demo system has been updated to the latest changes. It'd be great if you could test it a bit again. The main changes that were made are the addition of aliases (the "Also known as:" part on http://wikidata-test-repo.wikimedia.de/wiki/Data:Q3 for example) and diffing. Diffing only works on sitelinks so far, not on aliases, titles and so on. http://wikidata-test-repo.wikimedia.de
Cheers and thanks for testing Lydia
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
Hey :)
The demo system has been updated to the latest changes. It'd be great if you could test it a bit again. The main changes that were made are the addition of aliases (the "Also known as:" part on http://wikidata-test-repo.wikimedia.de/wiki/Data:Q3 for example) and diffing. Diffing only works on sitelinks so far, not on aliases, titles and so on. http://wikidata-test-repo.wikimedia.de
Cheers and thanks for testing Lydia
-- Lydia Pintscher - http://about.me/lydia.pintscher Community Communications for Wikidata
Wikimedia Deutschland e.V. Obentrautstr. 72 10963 Berlin www.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
On Wed, Jun 20, 2012 at 11:39 PM, benedix@zedat.fu-berlin.de wrote:
Hi,
I don't see any of my previously mentioned bugs fixed...
Hehe yeah. We are not quite _that_ fast.
But I found new ones ;)
Thanks for testing!
- 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
Yeah this is a known bug but the source is unknown so far. Being investigated.
- 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"
Can you please file a bug for that on bugs.wikimedia.org?
- 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
Please file a bug for that too.
- for "also known as" there is only a "edit"- but no "add"-link
Hmmm yeah I think because you add by editing it. Feedback from others on this?
- 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]
Please file a bug for that one too.
Cheers Lydia
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
John,
I pretty much second your concerns.
Do you know Edge Side Includes (ESI)? I was thinking about using them with 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@hypergrove.com wrote:
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
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
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:
John,
I pretty much second your concerns.
Do you
know Edge Side Includes (ESI)? I was thinking about using them
with
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@hypergrove.com wrote:
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 _______________________________________________ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org [1] https://lists.wikimedia.org/mailman/listinfo/wikidata-l [2]
_______________________________________________
Wikidata-l mailing
list
Wikidata-l@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
On Wed, Jun 20, 2012 at 11:39 PM, benedix@zedat.fu-berlin.de wrote:
Hi,
I don't see any of my previously mentioned bugs fixed...
Hehe yeah. We are not quite _that_ fast.
But I found new ones ;)
Thanks for testing!
- 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
Yeah this is a known bug but the source is unknown so far. Being investigated.
- 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"
Can you please file a bug for that on bugs.wikimedia.org?
done
- 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
Please file a bug for that too.
there is a bug from 2012-05-08 containing this issue: https://bugzilla.wikimedia.org/show_bug.cgi?id=36657
- for "also known as" there is only a "edit"- but no "add"-link
Hmmm yeah I think because you add by editing it. Feedback from others on this?
yes, but the inexperienced user does not know about this
e.g. a new Link can be added by clicking on "[add]" (what i dont like, i think you should show the 'language'- and 'page'-textboxes and a button [add] next to it instead of [save][cancel])
- 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]
Please file a bug for that one too.
done
Cheers Lydia
-- Lydia Pintscher - http://about.me/lydia.pintscher Community Communications for Wikidata
Wikimedia Deutschland e.V. Obentrautstr. 72 10963 Berlin www.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l