Re: [Wikidata-l] Wikidata map visualization

[Nikola Smolenski]

On 09/07/13 14:28, Denny Vrandečić wrote:

the following displays geographical data from Wikidata:



It is updated daily, clickable, zoomable, and also can be used to
display the connections between geographically located items. It also
shows how much data is already in Wikidata, and how amazing the
community is. I hope it will also inspire a few more drives for pushing
data into Wikidata. Look at all this huge empty places, in Africa,
central Asia, Canada...


...Europe...

I find it interesting that Poles haven't yet arrived :)

___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Proposal for media meta data on Wikimedia Commons

[Nikola Smolenski]

On 25/06/13 15:04, Daniel Kinzler wrote:

Am 25.06.2013 14:58, schrieb Nikola Smolenski:

Do you think it would it be possible to have this data on the actual image page,
where current page text would be just one of the items?


In theory yes, but I think that would create more problems than it would solve.
For one, wikitext as data values is very tricky.
Also, the transition would be painful.

Also, we'd have to find solutions for categories, for integration with the
translation  stuff, etc.

I think it would create far more problems that it would solve. What's the
problem with having the actual entity on a separate page, and modifying the
{{info}} template to pull info from there using Lua?


Not a problem, but I'm thinking that in future this could be expanded to 
more than images. For example, page categories could be stored as 
statements.


___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Proposal for media meta data on Wikimedia Commons

[Nikola Smolenski]

Two quick questions, I'll use the list since they are technical.

On 25/06/13 14:28, Daniel Kinzler wrote:

Over the last year, we have seen some discussion about if and how Wikidata can
be useful for Wikimedia Commons. One aspect of this is maintaining meta data as
structured data.

On behalf of the Wikidata development team, I just posted a proposal for this:

 https://commons.wikimedia.org/wiki/Commons:Wikidata_for_media_info


>  In order to support Commons meta-data, we plan to introduce another 
entity type, media-info. Each file on commons can have a media-info 
entity associated with it, which would reside on a sub-page of the file 
description page. E.g. the meta-data for File:Berlin.jpg would be 
located at File:Berlin.jpg/info.


Do you think it would it be possible to have this data on the actual 
image page, where current page text would be just one of the items?


> Aperture, etc. Might be taken from EXIF using a bot.

Wouldn't it be possible to create/update this data automatically 
whenever an image is uploaded?


___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Usability flaws

[Nikola Smolenski]

On 05/04/13 16:00, Lukas Benedix wrote:

* when no text is available in the users language the statement section
looks like this:
http://lbenedix.monoceres.uberspace.de/screenshots/mejpee0fxi_(2013-04-05_15.34.41).png



https://bugzilla.wikimedia.org/show_bug.cgi?id=36430#c17

___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Wikidata queries

[Nikola Smolenski]

On 28/03/13 18:03, Denny Vrandečić wrote:

We have a first write up of how we plan to support queries in Wikidata.


It's getting hot :)


Comments on our errors and requests for clarifications are more than
welcome.


What is the difference between 'sort' and 'order' QueryOptions?

And, I wanted to ask this for some time, where exactly are the 
statements being kept? I see no table that contains statements on the 
Toolserver, and nothing in Wikibase schema documentation.


___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] [Wikimedia-l] Are there plans for interactions between wikidata and wiktionaries ?

[Nikola Smolenski]

On 11/03/13 14:52, Denny Vrandečić wrote:

Personally, I regard Wiktionary as the third priority, following
Wikipedia and Commons. A lot of the other projects -- like Wikivoyage or
Wikisource -- can be served with only small changes to Wikidata as it
is, but both Commons and Wiktionary would require a bit of thought (and
here again, Commons much less than Wiktionary). I would appreciate a


On the other hand, I believe Wiktionary too could be well helped with 
only small changes to Wikidata. Interwiki links are the same problem as 
on Wikipedia and could be solved in the same way. Things like words' 
plural, inflections etc. are very tedious to write and could be solved 
like Wikipedia infoboxes. It is relations between words and concepts 
that are the difficult problem and that might require larger Wikidata 
modifications, so this part could be left for the future.


___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] getting some stats for the Hungarian Wikipedia

[Nikola Smolenski]

On 29/01/13 21:45, Amir E. Aharoni wrote:

And until the Big Links Remove, if the bots don't re-add the removed
links by force, that should be enough.


They should not be doing that. Any well-behaving bot will get the list 
of links from the API and not by parsing the article text. And the list 
of links is exactly the same regardless of whether the links come from 
the article text or from Wikidata.


___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Phase 1

[Nikola Smolenski]

On 29/01/13 10:28, Magnus Manske wrote:

So are the same bots doing different things? I seem to remember there
was one giant toolserver pybot instance doing only interwiki.


OTOH, yes, I believe there are bots doing only interwikis that could 
probably be blocked. But isn't anyone from Hungarian Wikipedia here to 
tell us how the test is going and what the community wants to do now?



___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Phase 1

[Nikola Smolenski]

On 29/01/13 10:02, Magnus Manske wrote:

Why not just block the bots on wikis that use wikidata?


Bots are used for much more than interwiki handling.


On Tue, Jan 29, 2013 at 6:51 AM, Bináris mailto:wikipo...@gmail.com>> wrote:



2013/1/28 Amir Ladsgroup mailto:ladsgr...@gmail.com>>

What is exact time of the next deployment (it and he)?

If you want to catch it, join #wikimedia-wikidata on IRC. It was
great to follow it on D-day!

And what time you think is best to disable interwiki bots?

Xqt can modify the code, but pywiki is not deployed, it is updated
by bot owners, so there is no chance to focus it on one hour. For
this reason I would say to begin it after deployment of Wikibase as
otherwise one should do it at least 1 or 2 days before which would
cause a maintenance pause. Yes, people will try to remove iws and
some of them will be put back by bots.


___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] getting some stats for the Hungarian Wikipedia

[Nikola Smolenski]

On 28/01/13 15:39, Lydia Pintscher wrote:

Is anyone interested in getting us some stats for the deployment on
the Hungarian Wikipedia? There is a database dump at
http://dumps.wikimedia.org/backup-index.html from the 22nd of January
that could be used. I'm interested in the effect Wikidata had so far
on this one Wikipedia.


Not from dumps, but from Toolserver, I don't see some reduction in bot 
activity. Number of bot edits in last 12 months:


201201  61527
201202  48472
201203  3
201204  60875
201205  56364
201206  56483
201207  49836
201208  50862
201209  39235
201210  44943
201211  37492
201212  52815
201301  40258

___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Multilingual categories on Wikimedia Commons

[Nikola Smolenski]

I have worked on Commons a bit and was already thinking how could 
Wikidata be integrated into it.


On 21/01/13 12:55, Denny Vrandečić wrote:

I'd think it would be appropriate to spec out how these features should
work and get a consensus on such a plan. Think about questions like:
* how is it represented in the wikitext? I.e. do I categorize a picture
with [[Category:Dog]] or can I also write [[Kategorie:Hund]]?

> * how should this be displayed on a page?

I don't think category links would any longer be represented in 
wikitext, but each image description page would be a wikidata item.


Wikidata already has various de facto "statement groups" (I'm sorry I'm 
not up to the newest terminology so I'm not sure how are they called). 
The data in the groups are edited independently of each other, and also 
displayed in various ways. Right now, there are two groups: labels and 
wikilinks. Labels are displayed as article titles and only one label is 
displayed at the time, while wikilinks are displayed in a table and 
multiple wikilinks are displayed at once.


But there is no need to stick to this organization, and various wikis in 
various namespaces could have different statement groups that could be 
displayed in various ways. For example, it would be possible that, on 
Commons, in Image namespace, have three groups: image description, image 
properties, and image categories. Image description would be displayed 
and edited similar to Wikidata label: only in the current interface 
language. Image properties would be displayed and edited as wikidata 
properties will be. Image categories would be displayed and edited as 
categories.


Image metadata might tie into all of this as well: these would be 
special properties that are not directly editable but filled in on image 
upload.



* what about subcategorizing? How does this work?


Similarly, every category would be an item. Category titles in various 
languages would be handled exactly the same as Wikidata labels. A 
category would have its supercategories as properties.


About the only potential problem that I see is that in some cases 
categorization is made logically, and in some cases linguistically. For 
example, on Commons, [[:Category:Tree rings]] is a subcategory of 
[[:Category:Rings]] which makes sense in English language, but in 
Serbian language tree rings aren't called tree rings and no one would 
ever got the idea to categorize them as such or to search for them in 
that category.



* is it only about categories? What about image descriptions?


Multilingual image descriptions are a common occurence.


* what about the plenty of data that is already in Commons? Can this be
reused or replaced?


A lot of data in Commons is already very structured, so I believe it 
shouldn't be a problem to transfer it to another format. About the only 
problem that I see is the potential need for coexistence of raw wikitext 
and wikidata in the same namespace while the transition is occuring, but 
even that is solvable.


___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Update to time and space model

[Nikola Smolenski]

On 08/01/13 12:36, Denny Vrandečić wrote:

Location:



I'm not sure if we should be going that far, but there may be cases 
where longitude and latitude are known with different degree of 
accuracy, so multiple precisions might be needed.


___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Data values

[Nikola Smolenski]

On 20/12/12 11:26, Daniel Kinzler wrote:

First off: our target use case is Wikipedia infoboxes. Do you have examples and
numbers about the usage of such ancient units in infoboxes on wikipedia? If they
are not in main stream use there, I don't see why Wikidata would have to support
them.


I don't think old units are used a lot in Wikipedia infoboxes. But one 
use case is digitalization and importing of various datasets, and in 
some of them old units are used and will be needed.


___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Data values

[Nikola Smolenski]

On 19/12/12 15:23, Martynas Jusevičius wrote:

triplestore design as well as XSD datatypes. What's next, WikiQL
instead of SPARQL?


How did you guessed? Oo

___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Data values

[Nikola Smolenski]

On 19/12/12 15:33, Nikola Smolenski wrote:

On 19/12/12 12:23, Daniel Kinzler wrote:

I don't think we can sensibly support historical units with unknown
conversions,
because they cannot be compared directly to SI units. So, they
couldn't be used
to answer queries, can't be converted for display, etc - they arn't
units in any
sense the software can understand. This is a solvable problem, but
would add a
tremendous amount of complexity.


Ah, but they could still be meaningfully compared to each other. And if
approximate conversion is known, this could be still be used to make the
conversion so that the measure is converted and its uncertainty increased.

Just throwing more info here: there might also be cases where we could
have multiple competing conversions. Somewhat similar to units,
something that I would very much like to see is comparison of various
monetary values, adjusted for inflation or exchange rate. But then you
would have various estimates of inflation by various bodies and you
might want to compare by either of them (or a combination of them?).


Appropriate conversion might also depend on the item in question. For 
example, old censuses sometimes measure population not in people but in 
households. In some cases we might have the idea of how large a 
household is to give estimate of the population.


___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Data values

[Nikola Smolenski]

On 19/12/12 12:23, Daniel Kinzler wrote:

On 19.12.2012 08:34, Nikola Smolenski wrote:

What I wanted to say. Additionally, in some cases historical units are not
accurate or accurately known, so possibly we won't even be able to make the
conversion.


I don't think we can sensibly support historical units with unknown conversions,
because they cannot be compared directly to SI units. So, they couldn't be used
to answer queries, can't be converted for display, etc - they arn't units in any
sense the software can understand. This is a solvable problem, but would add a
tremendous amount of complexity.


Ah, but they could still be meaningfully compared to each other. And if 
approximate conversion is known, this could be still be used to make the 
conversion so that the measure is converted and its uncertainty increased.


Just throwing more info here: there might also be cases where we could 
have multiple competing conversions. Somewhat similar to units, 
something that I would very much like to see is comparison of various 
monetary values, adjusted for inflation or exchange rate. But then you 
would have various estimates of inflation by various bodies and you 
might want to compare by either of them (or a combination of them?).


___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Data values

[Nikola Smolenski]

On 19/12/12 08:53, Gregor Hagedorn wrote:

I agree. What I propose is that the user interface supports entering
and proofreading "10.6 nm" as "10.6" plus "n" (= nano) plus "meter".
How the value is stored in the data property, whether as 10.6 floating
point or as 1.6e-8 is a second issue -- the latter is probably
preferable. I only intend to show that scientific values are not


Perhaps both should be stored. 1.6e-8 is necessary for sorting and 
comparison. But 10.6 nm is how the user entered it, presumably how it 
was written in the source that the user used, how is it preferably used 
in the given field, and how other users would want to see it and edit it.


As an example, human height is commonly given in centimetres, while 
building height is commonly given in metres. So, users will probably 
prefer to edit the tallest person as 282cm and the lowest building as 
2.1m even though the absolute values are similar.


___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Data values

[Nikola Smolenski]

On 18/12/12 16:52, Denny Vrandečić wrote:

Thank you for your comments, Marco.
2012/12/18 Marco Fleckinger mailto:marco.fleckin...@wikipedia.at>>
IMHO it would be make sense to have something hybrid. The datatype
for geolocation should accept something like a NAN-value for
optional altitudes. But it should also be possible to use altitudes
without longitude and latitude.


Why would it make sense to have both? What is the altitude in the
geolocation good for? Is there an example in Wikipedia where it is or
would be used, and where a property of its own would not be better?


While at it, why not separate longitude and latitude? There are items 
that only have one, f.e. http://en.wikipedia.org/wiki/Prime_meridian



IMHO it would make sense to use the [[International System of
Units]] for internal storage. It is not consequently used in other
realms, not even in the German spoken countries (PS vs. kW for
cars). Maybe it would be possible to use small scripts (such as
WP-templates) to transcalc values, which can easily be developed by
the community.

Internally we would translate it, yes, otherwise the numbers would not
be comparable. But for editing we need to keep the unit of the source /
of the editor, or else we will loose precision.


What I wanted to say. Additionally, in some cases historical units are 
not accurate or accurately known, so possibly we won't even be able to 
make the conversion.


___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Link FA/GA

[Nikola Smolenski]

On 01/12/12 20:17, Bináris wrote:

Can or will Wikidata handle Link FA / Link GA? Or will the Wikipedias
handle it in the old way? Will that fit into the system?



Right now, the Wikipedias are able to handle it in the old way. It is 
planned that in the future Wikidata will include information about 
article status, this feature is called "article badges".


___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] changing wikidata-item properties with multilingual labels

[Nikola Smolenski]

On 15/08/12 15:03, Gregor Hagedorn wrote:

Basically what Daniel proposed is, that it would be best practice that
for every string that refers to a concept, event, thing, person,
unless the editor is certain about item identity, a new wikidata item
entity should be created.

I could imagine this as a possible and perhaps elegant solution. My
concern is the handling of unknown identity and a workflow towards
improved identity recognition, not a discussion string versus item.


In the proposed case, would there be a problem with creating a "human 
name" entity that would not be a person and linking to that? If it is 
confirmed that certain link to this entity is a known person, it could 
be simply changed.




smime.p7s
Description: S/MIME Cryptographic Signature
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] changing wikidata-item properties with multilingual labels

[Nikola Smolenski]

On 14/08/12 22:57, Gregor Hagedorn wrote:

I would prefer if the decision whether entity-identity is known or
whether only a name-string or other label is known, should be left to
the Wikidata editor community, and not prescribed by the software.


I'm afraid that this will not be really possible in practice, since 
there is no support for multilingual strings. If you want to display a 
mayor name in multiple languages, you will have to link to an entity.




smime.p7s
Description: S/MIME Cryptographic Signature
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] watching Wikidata changes that affect my wiki

[Nikola Smolenski]

On 14/08/12 09:28, Amir E. Aharoni wrote:

2012/8/14 Nikola Smolenski:

On 14/08/12 08:57, Amir E. Aharoni wrote:

2012/8/14 Nikola Smolenski:

I believe it should be possible to alleviate this problem to an extent by
introducing automatic transcription between languages and specifying what
language the mayor's "default" name is in. If automatic transcription
gets
it wrong, it could still be overriden when someone enters the name in
another language.


It is guaranteed to be profoundly broken. The above-mentioned Hebrew
names will be transliterated as<'mrm mcn'>   (the apostrophes are part


Would it? How many Hebrew names are there that are spelled "עמרם"? If the
transliteration software knows it's a human name it can transliterate it as
"Amram".


What you say is kinda true, but in practice it's much more
complicated. I worked for a few years in a company that makes software
that does this and I was the lead developer. There are two software
packages that do it for Hebrew, they are proprietary and very
expensive. It's not that making a Free package is impossible, but you
need a team for every language that has such problems, you need
several full time people to maintain the words, and what's worst is
that most words have six or so possible pronunciations. Sure,
crowdsourcing in Wikidata may change that, but it's too early to talk
about this.

AFAIK the situation is even worse in Arabic, which is a much bigger
language than Hebrew.

What I'm getting at is, again, that some limited helping
transliteration may be OK, but it must not be automatically
propagated. Naïve people may think that that's how the name is


For Hebrew, Arabic and a few similar cases. In a large number of 
language combinations we will not have such problems.




smime.p7s
Description: S/MIME Cryptographic Signature
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] watching Wikidata changes that affect my wiki

[Nikola Smolenski]

On 14/08/12 08:57, Amir E. Aharoni wrote:

2012/8/14 Nikola Smolenski:

I believe it should be possible to alleviate this problem to an extent by
introducing automatic transcription between languages and specifying what
language the mayor's "default" name is in. If automatic transcription gets
it wrong, it could still be overriden when someone enters the name in
another language.


It is guaranteed to be profoundly broken. The above-mentioned Hebrew
names will be transliterated as<'mrm mcn'>  (the apostrophes are part


Would it? How many Hebrew names are there that are spelled "עמרם"? If 
the transliteration software knows it's a human name it can 
transliterate it as "Amram".



of the transliteration!) and. The same problem applies to
Arabic, Punjabi and many other languages. Without manual maintenance
it will perpetuate horrendously wrong transliteration.

Some very limited auto-transliteration is OK, but just as a
suggestion. I was actually going to write an email about that. But it
must not be automatic all the way and propagate to all wikis.


On the other hand, we don't even need transliteration for a huge amount 
of languages which keep the spelling from the original language, and 
then there is a somewhat smaller number of languages where 
transliteration is unambiguous. In these cases we may use 
transliteration freely.




smime.p7s
Description: S/MIME Cryptographic Signature
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] watching Wikidata changes that affect my wiki

[Nikola Smolenski]

On 13/08/12 16:37, Amir E. Aharoni wrote:

The problem is that the mayor's name can be written differently in
other languages. I didn't actually try running it myself, but as far
as I understand, Wikidata supports translating names. But what happens
when the mayor changes? It is likely that the name will be updated in
the language spoken in that city. At that point articles in Wikipedia


This is correct, albeit in general mayor will not be a name, but a link 
to an item, and the item will contain his name (in various languages).



in other languages will probably show the name in the language of the
city, which may be unreadable.

Let's take Haifa for an example. Its previous mayor was:
he: עמרם מצנע
en: Amram Mitzna
ru: Амрам Мицна
hr: Amram Micna
etc.

Now it changes to:
he: יונה יהב

And then suddenly all the articles about Haifa in all the languages
will show the mayor's name as "יונה יהב", which most people won't be
able to read. Maybe the Wikidata community will develop some kind of a
policy that will discourage adding names in local scripts without any
translation to a more common script. Maybe at some point software
should even show a warning if somebody tries to do it.


I believe it should be possible to alleviate this problem to an extent 
by introducing automatic transcription between languages and specifying 
what language the mayor's "default" name is in. If automatic 
transcription gets it wrong, it could still be overriden when someone 
enters the name in another language.


Relevant bugs are https://bugzilla.wikimedia.org/show_bug.cgi?id=37461 
and https://bugzilla.wikimedia.org/show_bug.cgi?id=36430




smime.p7s
Description: S/MIME Cryptographic Signature
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Wikidata Transclusions

[Nikola Smolenski]

On 14/06/12 17:49, jmccl...@hypergrove.com wrote:

"Wikidata publishing infoboxes and Wikipedias using them is again the
client-server model."

Not sure where this chestnut is coming from. Transclusion is as close to
client-server as my cooking is to being gourmet!

There's NO API. so I don't understand your commenst at all, sorry.


No, you do not. I'm afraid you will have to take my word for it.



smime.p7s
Description: S/MIME Cryptographic Signature
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Wikidata Transclusions

[Nikola Smolenski]

On 14/06/12 00:39, jmccl...@hypergrove.com wrote:

Transclusion is surely fundamental to wiki application design. The
[[wikidata]] proposal by contrast is a client-server API, such things an
artifact of the 20th century. What is the point of it here?

Ultimately the problem you're grappling with is not just just about
infoboxes, it's about *anything* other than article text that has
multilingual requirements. For instance, the same *pie chart* is to be
shared among wikipedias, the only difference being the graph's title,
key and other labels... [[wikidata]] is today doing format=table, later
other formats. That's alot to handle in an API.


I don't think Wikidata will ever do other formats. Wikidata will only 
export pure data.



So, it's highly advised the client-server API approach be scrapped. At a
minimum, it's outdated technology, for good reasons. Instead, wikidata
should *publish* infoboxes that are happily cached on wikidata servers.
That's the best performance that can possibly be had.


Wikidata publishing infoboxes and Wikipedias using them is again the 
client-server model. And if Wikidata publishes infoboxes, pie charts and 
the like, THAT will complicate the API, not the current approach. Not to 
mention that Wikipedias have and want to have different infobox designs.




smime.p7s
Description: S/MIME Cryptographic Signature
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Wikidata Transclusions

[Nikola Smolenski]

On 14/06/12 07:20, Bináris wrote:

Are you sure that Wikipedias will always agree in population and
religion charts?


They can always override it locally.



smime.p7s
Description: S/MIME Cryptographic Signature
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Forwarded from Wikidata-test-client

[Nikola Smolenski]

On 08/06/12 21:52, Lydia Pintscher wrote:

On Fri, Jun 8, 2012 at 6:19 PM, Friedrich Röhrs
  wrote:

is there any way to find the correspoding page on the repo
(http://wikidata-test-repo.wikimedia.de/) for a page on the client
(http://wikidata-test-client.wikimedia.de/wiki/) ?


I don't think there is a good way yet for users.


The code in includes/WBCSkinHandler.php should do that, but for some 
reason it doesn't work on the demo system. Probably a slight touch could 
fix the problem.




smime.p7s
Description: S/MIME Cryptographic Signature
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] [wikidata-intern] Request for comments: syntax for including data on client wikis (aka how to make infoboxes)

[Nikola Smolenski]

On 23/05/12 13:53, Daniel Kinzler wrote:

On 23.05.2012 13:14, Nikola Smolenski wrote:

{{#data:color|item=Blah}} - this uses item linked to "Blah" in the local 
language.
{{#data:color|item=en:Blah}} - this uses item linked to "Blah" in English 
language.
{{#data:color|id=q123}} - this uses item with ID q123.
{{#data:Blah->color}} - we can do this since ->  can't appear in a page name -
this is my favorite of course :)


3) no explicit reference/use of the item at all. Just use parser function to
access properties, and specify the item if need be (otherwise, the page's "own"
item is used).


That is what I am suggesting, yes.


The parser function should be able to override itself by template parameters - I
believe it is possible to do this.


That makes the hair in my neck stand up :)


 From the user point of view or the implementation point of view? :)


Both. And as Gabriel pointed out, something like this would be really bad for
things like the visual editor, snippet caching, etc.


How is it different from overwriting value of a data item in the initial 
suggestion?



If there will be no pre-loading, disregard this.


Don't know what you mean by "pre"... the item will be loaded into memory once,
whenever the page is rendered. It would typically be loaded from a local cache
(e.g. in the database), an http request to the repo while rendering would be
annoyingly slow.


This is what I mean. An alternative would be to load every assertion 
from the DB at the time it is requested.


There is also a hybrid possibility: load what we expect to be used (this 
would probably be entire item in the default language), then load every 
remaining assertion when it is requested.


A quick calculation: infobox at http://en.wikipedia.org/wiki/Berlin has 
some 2K of parameters, and the article exists in 200 languages, so that 
would amount to 400K of data. Of course, not all data will be 
translatable or translated, but still 100K does not seem unreasonable.



Except that it's not wrapped in any HTML. Perhaps there should be an option to
{{#data-value}} to turn that off completely, using form=plain or some such.


Now shorten #data-value to #data, use form=plain as the default and that's it :)


Yes, we can drop the "simple" parameter-like syntax an use parser functions for
everything.

The remaining question is... how do i specify the item i want to get the
property from (if it's not the default)? Will be be assigning local names to


Well, this is what we we talked about above, at the start of this 
e-mail, right?



items, using #load-data or some such? Or will we just use the item id directly -
which would probably be a parameter, so we'd end up with something like this:

   {{#property:population|item={{{item-id|*}

...with * representing the default (the page's "own") item. Not very pretty,


The default would be used if item is not specified. I'm not sure I 
understand why are you introducing this.



I would try not to introduce new syntax if it is not necessary. How about this:

[[wikidata:Berlin]] - links to en.wikidata.org/wiki/Berlin
[[wikidataid:q1234]] - links to en.wikidata.org/id/q1234
{{canonicalurl:wikidata:Berlin|action=edit}} - links to edit page

All of this syntax already exists, is widely used and could be introduced
without additional coding :)


You'd have to do  [[wikidata:id/{{#property:id}}|the data item]].


Again, I don't see why.


But this doesn't work for edit links. Especially not if the edit link is
supposed to invoke the on-site ajax editing interface How to you generate a
link/button for doing that?


Yes, for that you have to have a new parser function, similar to 
canonicalurl above.




smime.p7s
Description: S/MIME Cryptographic Signature
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] [wikidata-intern] Re: Request for comments: syntax for including data on client wikis (aka how to make infoboxes)

[Nikola Smolenski]

On 23/05/12 13:19, Daniel Kinzler wrote:

On 23.05.2012 13:14, Nikola Smolenski wrote:

If we assume that in practice #data-template is usually going to be wrapped into
a template, what's the point of having it at all? Do you see any technical
reasons for it?


How else do you pass a complex object to a template and make its properties show
up as template parameters?


I don't? The template requests what it needs when it needs it.

Perhaps both approaches could be done, and we will see what people will 
use in practice.




smime.p7s
Description: S/MIME Cryptographic Signature
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] [wikidata-intern] Request for comments: syntax for including data on client wikis (aka how to make infoboxes)

[Nikola Smolenski]

On 22/05/12 15:49, Daniel Kinzler wrote:

On 22.05.2012 15:15, Nikola Smolenski wrote:

Rather, I would include a template normally and use a parser function within the
template to access the data.


So, that would be option (2) from above.


So, instead of {{{data}}} there would be {{#data:}}, instead of {{{data.color}}}
there would be {{#data:color}}, instead of {{{data.color(ACME_SURVEY_2010)}}}
there would be {{#data:color|ref=ACME_SURVEY_2010}} and so on.


How would you specify which item {{#data:}} refers to, in case it's not the
articles "default" item? How would you pass multiple items to a template?


I see multiple possibilities:

{{#data:color|item=Blah}} - this uses item linked to "Blah" in the local 
language.
{{#data:color|item=en:Blah}} - this uses item linked to "Blah" in 
English language.

{{#data:color|id=q123}} - this uses item with ID q123.
{{#data:Blah->color}} - we can do this since -> can't appear in a page 
name - this is my favorite of course :)


Every template or article could read any item without the need to pass it.


If this is needed, one can always use the {{#data-value}} function with
source=ACME_SURVEY_2010 (perhaps 'ref' is better than 'source').


By the way, in some cases a single assertion might have multiple 
sources, also a single source might support multiple assertions, this 
needs to be taken into account.



The parser function should be able to override itself by template parameters - I
believe it is possible to do this.


That makes the hair in my neck stand up :)


From the user point of view or the implementation point of view? :)


I see that there is need to also select desired content language (for example, a
lot of infoboxes display name of the topic in the content language and in the
topic's language(s)). This has the potential to introduce additional problems,
of course.


The parameter syntax is the simply way to access property values. For all fancy
needs, like picking the language, use {{#data-value}} instead. Basically, the
{{{data.foo}}} syntax is just a shorthand for the more powerful {{#data-value}}
stuff.


The problem is that we are going to pre-load all the data of an item 
before the article renders, right? So now we need to pre-load all the 
data in all the languages.


If there will be no pre-loading, disregard this.


Except that it's not wrapped in any HTML. Perhaps there should be an option to
{{#data-value}} to turn that off completely, using form=plain or some such.


Now shorten #data-value to #data, use form=plain as the default and 
that's it :)



 {{#data-link:data|the data item}}

Why not the usual interwiki syntax of [[wikidata:data|the data item]]?


because "data" is not an identifier for that item on the wikidata repo. YOu
would have to use something like:

[[wikidata:/id/{{{data.id}}}|the data item]]

But constructing edit links this way is very cumbersome. The main intend for
this function is to make it easy to provide an edit link in the infobox.

But perhaps a different syntax should be used for this. After all, the edit link
would, with javascript enabled, not really be a link, but a button to activate
the on-site editing feature.


I would try not to introduce new syntax if it is not necessary. How 
about this:


[[wikidata:Berlin]] - links to en.wikidata.org/wiki/Berlin
[[wikidataid:q1234]] - links to en.wikidata.org/id/q1234
{{canonicalurl:wikidata:Berlin|action=edit}} - links to edit page

All of this syntax already exists, is widely used and could be 
introduced without additional coding :)




smime.p7s
Description: S/MIME Cryptographic Signature
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] [wikidata-intern] Re: Request for comments: syntax for including data on client wikis (aka how to make infoboxes)

[Nikola Smolenski]

On 22/05/12 16:49, Daniel Kinzler wrote:

On 22.05.2012 16:37, Nikola Smolenski wrote:

Of course not, however, for example, I believe a major use of Wikidata would be
for citation templates, so
{{cite|id=q1234}}{{cite|id=q2345}}  is better than
{{#data-template:cite|id=q1234}}{{#data-template:cite|id=q2345}}.


The bibliography use case is on our minds, but not in our road map. It's beyond
phase 3. So i'm reluctant to spend too much thought on it right now.

However, you can always just wrap another template around
{{#data-template:cite|id={{{id}, respectively just make {{cite}} call
{{#data-template:cite-format|id={{{id}


If we assume that in practice #data-template is usually going to be 
wrapped into a template, what's the point of having it at all? Do you 
see any technical reasons for it?




smime.p7s
Description: S/MIME Cryptographic Signature
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] [wikidata-intern] Re: Request for comments: syntax for including data on client wikis (aka how to make infoboxes)

[Nikola Smolenski]

On 22/05/12 16:28, Daniel Kinzler wrote:

Do you think putting a parser function call directly into the article would be
considered far worse than a simple template call? I.e. is

   {{Infobox}}

really so much better than

   {{#data-template:Infobox}}

?


Of course not, however, for example, I believe a major use of Wikidata 
would be for citation templates, so 
{{cite|id=q1234}}{{cite|id=q2345}} is better than 
{{#data-template:cite|id=q1234}}{{#data-template:cite|id=q2345}}.




smime.p7s
Description: S/MIME Cryptographic Signature
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Request for comments: syntax for including data on client wikis (aka how to make infoboxes)

[Nikola Smolenski]

On 22/05/12 13:47, Daniel Kinzler wrote:

I have created a first preliminary draft of how data items from the Wikidata
repository may be accessed and rendered on the client wiki, e.g. to make 
infoboxes.

https://meta.wikimedia.org/wiki/Wikidata/Notes/Inclusion_syntax

It would be great if you could have a look and let us know about any
unclarities, omissions, or other flaws - and of course about your ideas of how
to do this.


As could perhaps be guessed, I have a lot of comments :)

Including Items in an Article:

{{#data-template:Infobox
|data_item=q332211
|data_param=stuff
|foo=some value
|stuff.color=green
}}

I see no reason for creating a new parser function for inclusion of 
templates. Also, this syntax would not allow a template to draw data 
from more than one item, which would probably be a requirement in phase3.


Rather, I would include a template normally and use a parser function 
within the template to access the data.


So, instead of {{{data}}} there would be {{#data:}}, instead of 
{{{data.color}}} there would be {{#data:color}}, instead of 
{{{data.color(ACME_SURVEY_2010)}}} there would be 
{{#data:color|ref=ACME_SURVEY_2010}} and so on.


One advantage is that commonly used syntax is always used, instead of 
inventing new syntax (as for the reference in this example).


Another advantage, this way would make data usable directly in article 
text, if that is wanted.


The parser function should be able to override itself by template 
parameters - I believe it is possible to do this.


Unrelated to the above,

"This will return the value of the color property, in the page's content 
language, as plain text."


I see that there is need to also select desired content language (for 
example, a lot of infoboxes display name of the topic in the content 
language and in the topic's language(s)). This has the potential to 
introduce additional problems, of course.


Formatting Functions:

{{#data-value:data.color}}

form
Specifies in what form rendered, that is, in which HTML element the 
value should be wrapped.


span: wrap in  tags, use  tags for parts
div: wrap in  tags, use  tags for parts
li: wrap in  tags, use  tags for parts

I don't like this at all, since it limits the number of possibilities, 
introduces yet another syntax parallel to HTML.


Yet, I don't see anything much better. A half-baked idea is to leave it 
to the client wikis to create their data display templates that could be 
used to format data appropriately.


(I see Jérémie's email now, and see that we came independently to some 
of the same conclusions :) )


{{#data-values}}:

But this is of course an even worse problem.

{{#data-link:data|the data item}}

Why not the usual interwiki syntax of [[wikidata:data|the data item]]?



smime.p7s
Description: S/MIME Cryptographic Signature
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] We have a demosystem

[Nikola Smolenski]

On 21/05/12 13:18, Jan Kučera wrote:

Are there some docs describing client-syntax etc. (eg. how it actually works)?


http://www.mediawiki.org/wiki/Extension:WikibaseClient#Usage



smime.p7s
Description: S/MIME Cryptographic Signature
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] WikiData/Scrum Item #47 (was: Re: Forward of moderated message)

[Nikola Smolenski]

On Sat, 2012-04-28 at 21:43 +0200, Gerard Meijssen wrote:
> So far the discussion is about interwiki links in a Wikipedia context.
> There are however interwiki links in a Wiktionary context as well.
> They are often linked from Wikipedia and they often have information
> in languages we do not have an article in or information in languages
> we do not have a Wikipedia in.

Perhaps it would be the easiest to simply add the ability to link to
other projects, like we now have links to Wikipedia. This would include
Wiktionary, Wikisource, perhaps even external projects like OSM. Some
items would have links only to Wikipedia ("Berlin, a city in Germany"),
some to Wiktionary ("Berlin, a word of English language"), some to both
("Meh").



___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l