I don't think using "List" as a type name is a good idea, because "list" is
already generally used to indicate that a template field holds a list of
values. This naming is used even in SMW itself - the #declare function can
be called with "{{#declare:property-name=field-name#list}}". This naming
confusion could apply even to "Value list", actually.As for a better name - how about "N-ary"? Yes, it's obscure, but then again people probably wouldn't use this type unless they understood the concept anyway. "N-ary" has the advantage that it doesn't introduce yet another term - it's already the name used in the database table and code, and in discussions. I should note, since I'm on the subject, that I would just as well see these "multi-value properties" removed from SMW altogether. Even if the issues with querying get resolved, they're still an un-ideal solution: they're inflexible, they don't support enumerations (i.e., a limited set of allowed values), and, maybe most compellingly, they're not "semantic" - there's no way to indicate what each value actually means. But maybe that's a topic for another discussion... -Yaron On Thu, Jan 7, 2010 at 9:16 AM, Markus Krötzsch < mar...@semantic-mediawiki.org> wrote: > On Donnerstag, 7. Januar 2010, Jon Lang wrote: > > Markus Krötzsch wrote: > > > The code for n-ary/multivalued has now been changed in SVN, and a new > > > system is in place. This email describes the changes for users, and > asks > > > for proposals on how to label some things that users will have to > enter. > > > This thread does not discuss the maximal number of fields in a > > > multi-valued property (there is another thread for this). > > > > > > == Changes for the user == > > > > > > The old way of declaring an n-ary property was to give a type > annotation > > > like the following on its property page: > > > > > > [[has type:: String; Number; Page]] > > > > > > This example declares a property that has three fields of the given > order > > > and type. The new code requires a modified declaration that contains > two > > > annotations: > > > > > > [[has type:: Value list]] > > > [[has fields:: String; Number; Page]] > > > > > > So the type is no longer the list but it has a name, and the list of > > > fields is given in a new property. > > > > Does the type have to be "Value list", or can you add "has fields" to > > other properties? > > No, you have to specify the type. > > > My reasoning: in the "Defining N-ary Relations on > > the Semantic Web" article[1], a distinction was made between an N-ary > > relation that represents a primary value with supplementary > > information and an N-ary relation that represents different aspects of > > a common relation with no preference for one value over any of the > > others. It occurs to me that by allowing "has fields" on non-"Value > > list" property pages, we could capture this distinction quite > > intuitively: if the property page includes "has type:: Value list", > > then there is no primary value: any queries concerning values for that > > page must refer to the fields; if the property page specifies any > > other type, then that is considered to be the primary value, and > > queries for values on that page assume that you're referring to the > > primary value unless you explicitly ask for the fields. > > I see your point but I don't think that this is needed. The reason is that > there would be basically two cases that could occur: > > (1) The primary value is a wiki page. In this case, assigning a value to > the > N-ary relation would specify additional annotations of that primary page > value. So one would specify annotations of a page within some other page. > This > is not supported by SMW and it is not needed, since one can always edit the > primary page directly. > > (2) The primary value would be a data value that is not a page. Then you > would > attach annotations to a datavalue, e.g. to the number "42". This is not > desirable, since neither SMW nor RDF support annotations on data literals > such > as numbers or strings. > > > > > 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. > > I should add that we can have any number of such types that use different > syntaxes for different purposes. One could also have special-purpose types > for > naturally occurring compound data such as street addresses (as written in > some > language). I am not going to write these, but they could be part of > extensions. 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). > > -- 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 > -- > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and > easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Semediawiki-user mailing list > semediawiki-u...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/semediawiki-user > >
------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
