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.
- 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).
- Please run a spelling checker, it is distracting to read at the
moment. but content goes over form, or course!
Sorry, will do.
-- daniel