I second the general request, though I doubt it's feasible to consider
adding this feature to version 1.4. As a reminder, or for those who haven't
seen it, there's a page that describes n-ary relations in general, and
includes, at the bottom, a proposed syntax I came up with for handling them
in SMW:
http://semanticweb.org/wiki/N-ary_relations
There's more discussion of the SMW implementation in the talk page.
By the way, I believe there's some disagreement about whether or not what's
currently in SMW represents true n-ary relations: I think some have said
that it is, and that this proposal is better described as "properties for
entities within pages", while others have said that the proposal is really
n-ary relations, and that what's currently available is only "multi-valued
properties". But that's really just a (if I may call it that) semantic
issue.
-Yaron
On Tue, Oct 7, 2008 at 2:08 PM, Robert Murphy <[EMAIL PROTECTED]>wrote:
> 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 S-MW.org 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!
> Sincerely,
>
> Robert Murphy
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Semediawiki-devel mailing list
> Semediawiki-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
>
>
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
