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


On Thu, Jan 7, 2010 at 9:16 AM, Markus Krötzsch <markus@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

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  <markus@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
Semediawiki-user mailing list