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