[Wikidata-l] Teilnahme Wikidata

[pre . web]

(Once Wikidata seems to be a german project, I'll write this mail also in
german language. Let me know if I'm wrong, so I would write again in
english)
 Hallo
 Ich bin sehr an der Teilnahme vom Wikidata-Projekt interessiert, kämpfe
aber noch mit der richtigen Anlaufstelle, bzw. Informationsbeschaffung.
Natürlich habe ich die Informationen unter
http://meta.wikimedia.org/wiki/Wikidata
(http://meta.wikimedia.org/wiki/Wikidata) sowie einigen der Unterseiten
gelesen. Eine Anfratge unter #wikimedia-wikidata
(irc://irc.freenode.net/wikimedia-wikidata) wurde obschon etwa 30
Teilnehmer online waren nicht beantwortet. Deshalb nun meine Anfrage über
die Mailingliste.
 Soweit ich gesehen habe, gibt es eine Liste in der man sich als Helfer
eintragen lassen kann (http://meta.wikimedia.org/wiki/Wikidata/Volunteers
(http://meta.wikimedia.org/wiki/Wikidata/Volunteers)). Allerdings sind mir
die Aufgaben nicht ganz klar. Was genau man also z.B. unter "Interwiki to
wikidata transition", "Importing data to Wikidata" oder "Infobox
transition" zu verstehen hat. Solange ich darüber nicht im klaren bin,
kann ich mich leider nicht eintragen. Könnte mir jemand beschreiben was
genau man unter diesen drei Begriffen zu verstehen hat, wie die Arbeit
daran genau aussieht und ab wann man mit der Arbeit loslegen kann?
 Ich würde mich gerne in irgendeiner Form der Dateneingabe-/übernahme
beteiligen. Entweder die direkte Dateneingabe/-import, oder die nötigen
Vorbereitungen dazu, damit der Import automatisiert werden kann. Welche
Arbeit wäre da für mich passend?
 Freundliche Grüsse
 Tobias

___
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)

[Daniel Kinzler]

On 22.05.2012 22:56, Gabriel Wicke wrote:
>> Its hard to imagine how to achieve this nicely without using parser
>> functions. -- Duesentrieb (talk) 19:37, 22 May 2012 (UTC)
> 
> An alternative might be to return JSON from the parser function and let
> a Lua module, some other parser function or even a new templating
> construct handle the formatting.

Well, {{{data}}} already really *is* that JSON structure. I'm trying to come up
with exactly that new templating structure :)

-- daniel


-- 
Daniel Kinzler, Softwarearchitekt

Wikimedia Deutschland e.V. | Eisenacher Straße 2 | 10777 Berlin
http://wikimedia.de  | Tel. (030) 219 158 260

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 B. 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

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

[Daniel Kinzler]

On 22.05.2012 22:37, Gabriel Wicke wrote:
> {{{data.color}}} would be inaccessible to Lua templates, unless it is
> expanded as a parameter in a custom preprocessor frame and then passed
> by value to the Lua template. The custom preprocessor frame code would
> be specific to the current PHP preprocessor, and incompatible with other
> parsers.
> 
> A parser function call with explicit item parameter on the other hand
> would work as-is through the generic API- be it from Lua or Parsoid.

even though {{{data}}} wouldn't be text, but a complex data object that needs
special handling when evaluating it to wikitext?

-- daniel


-- 
Daniel Kinzler, Softwarearchitekt

Wikimedia Deutschland e.V. | Eisenacher Straße 2 | 10777 Berlin
http://wikimedia.de  | Tel. (030) 219 158 260

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 B. 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

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

[Gregor Hagedorn]

I added some comments on the wiki

___
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)

[Gabriel Wicke]

On 05/22/2012 09:39 PM, Daniel Kinzler wrote:
> the {{#data-value}} function lets you output all of these "parts" all at
> once (or separately, if you like), and lets you control aspects like the 
> format
> of the output using parameters. If you choose to output multiple parts at 
> once,
> {{#data-value}} can use its knowledge about the desired HTML form to do this
> nicely. E.g.
> 
>  
> {{#data-value:data.population|show=label,value,timestamp,source,indicators,edit|form=tr}}
> 
> would be rendered as
> 
>   
> Population
> 523,411
> 2010
> [1],[2]
> 
> [edit]
>   
> 
> Its hard to imagine how to achieve this nicely without using parser
> functions. -- Duesentrieb (talk) 19:37, 22 May 2012 (UTC)

An alternative might be to return JSON from the parser function and let
a Lua module, some other parser function or even a new templating
construct handle the formatting.

Gabriel


___
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)

[Gabriel Wicke]

On 05/22/2012 09:47 PM, Daniel Kinzler wrote:
> On 22.05.2012 21:27, Gabriel Wicke wrote:
>>> 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.
>>
>> This could even be simplified further to
>>
>> {{#data:{{{data_item}}}|color}}
>>
>> The syntax is admittedly longer, but would work as-is with alternate
>> parsers such as Parsoid or a generic parser function API in Lua. It
>> would also preserve referential transparency as far as possible, which
>> is good for finer-grained caching.
> 
> That's pretty much what I was doing with {{#data-value:data.color}}. Turning
> that into {{#data-value:{{{data}}}|color}} would actually be fine, though a 
> bit
> ugly. Perhaps it would even be nice to turn it around:
> {{#property:color|{{{data}.

Sure, both are fine with me. My concern is more about using the plain
parser function API without magic globals or custom preprocessor behavior.

> However, I'd still like to support the plain template parameter syntax with
> pseudo-parameters, e.g. {{{data.color}}} for retrieving the flat wikitext 
> value
> of the property.
> 
> Do you think that's ok? Or does it introduce complications with respect to 
> Lua, etc?

{{{data.color}}} would be inaccessible to Lua templates, unless it is
expanded as a parameter in a custom preprocessor frame and then passed
by value to the Lua template. The custom preprocessor frame code would
be specific to the current PHP preprocessor, and incompatible with other
parsers.

A parser function call with explicit item parameter on the other hand
would work as-is through the generic API- be it from Lua or Parsoid.

Gabriel


___
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)

[Gabriel Wicke]

On 05/22/2012 03:49 PM, Daniel Kinzler wrote:
> On 22.05.2012 15:15, Nikola Smolenski wrote:
> 2) alternatively, don't pass item from the article to the template at all.
> Instead, use parser functions for every access to an item property, and 
> specify
> the item id as a parameter if necessary. That would create a lot of 
> rundundancy
> and wouldn't allow "normal" template parameter syntax to be used to access 
> data
> properties.

You could still pass the data item to the template:

{{Infobox|di=q556677}}

and inside Template:Infobox:

{{#data:{{{di}}}|color}}

This is admittedly slightly more verbose.

On the other hand, It would also work in articles, and supports multiple
items in a single template. More importantly (to me), it is familiar to
current editors, compatible with alternate parsers (e.g. Parsoid) or a
generic Lua -> parser function API and makes it easier to implement
generic fragment caching.

Overall I'd prefer any magic-free and forward-compatible solution even
if it comes at the cost of small syntactic inconveniences.

Gabriel


___
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)

[Daniel Kinzler]

On 22.05.2012 21:27, Gabriel Wicke wrote:
>> 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.
> 
> This could even be simplified further to
> 
> {{#data:{{{data_item}}}|color}}
> 
> The syntax is admittedly longer, but would work as-is with alternate
> parsers such as Parsoid or a generic parser function API in Lua. It
> would also preserve referential transparency as far as possible, which
> is good for finer-grained caching.

That's pretty much what I was doing with {{#data-value:data.color}}. Turning
that into {{#data-value:{{{data}}}|color}} would actually be fine, though a bit
ugly. Perhaps it would even be nice to turn it around:
{{#property:color|{{{data}.

However, I'd still like to support the plain template parameter syntax with
pseudo-parameters, e.g. {{{data.color}}} for retrieving the flat wikitext value
of the property.

Do you think that's ok? Or does it introduce complications with respect to Lua, 
etc?

-- daniel

-- 
Daniel Kinzler, Softwarearchitekt

Wikimedia Deutschland e.V. | Eisenacher Straße 2 | 10777 Berlin
http://wikimedia.de  | Tel. (030) 219 158 260

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 B. 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

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

[Daniel Kinzler]

relaying more conversation between me an TMg on
:

~+
I don't really understand what all the formatting stuff is about. Why should we 
use

{{#data-value:data.color|form=span}}

instead of

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

Or worse, why should we use

{{#data-value:data.color|form=td|style=text-align: right;}}

instead of the wiki table syntax?

| style="text-align: right;" | {{#data-value:data.color}}

I think you should drop "form", "style" and "class". Simpler is better. --TMg
17:26, 22 May 2012 (UTC)

For the simple access you suggest above, the plain template parameter syntax
is provided, e.g. {{{data.color}}}, as in

{{{data.color}}}

but there are many aspects of rendering a property value that can not be
readily expressed in this syntax, for example, which language or precision and
unit to use for the output. Also, values often have qualifiers, such as the
source, accuracy, timestamp, etc. Lastly, there nedds to be a place for things
like indicators for disputes, edit links, etc.
the {{#data-value}} function lets you output all of these "parts" all at
once (or separately, if you like), and lets you control aspects like the format
of the output using parameters. If you choose to output multiple parts at once,
{{#data-value}} can use its knowledge about the desired HTML form to do this
nicely. E.g.

 
{{#data-value:data.population|show=label,value,timestamp,source,indicators,edit|form=tr}}

would be rendered as

  
Population
523,411
2010
[1],[2]

[edit]
  

Its hard to imagine how to achieve this nicely without using parser
functions. -- Duesentrieb (talk) 19:37, 22 May 2012 (UTC)

-- 
Daniel Kinzler, Softwarearchitekt

Wikimedia Deutschland e.V. | Eisenacher Straße 2 | 10777 Berlin
http://wikimedia.de  | Tel. (030) 219 158 260

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 B. 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

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

[Gabriel Wicke]

On 05/22/2012 03:16 PM, Nikola Smolenski wrote:
> 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.

This could even be simplified further to

{{#data:{{{data_item}}}|color}}

The syntax is admittedly longer, but would work as-is with alternate
parsers such as Parsoid or a generic parser function API in Lua. It
would also preserve referential transparency as far as possible, which
is good for finer-grained caching.

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

I'd strongly recommend against any magic like this, as it makes
templates even harder to understand and also harder to cache.

Gabriel


___
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)

[Daniel Kinzler]

On 22.05.2012 18:11, Helder Wiki wrote:
> On Tue, May 22, 2012 at 10:49 AM, Daniel Kinzler
>  wrote:
>> For the most part, I tried to keep the normal syntax for template parameters,
>> just introducing structured names (dots and colons). The syntax for
>> selection-by-reference-id is indeed a bit awkward. Perhaps we can just drop 
>> it.
>> If this is needed, one can always use the {{#data-value}} function with
>> source=ACME_SURVEY_2010 (perhaps 'ref' is better than 'source').
> 
> Whatever the choice is, woudn't it need to be translated to other languages?

As far as MediaWiki supports the localization of parameter names for parser
functions and tag extensions.

> Here it seems appropriated to ask the same as Jérémie:
> On Tue, May 22, 2012 at 10:08 AM, Jérémie Roquet  wrote:
>> v. What about lua? :)

There will be a Lua interface for calling parser functions. Using this, all
functionality is covered. Once we know more about the Lua bindings, we can come
up with a nicer interface.

-- daniel


-- 
Daniel Kinzler, Softwarearchitekt

Wikimedia Deutschland e.V. | Eisenacher Straße 2 | 10777 Berlin
http://wikimedia.de  | Tel. (030) 219 158 260

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 B. 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

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

[Helder Wiki]

On Tue, May 22, 2012 at 10:49 AM, Daniel Kinzler
 wrote:
> For the most part, I tried to keep the normal syntax for template parameters,
> just introducing structured names (dots and colons). The syntax for
> selection-by-reference-id is indeed a bit awkward. Perhaps we can just drop 
> it.
> If this is needed, one can always use the {{#data-value}} function with
> source=ACME_SURVEY_2010 (perhaps 'ref' is better than 'source').

Whatever the choice is, woudn't it need to be translated to other languages?

>> 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.
>
> Yes, this is kind of a nasty compromise.
>
> On the one hand, it would be extremely cumbersome to have to re-implement the
> table (and other) structures for representing property values with various
> qualifiers, not to speak of the rendering logic for these qualifiers 
> themselves.
>
> On the other hand, we want to allow template authors to integrate property
> values in different kinds of structures, like tables and lists.
>
> Note that with the help of the show=... parameters, template authors can still
> implement their own rendering of the value (or rather, statement) with all 
> it's
> parts, using one {{#data-value}} call for each one.

Here it seems appropriated to ask the same as Jérémie:
On Tue, May 22, 2012 at 10:08 AM, Jérémie Roquet  wrote:
> v. What about lua? :)

Best regards,
Helder

___
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)

[Daniel Kinzler]

On 22.05.2012 17:49, Helder Wiki wrote:
> The section
> https://meta.wikimedia.org/w/index.php?title=Wikidata/Notes/Inclusion_syntax#Accessing_Data_Fields_in_a_Template
> says "{{{data}}}...would evaluate to the label and description of the
> item... in the **page's content** language". But it should be noted
> that on some it will be necessary to allow a different language to be
> used (e.g. on ptwiki some data is written in Portuguese from Brazil
> and other is in Portuguese from Portugal, Angola, and so on). So it
> would be necessary to provide a way to specify the appropriate
> language.

Yes, of course. {{{data}}} is just a shorthand. If you want e.g. just the
description in Dutch, falling back to German, you could use #data-value to get 
it:

  {{#data-value:data.description|language=nl,de|form=plain}}

> Another thing: will we be able to translate the name "data" (e.g. to
> "dados") which appear on "{{#data-value:" "{{{data.color}}}",
> "data_item", "data_param" etc..?

There are three different things to translate here.

1) the name of the parameter used to pass the item to the template ("data" in
the example). You are free so choose it using the data_param option. The default
could indeed be localized, though changing that (be editing the respective
system message) is likely to break a lot of things in a very hard to understand 
way.

2) the name of the (well-known) parameters (options) for the proposed parser
functions, like data_item and data_param for the #data-template function. Since
#data-template is a parser  function, it will use MediaWikis standard mechanisms
for localizing parser functions. I'm pretty sure the name of the function can be
localized, and perhaps also the names of the parameters, I don't know. In any
case, this is a general mediawiki issue, not specific to wikidata.

3) the names of item properties, e.g. "color" in the "data.color" example. These
are properties defined and described on pages on the wikidata repository, and
they have localized names for display. If these localized names can also be used
to access the respective property, or if a stable, unique, unlocalized
identifier must be used, is still up for discussion. The problem with localized
identifiers is - if they change, they break a *lot* of things.


> Would it be possible to create a link having "action=edit" as text? E.g.:
> {{#data-link:data|action=edit|action=edit}}
> or
> {{#data-link:data|action=edit|action{{=}}edit}}

This is the general problem of passing a positional parameters that contain a
"=" to templates and parser functions. There are two common solutions:

  {{#data-link:data|action=edit|2=action=edit}}

and

  {{#data-link:data|action=edit|action=edit}}

Regards,
Daniel

-- 
Daniel Kinzler, Softwarearchitekt

Wikimedia Deutschland e.V. | Eisenacher Straße 2 | 10777 Berlin
http://wikimedia.de  | Tel. (030) 219 158 260

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 B. 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

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

[Daniel Kinzler]

Relying further conversation with TMg on the draft's talk page
:

4I'm a software developer, I know the dot syntax. However, I'm not sure
if it's appropriate here. Wikitext is no programming language, not even with all
the parser functions we have. It does not even look like JavaScript or C++.
Currently in template parameters like {{{Min.-max. height}}} neither dashes nor
dots nor spaces have a meaning. All I say is: If you choose a character why not
choose the dash? Again, this would be consistent with the HTML5 data-* 
attributes.
5I want to translate {{{data.color}}} to {{{Daten.Farbe}}} (or to
{{{Daten-Farbe}}} as argued above). Maybe I'm wrong and this is not important.
The question is: What part of the new syntax will be visible in articles? All
these parts must be translated.
6OK. Similar to the /doc, /sandbox and /testcases subpages we will
create a lot of /data-template subpages then. I think this is a good idea.

--TMg 15:30, 22 May 2012 (UTC)

4You asked "If you choose a character why not choose the dash?"
well, dashes and underscores are often used in property identifiers. If we used
them as our structuring element, they can not occur inside either the name of
the parameter that references the item, nor in the name of any property of the
item. So, the item can't have e.g. a pupulation-density parameter and, according
to your original point, shouldn't be using pupulation_density either (well, we
could use dashes as a structuring element and underscores i nthe name of
parameters and properties, but you didn't like that and it's visually far more
confusing than using dots). Anyway, I'm not desperate to use dots. I just think
dashes are worse. We can use slashes, how about it :)
5Ah, you want to translate the names of the item's properties. We
are considering to make this possible in the property definition in the wikidata
repository. We'll have to think about restrictions for those names (allow
dashes? dots? spaces?), and if and how they can be changed later (changing the
localized name would break a lot of things...).

It may save us a lot of trouble to require the use of unchanging
unique identifiers to the parameters, so nothing breaks when the translation is
changed. We'll have to maintain a localized "visible" name anyway, so we can
automatically provide labels for properties (oops, forgot to mention that in the
draft).

--Duesentrieb (talk) 15:55, 22 May 2012 (UTC)



-- 
Daniel Kinzler, Softwarearchitekt

Wikimedia Deutschland e.V. | Eisenacher Straße 2 | 10777 Berlin
http://wikimedia.de  | Tel. (030) 219 158 260

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 B. 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

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

[Helder Wiki]

The section
https://meta.wikimedia.org/w/index.php?title=Wikidata/Notes/Inclusion_syntax#Accessing_Data_Fields_in_a_Template
says "{{{data}}}...would evaluate to the label and description of the
item... in the **page's content** language". But it should be noted
that on some it will be necessary to allow a different language to be
used (e.g. on ptwiki some data is written in Portuguese from Brazil
and other is in Portuguese from Portugal, Angola, and so on). So it
would be necessary to provide a way to specify the appropriate
language.

Another thing: will we be able to translate the name "data" (e.g. to
"dados") which appear on "{{#data-value:" "{{{data.color}}}",
"data_item", "data_param" etc..?
In Portuguese and Spanish there is the word "data" with the meaning of
the english word "date":
http://en.wiktionary.org/wiki/data#Portuguese
It could be confusing not being able to translate this...

Would it be possible to create a link having "action=edit" as text? E.g.:
{{#data-link:data|action=edit|action=edit}}
or
{{#data-link:data|action=edit|action{{=}}edit}}
?

Best regards,
Helder
On Tue, May 22, 2012 at 8:47 AM, Daniel Kinzler
 wrote:
> Hello all
>
> 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.
>
> Getting this right is an important part of implementing phase 2 of the 
> Wikidata
> project, and so I feel it's important to start drafting and discussing early.
> Having a powerful but not overly complex way to create infoboxes etc from
> Wikidata items is very important for the acceptance of Wikidata on the clinet
> wikis, I believe.
>
> Thanks,
> Daniel
>
>
> --
> Daniel Kinzler, Softwarearchitekt
>
> Wikimedia Deutschland e.V. | Eisenacher Straße 2 | 10777 Berlin
> http://wikimedia.de  | Tel. (030) 219 158 260
>
> Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
> Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
> unter der Nummer 23855 B. 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

___
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)

[Daniel Kinzler]

On 22.05.2012 17:25, Platonides wrote:
> You might want in wikipedia: John Doe ended up the {{#data-value:
> item=123|param=Position/2012 Race|format=ordinal}} in the [[2012 Race]]
> out of {{#data-value:456|param=total-participants}}

It's a possible use case, but as a Wikipedia, I would like to avoid such things
in the prose part of an article, to keep the wikitext readable and editable.
Anyway, this kind of information either never changes, so the overhead of
referencing a data item is pointless, or changes frequently, in which case a
table or infobox is more useful for displaying it.

> Where item 123 could be {"name":"John Doe","Position\/2012 Race":42}
> for instance, and 456 {"name":"2012
> Race","country":"Germany","total-participants":1024}
> 
> Arguably, we might want to store instead John Doe position in the 2012
> Race item.

This is really a question about the data model, not the inclusion syntax.

Anyway, in my mind, this would be modeled like this:

* There's an item for John Doe, say Q23
* There's an item for the 2012 race, say Q42
* The race has a property "positions"
* "positions" is inherently multi-valued (i.e. multiple values don't indicate
alternatives, but are considered to be true all at once, and multiple different
values can be ascribed to a single source).
* Each entry in positions is a reference to a contestor (e.g. Q23) with their
rank and perhaps time or whatever as qualifiers.

Alternatively, Q42 could even be about the race in general, and the entries in
the "positions" property could be qualified with a point in time. Wikidata
editors would be free to choose either solution (or your solution, or whatever).

We (me, Denny and Markus Krötsch) have discussed this kind of "qualified
multi-value properties" quite extensively and came to the conclusion that using
the pattern above, we can model most scenarios sanely. Another typical example
would be ethnic groups of a country, as percentage of the population, by year
and source.

-- daniel


-- 
Daniel Kinzler, Softwarearchitekt

Wikimedia Deutschland e.V. | Eisenacher Straße 2 | 10777 Berlin
http://wikimedia.de  | Tel. (030) 219 158 260

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 B. 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

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

[Daniel Kinzler]

On 22.05.2012 17:12, Bryan Burgers wrote:
> What I didn't see in the proposal was a way to get data multiple levels deep.
> Will this be possible?

Not directly. Wikibase/Wikidata doesn't provide nested items. Only item 
references.

> Use case:
> 
> Q100 is data about an association football game. Maybe Q100 has 
> team1-score="3",
> team2-score="2", referenced by {{{data.team1-score}}} and 
> {{{data.team2-score}}}
> respectively (or whatever modifications have been made already due to previous
> discussion). Great.

ok

> Q100 also might have links to the teams: team1=[Q200], team2=[Q201]. Q200 has
> the name of the team: name="Melchester Rovers". Can we get the name of the 
> team?
> {{{data.team1.name }}}? Some other syntax? Not 
> available?

Not like this. Either, the teams get passed into the templates as separate
items, e.g. as data_team_1 and data_team_2. But that would require the called to
specify the teams explicitly, even though they are already in the item Q100
about the match.

It could be made nicer if the template is allowed to load additional items into
its scope on its own accord, as I discussed in my reply to Nikola earlier:

  {{#load-data:{{{data.team1}


Note that I don't really like the idea, but if we need it to cover real world
use cases, then we can easily do this, I think.

The only difficulty here is to decide what exactly {{{data.team1}}} should
return in case {{{data.team1}}} is an item reference. In the present use case,
it would need to return the item id, while when used "normally" in wikitext, it
would be nice if it would return a wiki link to the corresponding local wiki
page (if that exists). We may then need to somehow indicate that in this
context, we want the actual id, perhaps like this:

  {{#load-data:{{{data.team1#id}

This is not very pretty, though. Maybe it would be cleaner to use something like
this:

  {{#load-data:{{#data-value:data.team1|form=raw

-- daniel


-- 
Daniel Kinzler, Softwarearchitekt

Wikimedia Deutschland e.V. | Eisenacher Straße 2 | 10777 Berlin
http://wikimedia.de  | Tel. (030) 219 158 260

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 B. 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

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

[Platonides]

On 22/05/12 16:28, Daniel Kinzler wrote:
>> What if for some
>> > reason we want a template that accesses several items? Is it
>> > reasonable to assume that there will always be an item that links to
>> > every needed item for a given template?
> In the Wikipedia use case which is the basis for our spec, yes. Because the
> items are per definition describing the same thing that the Wikipedia page
> describes.

You might want in wikipedia: John Doe ended up the {{#data-value:
item=123|param=Position/2012 Race|format=ordinal}} in the [[2012 Race]]
out of {{#data-value:456|param=total-participants}}

Where item 123 could be {"name":"John Doe","Position\/2012 Race":42}
for instance, and 456 {"name":"2012
Race","country":"Germany","total-participants":1024}

Arguably, we might want to store instead John Doe position in the 2012
Race item.


PS: No magically loaded template parameters, please.

___
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)

[Bryan Burgers]

What I didn't see in the proposal was a way to get data multiple levels
deep. Will this be possible?

Use case:

Q100 is data about an association football game. Maybe Q100 has
team1-score="3", team2-score="2", referenced by {{{data.team1-score}}} and
{{{data.team2-score}}} respectively (or whatever modifications have been
made already due to previous discussion). Great.

Q100 also might have links to the teams: team1=[Q200], team2=[Q201]. Q200
has the name of the team: name="Melchester Rovers". Can we get the name of
the team? {{{data.team1.name}}}? Some other syntax? Not available?

Bryan Burgers
___
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)

[Daniel Kinzler]

Hi Dennis

On 22.05.2012 16:58, Dennis Tobar wrote:
> Hi everyone:
> 
> I have an issue related with permissions and "template syntaxes"
> 
> I read in the draft on Meta about data_item
[...]
> Is this data input available for everyone users?, pe: if any user adds
> or changes this parameter, are there any problem with the link to data
> parameters?.

It's just a template parameter. Anyone can change it. Changing it can do
whatever to the page, depending on the template and the parameters.

> Sorry if I misunderstand this parameter, but I'm thinking on sysop's
> work... only revert vandalism and the consequences of change some
> linked data :(

Vandalizing the data_item parameter would be the equivalent of vandalizing the
language links or infobox parameters. Easy to detect and revert.

Relying information about changes performed directly in the wikidata repository,
so that vandalism there can be detected, is a much more tricky problem... but a
different topic.

-- daniel

-- 
Daniel Kinzler, Softwarearchitekt

Wikimedia Deutschland e.V. | Eisenacher Straße 2 | 10777 Berlin
http://wikimedia.de  | Tel. (030) 219 158 260

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 B. 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

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

[Neil Harris]

On 22/05/12 15: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}

-- daniel




Which is absolutely the right way to do it. In general, I think that 
access to the semantic layer should always be done in this way: the 
extra layer of indirection is a form of implementation hiding, allowing 
the semantic parts of the system to be maintained and redefined without 
having to change the user interface and thus have to ripple edits 
through into thousands of articles.


-- Neil



___
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)

[Dennis Tobar]

Hi everyone:

I have an issue related with permissions and "template syntaxes"

I read in the draft on Meta about data_item

The data_item parameter can be used to specify the data item to
include directly by id. Per default, the item associated with the
present article via its article links is used. This implies that the
client wiki tracks with pages uses which item, to allow the relevant
pages to be rerendered when the data item changes in the repository.

Is this data input available for everyone users?, pe: if any user adds
or changes this parameter, are there any problem with the link to data
parameters?.

Sorry if I misunderstand this parameter, but I'm thinking on sysop's
work... only revert vandalism and the consequences of change some
linked data :(

Regards.

On Tue, May 22, 2012 at 7:47 AM, Daniel Kinzler
 wrote:
> Hello all
>
> 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.
>
> Getting this right is an important part of implementing phase 2 of the 
> Wikidata
> project, and so I feel it's important to start drafting and discussing early.
> Having a powerful but not overly complex way to create infoboxes etc from
> Wikidata items is very important for the acceptance of Wikidata on the clinet
> wikis, I believe.
>
> Thanks,
> Daniel
>
>
> --
> Daniel Kinzler, Softwarearchitekt
>
> Wikimedia Deutschland e.V. | Eisenacher Straße 2 | 10777 Berlin
> http://wikimedia.de  | Tel. (030) 219 158 260
>
> Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
> Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
> unter der Nummer 23855 B. 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



-- 
Dennis Tobar Calderón
Ingeniero en Informática UTEM
Licenciado en Ciencias de la Ingeniería UTEM

___
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)

[Daniel Kinzler]

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}

-- daniel


-- 
Daniel Kinzler, Softwarearchitekt

Wikimedia Deutschland e.V. | Eisenacher Straße 2 | 10777 Berlin
http://wikimedia.de  | Tel. (030) 219 158 260

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 B. 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

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

[Daniel Kinzler]

Relying questions TMg posted on the draft's talk page
:

Localization, syntax and more questions

1)Currently we are using the hash syntax for parser functions like {{#if:
and {{#expr:. I'm not sure if it's a good idea to use the same syntax for the
Wikidata stuff. As you said the output of e.g. {{#data-value: can not be used as
an input for e.g. {{#if:. Isn't this confusing?
2)Maybe it would be more confusing to invent a new syntax?
3)Why does data-template use a dash but data_item and data_param are using
underscores? Please use dashes everywhere. Be consistent with the HTML5 data-*
attributes.
4)Why not using the same syntax inside the templates? For example,
{{{data-color}}} instead of {{{data.color}}}?
5)Are we free to use localized template names and parameter names for the
new infobox syntax? I consider this very, very important. Here is an example why
this is so important. We need a clearly defined point where the parameter names
can be translated to create a localized version of the same template.
6)Overall, I'm not sure if the new infobox syntax is meant to be used in
articles or in other templates? Can we keep our existing localized templates and
use the new syntax in these templates? The new syntax should allow this.

--TMg 14:23, 22 May 2012 (UTC)

Hi TMg, thanks for your input!

1)these are parser functions. And you can use their output as input for
other parser functions, they are just riddled with a lot of HTML and so pretty
useless as conditions, etc. But I will rephrase the relevant sentence - the
output of #data-value etc can be used as the seconds or third parameter to #if
just fine, it just doesn't make sense to use it as the first parameter (the
condition).
2)yes :) Also much harder to implement.
3)ok, will use slashes instead of underscores in parameter names.
4){{{data.color}}} is a structured identifier, meaning the property
"color" of the object "data". Dots (and colons) are commonly used in programming
languages to denote sub-entities (parts, properties, members, etc). in contrast,
data-template or data-param are not structured - they are just compound phrases.
The do not denote sub-entities.
5)Template names are completely custom. It's not that you can localize
them - you will have to provide your own. As to the parameters supported by the
parser functions... they will use whatever mechanism exists for localizing the
parameter names of parser functions. I don't know if MediaWiki supports it. If
MediaWiki supports it, Wikidata/Wikibase supports it.
6)The intention is to use {{#data-template:whatever}} in the article and
{{#data-value:data.foo}} in the template. If you want to hide the
{{#data-template}} stuff, you can wrap another template around it: {{Whatever}}
would do {{#data-template:whatever-format}}, and whatever-format would contain
the actual formatting logic.

HTH -- Duesentrieb (talk) 14:44, 22 May 2012 (UTC)


-- 
Daniel Kinzler, Softwarearchitekt

Wikimedia Deutschland e.V. | Eisenacher Straße 2 | 10777 Berlin
http://wikimedia.de  | Tel. (030) 219 158 260

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 B. 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

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] [wikidata-intern] Re: Request for comments: syntax for including data on client wikis (aka how to make infoboxes)

[Daniel Kinzler]

On 22.05.2012 15:08, Jérémie Roquet wrote:
> I've some questions about the design proposed in this draft. I'm not
> sure these are actual issues, but I prefer to be sure ;-)
> 
> i. It seems to me that the proposed design implies that any access to
> data is done through a template transclusion, which could be fine for
> the given example (ie. infoboxes — though I'll raise another issue
> below, see ii.) but AFAIU forbids direct use of data in an article. Is
> this a desirable limitation? Or did I miss something?

I considered this a small price to pay (it's an uncommon use case, as the
experience with SMW shows - people use templates for this sort of thing).

But it's easy enough to overcome this limitation, see me reply to Nikola.

> ii. I understand that only one item can be included at once (either by
> using the data_item attribute or the article links). 

Only one item can be formated by a given template call. Multiple items can be
included on the same page, using the same or different templates for formatting.

> What if for some
> reason we want a template that accesses several items? Is it
> reasonable to assume that there will always be an item that links to
> every needed item for a given template?

In the Wikipedia use case which is the basis for our spec, yes. Because the
items are per definition describing the same thing that the Wikipedia page
describes.

Even for other use cases, I can hardly imagine when multiple items should be
passed to a single template. Templates are made to provide uniform formatting
for objects with similar properties. They are essentially views on specific
types of items.

But again, this limitation is easy enough to overcome, see my reply to Nikola.

> iii. Articles on current wikis use templates named (eg.) “{{Infobox…”.
> Shouldn't it be a prerequisite for templates using Wikidata to (be
> able to) keep the same name, so that:

The templates can have any name, wikidata/wikibase doesn't care. "infobox" was
just an example. There can be any number of such templates on the client wikis,
for formating different things in different ways.

>  - we don't have to run bots on every single article only to prepend
> “#data-template:” but just have to update the template? Arguably, we
> would have to edit the articles anyway to remove attributes that are
> handled by Wikidata; just to be sure.

Editing of every article *will* be necessary. I see no way past this. Whether
that edit introduces a simpler template rederence, or a parser function call, is
yet to be decided.

>  - people don't massively reject the transition to Wikidata because of
> the /visible/ syntax change.

Well, there will be massive changes to the article, to wit, removal of all the
infobox parameters.

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}}

?

I would actually prefer the latter, because it is more obvious, less magic
happening invisibly in the background.

But if need be, it's easy enough to hide that call: if the Infobox template is
smart, and when called without any parameters, calls {{#data-template:Infobox}}.
So in the article, you'd just see {{Infobox}}.

The same can of course also be done by using a "top level" template for hiding
the parser function (e.g. Infobox) separate from the real template (e.g.
Infobox-format or whatever), which would be used with
{{#data-template:Infobox-format}} by the Infobox template.

> iv. Per i., ii. and iii., wouldn't it be desirable to have some syntax
> to access an item without relying on template transclusion? 

As i said in i., i think that's a rare use case. However, it's simple enough to
provide this ability, see my reply to Nikola.

> This would
> enable us to:
>  - use data in an article without having to write a template first (solves 
> i.);

Hm, actually - this might be nice for using values from the item inline in the
article text. But do we really want to encourage that?

>  - write templates that can get as many items as they need, either
> from the transcluding page or /by themselves/ (solves ii.);

Well, I don't like magic going on in the background, so I don't really like
templates fetching item data by themselves.

But if need be, my suggestion to provide a {{#load-data}} function that puts an
item into the current scope (be it the page or a template) would solve this too.

>  - update the existing templates to Wikidata without having to edit
> the articles and without visible changes from the template user's
> perspective — except for what is handled by Wikidata, of course
> (solves iii.).

This is always possible. Keep the current template as is, move the actual
formating logic to another template, make the original template call the
{{#data-template}} function.

> v. What about lua? :)

Parser functions are available for use from Lua, afaik. Once we know more about
how Lua wil

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

[Daniel Kinzler]

On 22.05.2012 15:47, Jeroen De Dauw wrote:
> Hey,
> 
> Great writeup, after doing a quick read, I agree with most stuff, but have 
> some
> minor remarks:
> 
>>  {{{data.color(ACME_SURVEY_2010)}}}
> 
> This suggests that we do not want property names with brackets in them.
> Sometimes an item might have 2 distinct properties with the same name (I can't
> think of any example right now but things this does occur) in which case you
> need to add some extra stuff in their name to distinguish them. WP often uses
> brackets for this when it happens with page names, so it does not seem to far
> fetched that people would want to use that here as well.

Yea, as I said in my reply to Nikola: it's probably best to just drop that 
syntax.

>> {{#data-link:|action=edit|the data item}}
> 
> I really don't like providing an empty value to have it use the default. 
> Should
> be possible to just omit the parameter altogether. Also, I think it's nice to
> have the arguments be order independent. So using parameter names for 
> everything
> except the identifier might be good. Right now it's for example impossible to
> have action=edit or similar at it's start.

Well, that would mean that the link text can't be a positional parameter, so
we'd have to use {{#data-link:action=edit|text=the data item}}. A bit un-pretty,
but then, this stuff will only show up in templates anyway.

So yea, agreed.

-- daniel


-- 
Daniel Kinzler, Softwarearchitekt

Wikimedia Deutschland e.V. | Eisenacher Straße 2 | 10777 Berlin
http://wikimedia.de  | Tel. (030) 219 158 260

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 B. 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

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

[Daniel Kinzler]

On 22.05.2012 15:15, Nikola Smolenski wrote:
> 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.

Basically, we need a way to pass a complex data object as a parameter to a
template. If we don't have that, we have two alternative choices:

1) assign per-page variables to items, e.g. make {{{thingy}}} available in the
article after a call to {{#load-data|thingy}}. Then you can use
{{Infobox|data={{{thingy}, as usual. But I think this "global variables"
approach is ugly and confusing, at least when stuff is loaded from inside 
templates.

2) alternatively, don't pass item from the article to the template at all.
Instead, use parser functions for every access to an item property, and specify
the item id as a parameter if necessary. That would create a lot of rundundancy
and wouldn't allow "normal" template parameter syntax to be used to access data
properties.

To me, this seems natural, because it behaves like a function call. Being able
to pass complex objects as parameters directly would of course be better still.

Actually, if the template in question wants to pass the data object on to
another template, we kind of need this...

> Also, this syntax would not allow a template to draw data from more than one
> item

Correct. This could be simple enough to overcome, though I can't think of a
*nice* way off hand. Off the top of my head, I'd do something like this:

 ...
 |data_item_2=q556677
 |data_param_2=other_stuff
 |data_item_3=q114488
 |data_param_3=more_stuff
 ...

or even:

 |data_item=q332211 as stuff
 |data_item_2=q556677 as other_stuff
 |data_item_3=q114488 as more_stuff


> which would probably be a requirement in phase3.

No, it's not. phase3 is about automatic listings, which require a different
syntax anyway. Also, in a list, all items would use the same template and the
same rendering options. No need for the ability to pass multiple items to a
single template.

> 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?

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

For the most part, I tried to keep the normal syntax for template parameters,
just introducing structured names (dots and colons). The syntax for
selection-by-reference-id is indeed a bit awkward. Perhaps we can just drop it.
If this is needed, one can always use the {{#data-value}} function with
source=ACME_SURVEY_2010 (perhaps 'ref' is better than 'source').

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

Yes, that's also something that is bothering me. I would propose for this case
to implement option (1) from above: use {{#load-data|stuff}} to make the item
available as {{{stuff}}} in the current scope (preprocessor frame).

That's kind of like saying "pass the item to me" instead of "pass the item to
the template".

> 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 :)

> 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.

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.

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.

> 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 any

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

[Jeroen De Dauw]

Hey,

Great writeup, after doing a quick read, I agree with most stuff, but have
some minor remarks:

>  {{{data.color(ACME_SURVEY_2010)}}}

This suggests that we do not want property names with brackets in them.
Sometimes an item might have 2 distinct properties with the same name (I
can't think of any example right now but things this does occur) in which
case you need to add some extra stuff in their name to distinguish them. WP
often uses brackets for this when it happens with page names, so it does
not seem to far fetched that people would want to use that here as well.

> {{#data-link:|action=edit|the data item}}

I really don't like providing an empty value to have it use the default.
Should be possible to just omit the parameter altogether. Also, I think
it's nice to have the arguments be order independent. So using parameter
names for everything except the identifier might be good. Right now it's
for example impossible to have action=edit or similar at it's start.

Cheers

--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil.
--
___
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] Request for comments: syntax for including data on client wikis (aka how to make infoboxes)

[Jérémie Roquet]

Hi Daniel, everyone,

2012/5/22 Daniel Kinzler :
> 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

Great!

> 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.
>
> Getting this right is an important part of implementing phase 2 of the 
> Wikidata
> project, and so I feel it's important to start drafting and discussing early.
> Having a powerful but not overly complex way to create infoboxes etc from
> Wikidata items is very important for the acceptance of Wikidata on the clinet
> wikis, I believe.

I've some questions about the design proposed in this draft. I'm not
sure these are actual issues, but I prefer to be sure ;-)

i. It seems to me that the proposed design implies that any access to
data is done through a template transclusion, which could be fine for
the given example (ie. infoboxes — though I'll raise another issue
below, see ii.) but AFAIU forbids direct use of data in an article. Is
this a desirable limitation? Or did I miss something?

ii. I understand that only one item can be included at once (either by
using the data_item attribute or the article links). What if for some
reason we want a template that accesses several items? Is it
reasonable to assume that there will always be an item that links to
every needed item for a given template?

iii. Articles on current wikis use templates named (eg.) “{{Infobox…”.
Shouldn't it be a prerequisite for templates using Wikidata to (be
able to) keep the same name, so that:
 - we don't have to run bots on every single article only to prepend
“#data-template:” but just have to update the template? Arguably, we
would have to edit the articles anyway to remove attributes that are
handled by Wikidata; just to be sure.
 - people don't massively reject the transition to Wikidata because of
the /visible/ syntax change.

iv. Per i., ii. and iii., wouldn't it be desirable to have some syntax
to access an item without relying on template transclusion? This would
enable us to:
 - use data in an article without having to write a template first (solves i.);
 - write templates that can get as many items as they need, either
from the transcluding page or /by themselves/ (solves ii.);
 - update the existing templates to Wikidata without having to edit
the articles and without visible changes from the template user's
perspective — except for what is handled by Wikidata, of course
(solves iii.).

v. What about lua? :)

Best regards,

-- 
Jérémie

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

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

[Daniel Kinzler]

Hello all

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.

Getting this right is an important part of implementing phase 2 of the Wikidata
project, and so I feel it's important to start drafting and discussing early.
Having a powerful but not overly complex way to create infoboxes etc from
Wikidata items is very important for the acceptance of Wikidata on the clinet
wikis, I believe.

Thanks,
Daniel


-- 
Daniel Kinzler, Softwarearchitekt

Wikimedia Deutschland e.V. | Eisenacher Straße 2 | 10777 Berlin
http://wikimedia.de  | Tel. (030) 219 158 260

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 B. 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

Re: [Wikidata-l] mockups for linking Wikipedia articles up for feedback

[Lydia Pintscher]

On Tue, May 8, 2012 at 11:46 AM, Lydia Pintscher
 wrote:
> Heya folks :)
>
> We've worked on mockups for how we think linking of articles between
> different Wikipedias should work with Wikidata. You can find the
> mock-ups and explanations here:
> https://meta.wikimedia.org/wiki/Wikidata/Notes/Storyboard_for_linking_Wikipedia_articles
> It'd be great if you could have a look and give feedback either here
> or on the discussion page on meta.

Just for your information: We will have to rework these mock-ups now
that the universal language selector is coming:
http://blog.wikimedia.org/2012/05/21/introducing-designs-for-the-universal-language-selector/
  I'll let you know when we have new mock-ups to show and discuss.


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