On Samstag, 6. März 2010, Jon Lang wrote: > Markus Krötzsch wrote: > > Moving toward the SMW 1.5.0 release (finally), I came back to this > > thread, and I find that I agree with Jon & Yaron: the name "list" really > > means something different (actually, I might even program support for a > > real "list" in some future). > > For an actual list, I'd prefer to see something like: > > <list property="sibling"> > [[sibling::Greg]] is the eldest of [[parent::Mike]]'s boys; > [[sibling::Peter]] is the middle child; and [[sibling::Bobby]] is the > youngest of the three. > </list> > > The idea is that within the list tag, you're requesting that the order > of the item properties be tracked. I'm going with the tag because of > the ability to specify an attribute for it; this lets you freely mix > ordered properties with unordered ones. It also lets you specify more > than one property to order into a single sequence (e.g., "brother > sister"); and if you don't specify any specific properties to order, > the default behavior is to order [i]all[/i] properties within the > list's scope.
Parsing is currently stateless and the interpretation of syntax does not depend on its order. Nesting is achieved by parser functions/templates, but not by <HTML-style tags>. So the suggested behaviour would alter a number of basic assumptions in MediaWiki parsing, making it hard to code it in a clean way. In addition, it also would redefine some of SMW's basic syntax depending on the current state, which leads to further foreseeable problems. The feature could possibly be realised in some extension, but I would really not recommend to do it like this. > > > So I will go for "record" (and don't ask me about translations to > > other languages; "record" will remain available in all languages and > > better proposals can be made by translators). > > Nitpicky personal preference: I'd prefer to have "record" reserved to > mean a collection of named fields, when we get around to that. A > collection of fields that are accessed by position is more properly > referred to as a "tuple". As a more generic term, consider "compound > property" to refer to a property that has fields: tuples and records > would be two varieties of compound properties. I agree, but "tuple" seemed to be even more technical. Records in Pascal of course are somewhat different, but I still think it is a good name for our purposes (for one thing, it is not easily confused with anything that we already have in MediaWiki). The planned named-fields version might be called "object". > > > Named fields are not going to be supported for now. To get this kind of > > feature, we would first go for something like internal objects where > > independently declared properties provide the field names for the > > components of a compound. But this is not going to be part of SMW 1.5.0 > > yet. > > Fair enough. Either way, I'm looking forward to the time when SMW > lets you query by field as well as by property. The architecture that has been set up now enables rather arbitrary extension types to be defined, both in terms of input and of query behaviour. So even the most specific interface demands could probably be addressed when creating new compound data values. -- Markus -- Markus Krötzsch <mar...@semantic-mediawiki.org> * Personal page: http://korrekt.org * Semantic MediaWiki: http://semantic-mediawiki.org * Semantic Web textbook: http://semantic-web-book.org --
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev
_______________________________________________ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
