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 will bind into MediaWiki, we can think about nice shorthands and pretty syntax.

Thanks for your input!

-- daniel

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

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

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

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?

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.

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

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

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.

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

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

On 23.05.2012 12:53, Gabriel Wicke wrote:

On 05/22/2012 11:52 PM, Daniel Kinzler wrote:

...

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?

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

So, you prefer a solution where the item to use is specified by id whenever a property of that item is to be accessed? In that case, I'd indeed prefer

{{#property:population|item=id/q12345}}

or just

{{#property:population}}

when using the page's "own" item.

But if the id comes from a template parameter, things get annoying:

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

(where "*" would mean "use the page's default item)

This is very ugly, especially if you have to do it 20 or 50 times (for every property).

A possible solution would be to assign local names to items:

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

What do you think?

On Wed, May 23, 2012 at 9:33 AM, Gabriel Wicke wicke@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?

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

Relying further conversation with TMg on the draft's talk page https://meta.wikimedia.org/wiki/Talk:Wikidata/Notes/Inclusion_syntax:

4 I'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. 5 I 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. 6 OK. 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)

4 You 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 :) 5 Ah, 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)

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

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 http://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

On 22.05.2012 17:49, Helder Wiki wrote:

The section https://meta.wikimedia.org/w/index.php?title=Wikidata/Notes/Inclusion_syntax... 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&#61;edit}}

Regards, Daniel

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> <td>Population</td> <td>523,411</td> <td>2010</td> <td><a href="#src23">[1]</a>,<a href="#src23">[2]</a></td> <td><a 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

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

On 29.05.2012 12:03, Denny Vrandečić wrote:

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

Yes, that's correct. I still think it would be quite useful, but we could makr it as obsolete.

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.

No, this is not a problem if implemented as described in the spec: the default item would be changed for the current *scope*, not the page. The scope is basically the current preprocessor frame, which is the mechanism by which "local" things like template parameters are managed. The scope of the "default item" would be the same as the scope for template parameters: the current template call, if any. After returning from the template, the default item would be beck to what it was before invoking the template.

Introducing a global variable into the page would indeed be very problematic. If it's not possible to do this based on the preprocessor frame, it would indeed be better to just drop this feature.

Do you hjave a suggestion how this could be made more clear in the draft?

• 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").

This would be quite bad, I think. It would mean that you can't use {{#property}}... directly at all, because the behavior of this would simply be undefined in cases where there are multiple equally strong statements. You'd have to use {{#property-values}} with an appropriate "row" template for every property. Very annoying.

You are correct that coalesced values would often be lists in the sense of plain text comma separated list. This would be the default for all data types that can not be combined in a more specific way (e.g. as ranges or using a max or min), for example for text values, sources, etc.

We definitely have to specify what {{#property}} will do if there are multiple equally strong statements associated with the property. That is, some type of coalescing needs to take place, even if it's trivial (e.g. always just use the first statement and ignore the rest).

If we don't use proper coalescing but just silently ignore additional, potentially conflicting statements, we will be hiding disputes and inconsistencies instead of making them obvious. This is especially important in places where multiple values were not expected, so it would be particularly bad to require the use of the rather awkward {{#property-values}} mechanism (or, in Lua, loops) in order to see disagreeing 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).

You are correct that this is ambiguous. This ties directly into the pending discussion about how to link to items from wikitext. In any case, the syntax to refer to items in {{#property}} calls should be the same we also use to refer to items using the normal interwiki syntax. That is, if we use [[wikidata:id/q12345]] we should also use {{#property|item=id/q12345}}, and if we use [[wikidata:en/Foo}}]] we should also use {{#property|item=en/Foo}}.

For interwiki links (and also for wiki-text links inside Wikidata, for use on discussion pages, etc) we need a single, unambiguous path-like syntax for addressing items. Using different parameters in parser functions and urls (like item vs. id) or similar tricks will not save us. We'll have to use prefixes.

So, since "id" could also be a language code, how about "item/q12345" or " ISO qid/12345" (qid is reserved for local use by ISO 639-3) or even "/q12345" or "*/q12345"?

-- daniel

PS: perhaps the key parts of this discussion should go into the draft as editorial notes?

Thanks for your comments, Gregor!

On 29.05.2012 15:48, Gregor Hagedorn wrote:

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.

They may not exist in the current form, but a "local scope" will always exist. Template parameter names are local the the current template "call". They have to be managed somewhere, so mediawiki will always have some way to manage data attached to the "current call", and we can tie into that to put the "default item" into that "current" or "local" scope.

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.

Ok, "aggregation" is probably clearer and also matches the use of that term in the context of SQL. Thanks for the suggestion!

From what Daniel is describing, "aggregation" (or perhaps specifically 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.

Enumeration should be the default, and can even be the only form of aggregation, though I would really like to have range and min/max too.

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.

We established the "item" terminology in the data model. The syntax spec has to be consistent with this. We could change "item" to something else, but we'd have to start in the data model.

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.

Yea, maybe that needs some explanation. I'm not using "strong" as such, I'm referring to "equally strong" statements. Two preferred statements are equally strong, but if there are no preferred statements but only two unsourced statements, they are also equally strong and would be combined (aggregated, coalesced).

2. Please run a spelling checker, it is distracting to read at the

moment. but content goes over form, or course!

Sorry, will do.

-- daniel

On 29.05.2012 17:02, Gregor Hagedorn wrote:

Hi Daniel,

...

They may not exist in the current form, but a "local scope" will always exist. Template parameter names are local the the current template "call". They have to be managed somewhere, so mediawiki will always have some way to manage data attached to the "current call", and we can tie into that to put the "default item" into that "current" or "local" scope.

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.

Hehe, good catch. I have been thinking about this, and I think that in the case of default items, it would be consistent to let "sub"-templates (nested template calls) inherit the item set by a template further up. I'm not sure how this is currently handled by the preprocessor. It's something to be investigated (maybe we can have a chat with Tim about this in Thursday...)

...

We established the "item" terminology in the data model. The syntax spec has to be consistent with this. We could change "item" to something else, but we'd have to start in the data model.

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.

Please voice your concerns on the data model's talk page, https://meta.wikimedia.org/wiki/Talk:Wikidata/Data_model.

-- daniel

On 29.05.2012 18:06, Gabriel Wicke wrote:

On 05/29/2012 05:12 PM, Daniel Kinzler wrote:

...

On 29.05.2012 17:02, Gregor Hagedorn wrote:

...

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.

Hehe, good catch. I have been thinking about this, and I think that in the case of default items, it would be consistent to let "sub"-templates (nested template calls) inherit the item set by a template further up. I'm not sure how this is currently handled by the preprocessor. It's something to be investigated (maybe we can have a chat with Tim about this in Thursday...)

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.

Thanks for providing details here!

This would be the case, since the local "variable" indicating the "local" default item would be set using a parser function call in the template, and would depend solely on the template parameters (or, trivially, use a static item id).

It is possible to add scoped variables, but we'd have to carefully consider the implications for caching, implementation complexity and usability.

Since the scoped var does not depend on any external information besides template parameters, I don't expect problems here.

-- daniel

Would it not be error prone to have the item setting being inherited in a subtemplate, which, on its own, expects to refer to the default item?

Gregor

On 29.05.2012 18:54, Gabriel Wicke wrote:

On 05/29/2012 06:33 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.

Thanks for providing details here!

This would be the case, since the local "variable" indicating the "local" default item would be set using a parser function call in the template, and would depend solely on the template parameters (or, trivially, use a static item id).

This is not true for subtemplates of such a wrapper template, unless you completely disable caching for those or handle expansion yourself.

Ah, of course. Good point, thanks!

...

...

It is possible to add scoped variables, but we'd have to carefully consider the implications for caching, implementation complexity and usability.

Since the scoped var does not depend on any external information besides template parameters, I don't expect problems here.

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.

So that basically means the default item should be changed only once, and only at the beginning, of a template, and this would have to be evaluated before evaulating anything else in that template. Hm, that sucks.

-- daniel

This is still to be decided. We expect to be back with a draft of a suggestion for this answer within the next month.

2012/5/29 Helder . helder.wiki@gmail.com

https://meta.wikimedia.org/w/index.php?title=Wikidata/Notes/Inclusion_syntax...

...

the language to prefer for the value, as a fallback list of language

codes. Per default, the page's content language is used. Just to be clear, will the default be the content language **and its fallbacks**?

---

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