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). 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).
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. Cheers, Markus On Donnerstag, 7. Januar 2010, Jon Lang wrote: > Markus Krötzsch wrote: > >> Related to this is the notion of named fields. Please give the option > >> to attach meaningful names to the fields for querying purposes, so > >> that the user doesn't have to specify a positional list of values. > >> For instance: > >> > >> [[has fields:: name=String; count=Number; source=Page]] > >> > >> This would allow queries for instances of the property by means of a > >> specific value for the name, property, and/or source. > > > > As I said, this task can be approached now. It is not going to be an > > extension of Type:List (the current favourite name of "Value list"), but > > another type that allows for these inputs (how could this be called?). > > Thanks for your syntax proposal; I think this is probably the most > > straightforward syntax to pick. > > In short, the question is what to call a property that is a collection > of named fields. surveying the programming language community: Perl > calls it a hash; Javascript calls it an Associative Array; C calls it > a struct; Pascal calls it a record. > > I could see calling it a record; it tracks nicely with the term > "field" to refer to the named component parts. > > > SMW now has an abstract datavalue class SMWContainerValue that can > > be used to create any kind of value implementations that store values > > that resemble an annotated page (just "internal", i.e. without a name). > > Thank you; this is something that I've been wanting since I first > encountered SMW. > > zehet...@molgen.mpg.de wrote: > > Another possibility, which I partly use in the SQFT extension, would be > > to supply the names via other properties on the property page which > > allows different set of names for different purposes (e.g. as index > > replacement in ask queries, as table headers etc.): > > > > [[has fields:: String; Number; Page]] > > [[has names:: name; count; source]] > > [[has long_names:: official id of component; occurences between 2000 and > > 2007; first publication mentioning component]] > > [[has headers:: ID by EMBL; 2000-2007 ; Publication]] > > I don't like the disconnect between the names and the values that are > presented there. That said, another possibility would be the use of > multiple "has field" properties. This works better for a Record than > for a List, since a List depends heavily on the sequence of the fields > while SMW Properties ought to be agnostic as to the order in which > they appear on a page. OTOH, a "has field" Property for a Record > could itself be a Record: > > [[has field:: name=name; type=String]] > [[has field:: name=count; type=Number]] > [[has field:: name=source; type=Page]] > > or even: > > [[has field:: type=String; name=name; long name=official id of > component; header=ID by EMBL]] > [[has field:: type=Number; name=count; long name=occurences > between 2000 and 2007; header=2000-2007]] > [[has field:: type=Page; name=source; long name=first publication > mentioning component; header=Publication]] > > ...although I'd be inclined to reserve something like the latter for > special-purpose container types. > > I have further thoughts about Records, which I'd ultimately like to > see supplant Lists for most uses; but they're probably best addressed > in a separate topic. > -- 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
