On 22/05/12 16:28, Daniel Kinzler wrote: Of course not, however, for example, I believe a major use of Wikidata would be for citation templates, so <ref>{{cite|id=q1234}}</ref><ref>{{cite|id=q2345}}</ref> is better than <ref>{{#data-template:cite|id=q1234}}</ref><ref>{{#data-template:cite|id=q2345}}</ref>.

On 22/05/12 15:49, Daniel Kinzler wrote: 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

On 23.05.2012 13:14, Nikola Smolenski wrote: 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.

On 23 May 2012 13:19, Daniel Kinzler &lt;daniel.kinzler(a)wikimedia.de&gt; wrote: 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

Thanks for the response Daniel! 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. 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. (Yes, thats what I meant with the ...-Inner templates) 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?) 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 &lt;daniel.kinzler(a)wikimedia.de&gt; wrote: > Relaying the conversation between gregor and me on > <https://meta.wikimedia.org/wiki/Talk:Wikidata/Notes/Inclusion_syntax#Various_notes>: > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 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 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. -- --------------------------------- Dr. G. Hagedorn +49-(0)30-8304 2220 (work) +49-(0)30-831 5785 (private) http://www.linkedin.com/in/gregorhagedorn https://profiles.google.com/g.m.hagedorn/about This communication, together with any attachments, is made entirely on my own behalf and in no way should be deemed to express official positions of my employer. It is intended only for the person(s) to whom it is addressed. Redistributing or publishing it without permission may be a violation of copyright or privacy rights.

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

On 22.05.2012 17:25, Platonides wrote: 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. 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.

On 05/22/2012 03:16 PM, Nikola Smolenski wrote: 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. I'd strongly recommend against any magic like this, as it makes templates even harder to understand and also harder to cache. Gabriel

On 05/22/2012 09:47 PM, Daniel Kinzler wrote: Sure, both are fine with me. My concern is more about using the plain parser function API without magic globals or custom preprocessor behavior. {{{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

On 05/22/2012 11:52 PM, Daniel Kinzler wrote: {{{data}}} won't be accessible to Lua or Parsoid. {{#data:q12345|somevalue}} on the other hand would be accessible through the regular parser function API. Gabriel

On 05/23/2012 01:57 PM, Daniel Kinzler 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. Gabriel

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

I added some comments on the wiki

Thank you Daniel, the new proposal seems to be a great aggregation of the discussion results. I like it a lot. A few short comments: * I would drop the Section "Changing the Default item". This is syntactic sugar (meaning, everything that can be done with the #data-item function can also be done without, especially within templates, by using template variables). But it might be tricky as, once the default item is changed within a template, it probably stays changed when we come back from the template, and this might have undesirable side effects. It basically adds a global variable to the page, and we need careful about how using it. This can be avoided by simply dropping the #data-item function. * The section "Coalescing values" is very interesting, but I think it needs a bit more work and wider discussion. AFAIK usually such values are not coalesced, but rather just listed (which would be covered by the section "Multiple values"). * The selection {{#property:population|item=id/q12345}} is ambiguous with {{#property:population|item=en/Germany}} since "id" is also a site code / language code. My first thought would be to drop the id/ in the first case, but I would prefer if in this case we would default to the current site (i.e., if, on the en.wp we could use {{#property:population|item=Germany}} without the "en/"). The second suggestion thus would be to use {{#property:population|id=q12345}} in the first case). Thanks for the great work, and keeping the discussion together. Cheers, Denny 2012/5/29 Daniel Kinzler &lt;daniel.kinzler(a)wikimedia.de&gt; -- Project director Wikidata Wikimedia Deutschland e.V. | Obentrautstr. 2 | 10963 Berlin Tel. +49-30-219 158 26-0 | http://wikimedia.de 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.

Thanks a lot Daniel for the update! I think this is great progress. Picking on the point Denny raised: With respect to the #data-item function: Even after reading your explanation I share some of Denny's concern. You are certainly right, that at present there is a clear solution. However, is this solution defined to be stable in the light of ongoing restructured of mediawiki? Is "current preprocessor frame" (which does not say anything to me) something that will always be present, even if mediawiki might in the end use a completely new parser? If yes, then I only see the problem of explaining the scope-definition slgihtly better. I agree with Daniel that aggregation or enumeration functionality is a must. I am slightly unhappy with the term Coalescing, because it seems to me misleading. E.g. the SPARQL and other programming language sense covers only part of what seems to be addressed here, see e.g. http://www.w3.org/TR/sparql11-query/#func-coalesce http://en.wikipedia.org/wiki/Null_coalescing_operator enumeration) would be clearer to me. I wonder whether it can be restricted to enumeration initially. However, I do support a functionality of directly output multiple values rather than forcing complex template programming recursion etc. ---- My own point, slightly more generic than this discussion: Whenever you use "data item" or "item data" (both forms exist, with "item data" seemingly being an abbreviation for "data item data" ;-) ), I start to think "what was this?" - the snak, the topic, the property values? "Topic" seems to be an excellent replacement for data item - with the added benefit of tying into topic maps. Gregor PS: 1. Note: you define preferred values, but later you switch to undefined "strong", which may or may not be a synonym. I suggest to drop the notion of "strong" and continue to argue with preferred. 2. Please run a spelling checker, it is distracting to read at the moment. but content goes over form, or course!

Hi Daniel, I am convinced if you can explain: the scope of this setting will always be identical to template parameters. For example, it will not be inherited if a template calls another template. Yes I know. I just mentioned it because I was experiencing myself being confused here -- just as an example. If you think there a chance to discuss the data model with respect to how the thing is being called, please open a discussion and I will gladly comment. I do respect your constraints in what you can discuss when. Gregor

On 05/29/2012 05:12 PM, Daniel Kinzler wrote: Both the PHP preprocessor and Parsoid rely on template expansions being purely functional for a single parser pass (see for example line 118ff in Preprocessor_DOM.php). This means that a full expansion subtree can be reused / cached if the parameters match. It is possible to add scoped variables, but we'd have to carefully consider the implications for caching, implementation complexity and usability. Gabriel

On 05/29/2012 06:33 PM, Daniel Kinzler wrote: This is not true for subtemplates of such a wrapper template, unless you completely disable caching for those or handle expansion yourself. One problem I see is that the value of the variable in a local scope would change during execution. Parsoid expands templates and parser functions in parallel, so you would get non-deterministic behavior depending on the order of execution. Gabriel

On 29.05.2012 18:58, Gregor Hagedorn wrote: Well, conceptually, I'd say that a template works on whatever was the default item for the caller - that's actually consistent, not breaking any assumptions. It would be more confusing to have it otherwise, imho. But as Gabriel points out, this is nasty to implement, because it constitutes "context" apart from the actual 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.

https://meta.wikimedia.org/w/index.php?title=Wikidata/Notes/Inclusion_synta… Just to be clear, will the default be the content language **and its fallbacks**?