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] 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 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] [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] [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)

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

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

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

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

[Daniel Kinzler]

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?

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

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

[Gregor Hagedorn]

On 23 May 2012 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 think I might have adressed that in my comment on the wiki. See
there, but essentially I believe it is technically equally valid, and
from a usability and community adoption standpoint far preferable, to
simply support a syntax to adress properties of the complex object,
and have the resolver of this syntax automatically pull the entire
complex wikidata object (of which the property is a part) into a
cache, so that subsequent calls to properties are returned from the
cached object.

I look forward to have this analyzed by Daniel. Obviously there are
some extra things that need to be added, but also other things simply
go away painlessly... Can you write a advantage/disadvantage
comparison on the wiki, Daniel, to be commented upon?

Gregor

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

Relaying the conversation between gregor and me on
:

~
In general, I am surprised that on the one hand you seem to be deeply modifying
the template parameter calls (by providing structured parameters and methods to
resolve the structure) while at the other hand you don't allow the data items to
be called from within a template. You present approach seems to force either
each page that calls an infobox template to be modified (replacing the
{{infoboxZZZ |foo=some value}} with a {{#data-template:infoboxZZZ |foo=some
value }} call, or, which is more likely, each infoboxZZZ to be renamed to
infoboxZZZ-Inner and a new infoboxZZZ be created that calls the infoboxZZZ-Inner
wrapped in the #data-template.

While this is possible to do, it seems a some overhead in the (very likely)
scenario that an infobox display a mixture of wikidata-stored information and
page-injected information, i.e. both the wrapper, and the inner, real infobox
template need to pass the right parameters.

I guess that approach is taken because of caching concerns. However, given that
the template parameter calls have to be overloaded for wikidata anyways: is it
possible to silently, whenever calling a item.color as a parameter, to always
cache the entire item, so that the next call for item.size would already be in
memory?

Some random notes on the text, which may or may not be useful:

The explanation is somewhat hard to follow, because the section "Including
Items in an Article" requires an understanding of what the object is that is
passed to a template. Normally templates do not get structured parameters
passed, so this was surprising to me. You invent this newly and a new syntax.
Perhaps the explanation of this general mechanism could come first.
Like other commentators, I am sceptical about using the dot for this. Both
dots and hyphens are legal in the grammar for RDF property names
(http://www.w3.org/TR/REC-xml/#NT-Name). Slashes or hashes are not and would be
a better choice in my opinion.
"This implies that the client wiki tracks": please define "client wiki".
Also I cannot follow the rest of the sentence, perhaps elaborate.

--G.Hagedorn (talk) 21:15, 22 May 2012 (UTC)


It was indeed intentional to always do item formatting via a template, since
that seems to be the way people usually handle the formatting of uniform data
objects. This can easily be amended by introducing a parser function that makes
a data object available in the present scope, instead of passing it to a
template. As to forcing all pages using the infobox templates to be modified:
technically, you don't have to do that, because you can easily wrap the call to
#data-template in the original template and use some other template to do the
actual formatting. But in practice, the page will have to be edited anyway. It's
pointless to use data from Wikidata if we don't remove all the infobox
parameters from the article pages.
re caching: all data items are cached. Twice, actually: once persistently in
a local database table, and once per request, in memory.
re your text notes: thanks for the input, I'll improve that. I think I'm
going to rewrite the entire proposal, now that I have gotten some feedback. --
Duesentrieb (talk) 15:55, 23 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)

[Gregor Hagedorn]

Thanks for the response Daniel!

>    It was indeed intentional to always do item formatting via a template, 
> since
> that seems to be the way people usually handle the formatting of uniform data
> objects.

I have no objections about this, I only comment on making the passing
of a complex object (the parts of which can then be accessed) into the
template the standard way of combining wikipedia templates with
wikidata.

> This can easily be amended by introducing a parser function that makes
> a data object available in the present scope, instead of passing it to a
> template.

To me the present calling convention then become redundant. I believe
simpler is better then. Yes, each such call would need some optional
parameters in rare cases (like using the non-default object) but that
can easily be handled inside the template then.

> As to forcing all pages using the infobox templates to be modified:
> technically, you don't have to do that, because you can easily wrap the call 
> to
> #data-template in the original template and use some other template to do the
> actual formatting.

(Yes, thats what I meant with the ...-Inner templates)

> But in practice, the page will have to be edited anyway. It's
> pointless to use data from Wikidata if we don't remove all the infobox
> parameters from the article pages.

True, I did not think of that. But my question would be: do you want
to display to the majority of users a standard template call where
some data is locally injected via a standard template parameter syntax
and some data is "magically" inherited from wikidata (I believe yes)
or do you want to force everyone to learn the new syntax with a yet
more strange and complex function call?

If the first, I see only disadvantages in introducing the necessity
for a "wrapping" function and nested templates (for which the locally
injected parameters have to always synced) at all.

Can we try to develop a scenario where the whole system works through
directly accessing properties through what you call (if I understand
you correctly) the "parser function that makes a data object available
in the present scope, instead of passing it to a template.".

(Note: I am not sure why, if you modify the template parameter
resolution syntax to allow access to structured objects, you need a
parser function here instead of directly using the syntax -- is there
a technical reason that it is not possible to overload template
paramter syntax handling in mediawiki outside an outer parser
function?)

>    re caching: all data items are cached. Twice, actually: once persistently 
> in
> a local database table, and once per request, in memory.

Good. So there should be no need to make the pass the whole-data-item
to a nested template function at all. I think. I can guess that there
are good reason to think differently, but so far I am stuck to my view
:-)

Gregor


On 23 May 2012 17:56, Daniel Kinzler  wrote:
> Relaying the conversation between gregor and me on
> :
>
> ~
> In general, I am surprised that on the one hand you seem to be deeply 
> modifying
> the template parameter calls (by providing structured parameters and methods 
> to
> resolve the structure) while at the other hand you don't allow the data items 
> to
> be called from within a template. You present approach seems to force either
> each page that calls an infobox template to be modified (replacing the
> {{infoboxZZZ |foo=some value}} with a {{#data-template:infoboxZZZ |foo=some
> value }} call, or, which is more likely, each infoboxZZZ to be renamed to
> infoboxZZZ-Inner and a new infoboxZZZ be created that calls the 
> infoboxZZZ-Inner
> wrapped in the #data-template.
>
> While this is possible to do, it seems a some overhead in the (very likely)
> scenario that an infobox display a mixture of wikidata-stored information and
> page-injected information, i.e. both the wrapper, and the inner, real infobox
> template need to pass the right parameters.
>
> I guess that approach is taken because of caching concerns. However, given 
> that
> the template parameter calls have to be overloaded for wikidata anyways: is it
> possible to silently, whenever calling a item.color as a parameter, to always
> cache the entire item, so that the next call for item.size would already be in
> memory?
>
> Some random notes on the text, which may or may not be useful:
>
>    The explanation is somewhat hard to follow, because the section "Including
> Items in an Article" requires an understanding of what the object is that is
> passed to a template. Normally templates do not get structured parameters
> passed, so this was surprising to me. You invent this newly and a new syntax.
> Perhaps the explanation of this general mechanism could come first.
>    Like other commentators, I am sceptical about using the dot for this. Both
> dots and hyphens are

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

[Daniel Kinzler]

On 23.05.2012 23:57, Gregor Hagedorn wrote:
> Can we try to develop a scenario where the whole system works through
> directly accessing properties through what you call (if I understand
> you correctly) the "parser function that makes a data object available
> in the present scope, instead of passing it to a template.".

This seems to be everyone's preference, even though it feels kind of icky to me.
Oh, well :) I'll rework the draft on that basis soon.

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

[Gregor Hagedorn]

> This seems to be everyone's preference, even though it feels kind of icky to 
> me.
> Oh, well :) I'll rework the draft on that basis soon.

I look forward to it. Maybe it runs against some wall, but then we
have a better basis for comparison.

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