Re: [Wikidata-l] Request for comments: syntax for including data on client wikis (aka how to make infoboxes)
On Wed, May 23, 2012 at 9:33 AM, Gabriel Wicke wi...@wikidev.net wrote: I don't really like this global variable business at all. Much of the ugliness above disappears when the id is mandatory: {{#data:{{id}}|color}} or (if you prefer): {{#data:color|{{id If it is missing, simply display an error and let the user fix it. Cache invalidation can be precise by usage (not necessarily the entire page) and correctly handles multiple data items per article. The system is also directly compatible with Lua and Parsoid. ...and inside of a Lua module, the ugly things could just be stored in a local variable, coudn't they? ___ 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)
Hi Daniel, everyone, 2012/5/22 Daniel Kinzler daniel.kinz...@wikimedia.de: 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
Re: [Wikidata-l] Request for comments: syntax for including data on client wikis (aka how to make infoboxes)
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 span tags, use span tags for parts div: wrap in div tags, use span tags for parts li: wrap in li tags, use span 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)
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] Request for comments: syntax for including data on client wikis (aka how to make infoboxes)
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)
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. span{{#data-value:data.population|show=label,value,timestamp,source,indicators,edit|form=tr}}/span would be rendered as tr tdPopulation/td td523,411/td td2010/td tda href=#src23[1]/a,a href=#src23[2]/a/td tda title=disputed href=...img src=...//a/td td[a title=edit href=...edit/a]/td /tr 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)
I added some comments on the wiki ___ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l