Since there seems to be a general fielding of ideas for the push towards 1.4, let me once again reiterate my deep concerns of the way SMW handles n-ary data.  I am not a programmer, so I'm sure I'm asking a lot without knowing what it costs, but I think I speak for a growing number of SMW users and their desire for functionality.

I think the way n-ary data is handled in #asks needs to be radically rethought.  Take for example the example of Einstein and his jobs.  [[Property:Had job]] is something like [[Property:Job]] (Has type::Page), [[Property:Employer]] (Page), [[Property::Start date]] (Date) and [[Property::End date]] (date).  The natural way to want to display this data for multiple people is a table.  The assumption would be that you'd have sortable table headings of Person, Job, Employer, Start and End.  Einstein would have multiple rows for his multiple jobs.  Other people would populate the table the same way.  This way, you could sort for people who worked for [[Deutche Bank]] or were [[Patent Clerks]].  But this kind of layout is impossible with MASSIVE programming, MANY other extensions and some on-the-fly JavaScripting.

On my wiki, I have an enormous about of data is simple, two-dimensions: a word and it's form.  But if I want to list all the forms a word is used in across all pages, I have to either hand write it, or write regex loops to parse the n-ary data, using vast amounts of server resources.

I hope those of you who code will consider revisiting n-ary in queries and make it more functional.  If I win the Lotto, the second thing I would do would be to pay a developer to work on this!

Robert Murphy