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 <daniel.kinzler(a)wikimedia.de> 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 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.
--
---------------------------------
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.