Talk:N-ary relations

From semanticweb.org
Jump to: navigation, search

Contents

[edit] Why SMW doesn't support n-ary relations

SMW doesn't support N-ary relations in SMW. BOWiki had to fork to develop this functionality which is a clear sign of resistance in original development community.

Can someone close to SMW development project provide some rationale regarding this issue.

Links to prior discussions or documents regarding this issue will be greatly appreciated.

Thank you. --Sergey Chernyshev 23:39, 10 May 2007 (CEST)

I don't think there's been resistance per se, just the feeling, it would seem, that it was a low-priority issue. Also there's been no consensus on what the syntax should be, which I think has been a big obstacle. Here are two threads from the mailing list on the issue - [1] [2] - in the second thread I tried to summarize the ideas in the first. Yaron Koren 02:14, 11 May 2007 (CEST)
As far as I can see that here, my suggestion combined with Yaron's triple-brackets seems to make the way. This syntax is already very powerful.
The problem that keeps is, that there are issures that are more important at the moment like getting a 1.0 release and combine that with Wikipedia. The next step might be simple reasoning. N-Ary Relations are cool stuff and we really want them, but good things need time. — MovGP0 02:20, 24 May 2007 (CEST)

[edit] Implications

Let me first say that I very much like the idea of n-ary relations in a semantic wiki system. Some things just innately call for such functionality. Specifically I'm thinking about the ability to annotate a property with start and end dates. Compare:

Without n-ary relations With n-ary relations
Ronald Reagan was elected as the 40th [[elected as::President of the United States]] on [[date elected (President of the United States):=November 4, 1980]]. He held office from [[start date (President of the United States):=January 20, 1981]] to [[end date (President of the United States):=January 20, 1989]]. Before becoming President, Reagan was the 33rd [[elected as::Governor of California]] ([[start date (Governor of California):=January 3, 1967]], to [[end date (Governor of California):=January 7, 1975]]). Ronald Reagan was elected as the 40th [[[elected as:=[[position::President of the United States]] on [[election date:=November 4, 1980]]. He held office from [[start date:=January 20, 1981]] to [[end date:=January 20, 1989]] ]]]. Before becoming President, Reagan was the 33rd [[[elected as:=[[position::Governor of California]] ([[start date:=January 3, 1967]], to [[end date:=January 7, 1975]]).]]]

(I am using Yaron Koren's markup for purposes of these examples. Other markup styles may be equally valid.)

In the above examples, I want to associate dates with terms in office. It's much simpler with n-ary relations. I have fewer properties to consider because I don't have to elaborate the date properties with the term I'm dating (such as the property "start date (President of the United States)". The properties are contained within the higher-level property "elected as."

I can also reuse properties. I don't need to create both "start date (President of the United States)" and "start date (Governor of California)." I can just use one property, "start date," which is much simpler.

Now, with that said, I have a few questions about how n-ary relations would be used in a wiki. I've separated them into the subheadings below. Interested in all responses. :)

Stormraven 22:47, 13 May 2007 (CEST)

[edit] Semantic searching

Let's say I want to search for the capital of New Zealand. From 1840 to 1865, the capital was Auckland, but from 1865 to present, it has been Wellington, so let's say I have given both of those cities the property "capital of" → New Zealand and have annotated those properties with start and end dates:

Auckland Wellington
[[[capital of:= [[state::New Zealand]] ([[start date:=1840]] - [[end date:=1865]])]]] [[[capital of:= [[state::New Zealand]] ([[start date:=1865]] - [[end date:={{CURRENTYEAR}}]])]]]

Now, when I do my semantic search, I can't just look for [[capital of::New Zealand]]. The property "capital of" doesn't take such an argument directly; it's a container for other properties. The search engine is going to have to be able to parse a more complex, n-ary structure, seeking both "capital of" and, within that property, the subproperty "state" equal to "New Zealand."

I think your "subproperty" here is not in the sense of state is a rfds:subPropertyOf capital_of, it's more a "component" or "aspect" -- Skierpage 00:28, 14 August 2007 (CEST)

Such a search would return both Auckland and Wellington, though. I need to find the one that is currently the capital. The magic word "CURRENTYEAR" keeps the Wellington entry nicely up to date, I hope. So perhaps if I search for

[[[capital of:=[[state::New Zealand]] [[end date:={{CURRENTYEAR}}]] ]]]

I'll find Wellington, as I hope.

What if the Wellington article hadn't been tagged with an end date, though? Perhaps someone left it off because there is no end date. Is there a way to search for "end date" either equal to CURRENTYEAR or not set at all?

Very interesting. I think this is mostly a question about aspects of inline queries not related to n-ary relations. Say you want to know what the capital was in, say, 2004. The query you're looking for might look something like:
<ask>[[[capital of:=[[state::New Zealand]] [[start date<=2004]] [[end date>=2004 OR end date:=null]] ]]]</ask>
I'm making up syntax here right and left. The point is, I think SMW inline queries are at the moment missing things like inequality operators, OR statements, and null checks, which is what this example would require, in addition to support for n-ary relations... it might be better to start off with something simpler. Yaron Koren 17:39, 14 May 2007 (CEST)
OR statements and inequality operators are described in the online documentation. NULL values are not. Fabricating that remaining element, the query above would look more like this:
<ask>[[[capital of:=[[state::New Zealand]] [[start date:=<2004]] [[end date:=>2004||NULL]] ]]]</ask>
However, after some more thought, the question above now suggests to me that I might prefer a new boolean relation, "current," to query instead of "end date." If, for instance, New Zealand were to move its capital to, I don't know, Dunedin in 2007, then both Wellington and Dunedin would have "end date" 2007 until January 1, 2008. But I could query for [[current:=true]] to find the correct current capital. Or I could use a more specific date for the switch, of course ("July 1, 2007"), but then my query would have to also use the more specific date ("{{CURRENTMONTH}} {{CURRENTDAY}}, {{CURRENTYEAR}}"), which is just cumbersome.
And it's true, this is mostly a question of arranging the query. I just wanted to point out that the query system would have to be ready to accept n-ary queries. — Stormraven (talk) 16:17, 16 May 2007 (CEST)
Ah, so it is - I stand corrected on the capabilities of inline queries. I should read the documentation more often... Yaron Koren 21:30, 16 May 2007 (CEST)

[edit] Related relations

N-ary relations would have implications for relations that are related to each other, such as by "inverse of" or "subrelation of." As I understand it — and I could easily be wrong — the current SMW system doesn't make much use of relations applied to relations. But if it ever does, n-ary relations will have a considerable impact.

Take the example above regarding capitals of New Zealand. The property "capital of" is generally considered the inverse of "has capital." But with n-ary relations, this is not necessarily the case. Auckland has the property "capital of," but no state would have the property [[has capital::Auckland]]. In fact, no state is directly implied to have that relation because, as structured above, Auckland's "capital of" has no direct object. It's a container for a number of other objects, one of which is "state," but there's no way to identify this as the primary subrelation. As far as the system is concerned, the relation "start date" could just as easily be the primary subrelation, implying that 1840 would have the inverse relation "has capital" → Auckland.

So the first problem of inverse n-ary relations is that there has to be a way to identify the primary subrelation that the inverse works through, to get from Auckland to New Zealand and back. The second is that the inverse is true only if (a) both relations have the same subrelations, and (b) the non-primary subrelations are all equal. So "has capital" would require the same subrelations "start date" and "end date," and they'd have to match. The New Zealand article could have two instances of "has capital," therefore, one each for [[city::Auckland]] and [[city::Wellington]], with the start and end dates properly assigned.

This creates an opportunity, though. If there is a way to identify the primary subrelation for each relation in the inverse pair, then the constancy of the other subrelations might be implied. So if I've fully annotated Auckland and Wellington but not New Zealand, and I've identified "state" as the primary subrelation of "capital of," then the SMW system might recognize on some level that New Zealand "has capital" both Auckland (1840-1865) and Wellington (1865-present). Further, if I've annotated all three, but the annotations don't match (perhaps I've got a date wrong), then the SMW system might recognize the inconsistency and somehow flag it for editorial review.

This is indeed a thorny problem. You're right, you'd have to identify one of the subrelations as being the main one. I don't know how that would be done, and in fact I don't know how such a thing would be defined in RDF either - the W3C document doesn't seem to mention primary subrelations.
On a practical level, I never much understood the need for inverse relations. In the case of your example, in the Auckland and Wellington pages, you can see the "capital" information because that's where it's defined. In the New Zealand page, you would just have to do a query like <ask>[[[capital of:=[[state::New Zealand]] ]]]</ask>, assuming there was n-ary support, and you'd get the list of both cities, and their years. So really, inverse relations would be used for another page altogether - some random other page where you wanted to list, say, all the countries that Auckland has been a capital of, and for what years.
Nevertheless, it is something that some users want. One option for finding inverses, given how tricky it is for n-ary relations, is to forget about creating inverse relations and just do inverse queries - queries where you keep the same relation name, but specify the object and not the subject. So, in this example, the query might look like:
<ask>Auckland[[capital of:=*]]</ask>
The idea of inverse queries makes some sense, in my opinion, for regular (non-n-ary) relations as well; there's no confusion about which relations are defined and which are merely "implied". It came up on the mailing list (a month ago), but with no resolution. Yaron Koren 17:23, 15 May 2007 (CEST)
I think you're right in that inverse relations (and other related relations) seem to have no practical use at this time because SMW doesn't make use of them. However, I also think that they have the potential for practical value, and as such the developers could decide to explore ways to make use of them. Only for that reason does it make sense to bring them up here.
I think I like the inverse query, though I don't care for the format above. It's too easily confused with a search for any article that mentions "Auckland" and is the capital of any state (as I described on the mailing list, with the example "Amsterdam" instead of "Auckland"). Perhaps you could reverse the ":=" notation to signify an inverse search:
<ask>[[Auckland=:capital of]]</ask>
Still, to take full advantage, you'd have to have a way to combine a regular search with an inverse search and collect all of the results together. That way, if either Auckland or New Zealand is annotated, you get the correct response, even if you don't know which one is annotated:
<ask>[[has capital::Auckland]]||[[Auckland=:capital of]]</ask>
According to Help:Semantic search, the double-pipe serves as a logical OR, although all the examples there put the operator within the [[double-bracketed]] search terms, so I don't know whether this notation would work, even leaving off the fabricated inverse search notation.
But if that (or something like it) would work, it would be almost as good as having SMW take direct advantage of inverse relations. The system would be able to find relations even if they're not fully annotated in every related article.
Sorry, I've gone far afield from talking about n-ary relations. — Stormraven 15:51, 16 May 2007 (CEST)

[edit] Interrupting information

In the course of writing an article, it's easy to foresee a time when an n-ary relation might be interrupted with other information not related to it, but which also needs annotation.

Suppose in the example above about Ronald Reagan, I were to write some introductory material about his election and term in office, but then go on to describe his presidency before ever mentioning when he left office. It might go something like this:

Ronald Reagan was elected as the 40th President of the United States on November 4, 1980. He assumed office on January 20, 1981, together with his Vice President, George H. W. Bush. Reagan assembled a cabinet of...

...Reagan left office on January 20, 1989.

There's lots of intervening information about his presidency before we ever get to the date he left office. This suggests that the markup has to be split around the intervening information and picked up again later, perhaps like

Ronald Reagan was elected as the 40th [[[elected as:=[[position::President of the United States]] on [[election date:=November 4, 1980]]. He assumed office on [[start date:=January 20, 1981]] ]]], together with his Vice President, [[[United States presidency:=[[vice-president::George H. W. Bush]]. Reagan assembled a cabinet of...

...Reagan left office on [[[elected as:=[[end date:=January 20, 1989]] ]]].

The parser would have to be able to recognize this division of information and collect the subrelations properly into their higher-level relations. But as it currently exists, I think it's more likely that the SMW system would give this article another instance of "elected as" with one, lonely subrelation, "end date," which is not useful.

I can think of only a couple ways to handle split information like this. One is for the author to give a relation a unique identifier for any unique instance of an n-ary relation. He might give the relation "elected as" the identifier "potus," for instance. Then whenever he refers to [[[elected as:=[[identifier:=potus]]...]]], the system will understand that it's additional information for that instance of the relation, not a new instance of the relation. The attribute "identifier" would have to be a protected word with a unique meaning in the SMW system.

The other option, and probably the best one, would be to require that all of the subrelations be contained within the higher n-ary relation even if they're not mentioned yet in the article. This might look something like this:

Ronald Reagan was elected as the 40th [[[elected as:=[[position::President of the United States]] on [[election date:=November 4, 1980]]. He assumed office on [[start date:=January 20, 1981]] [[end date:=January 20, 1989| ]] ]]], together with his Vice President, [[[United States presidency:=[[vice-president::George H. W. Bush]]. Reagan assembled a cabinet of...

...Reagan left office on January 20, 1989.

The empty pipe on the relation "end date" means the information is not displayed, but it's still filled in for the relation "elected as," and all of the relations are collected together. The system doesn't have to compare any other instances of "elected as" to this one to see whether they match. Any call to "elected as" is a new instance of that relation.

I think this second approach is the right one. It's much easier to preserve integrity of the data if everything related to an n-ary relation is forced to be in one place. Especially if you use templates to store semantic information, you could end up with data conflicts that might be hard to detect. Yaron Koren 17:46, 14 May 2007 (CEST)
I wouldn't throw the Idea using the ID totally away. The ID should only have local validity. Assume the following example:
Ronald Reagan was elected as the 40th [[[#ReaganElection::elected as:=[[position::President of the United States]] on [[election date:=1980-08-04|November 4, 1980]]. He assumed office on [[start date:=1981-01-20|January 20, 1981]] ]]], together with his Vice President, [[[United States presidency:=[[vice-president::George H. W. Bush]]]]]. Reagan assembled a cabinet of...
insert lot of bla bla here.

Reagan left office on [[[#ReaganElection::elected as:=[[end date:=1989-01-20|January 20, 1989]]]]].

In the Example the ID is prefixed using a #-Sign, so the parser can check for this. This approach solves the problem, but also makes the syntax more complex. But I guess this is just a possibility that we should keep in mind for the far future. The Example without need for any ID is for the nearer future.
MovGP0 02:08, 24 May 2007 (CEST)

[edit] Use cases

It's probably a good idea to list as many use cases here as possible to illustrate different features required from n-ary relations support in SMW.

[edit] When it doesn't make sense to create an article for relation

Simple use cases where it doesn't make sense to create separate article for the fact (which might make some sense in case of "Ronald Reagan's presidency").

[edit] College history

For example I'd like to mark foaf:Person's college attendance history where such relations will be described on Person's page with syntax like this:

[[[Attended college:=In [[Start date:=1992]] I got accepted into
[[College:=Bauman State University]] and was [[Finish reason:=expelled]]
from it in [[End date:=1994]].]]]

[[[Attended college:=Finally, in [[End date:=2000]] I [[Finish reason:=graduation|graduated]]
from [[College:=State University of Oil and Gas]].]]]

[edit] Address

It makes sense to have whole address defined (to be able to link to maps sites, for example) but still be able to query by it's parts.

[[[Address:=
   [[Street Number:=1335]] [[Street name:=Avenue of the Americas]],
   [[City::New York City]], [[State::New York|]] [[Zip:=10019]]
   [[Country::USA]]
]]]

[edit] Use Cases from the W3C

The following Use Cases are taken from [3] to show that the syntax suggested here is a general approach.

In Turtle:
:Christine
      a       :Person ;
      :has_diagnosis _:Diagnosis_Relation_1 .

:_Diagnosis_relation_1
      a       :Diagnosis_Relation ;
      :diagnosis_probability :HIGH;
      :diagnosis_value :Breast_Tumor_Christine .
In article Christine:
[[instance of::Person]]
[[[has diagnosis::
      [[instance of:Diagnosis Relation]]
      [[diagnosis probability:=HIGH]]
      [[diagnosis value::
            Breast Tumor Christine]]
]]]


In Turtle:
:Diagnosis_Relation
      a       owl:Class ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:someValuesFrom :Disease ;
                owl:onProperty :diagnosis_value
              ] ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:allValuesFrom 
                   :Probability_values ;
                owl:onProperty 
                   :diagnosis_probability
              ] .
In Article Relation:Diagnosis Relation:
[[rdfs:subClassOf::owl:Class]]
[[[owl:Restriction::
      [[owl:someValuesFrom::Disease]]
      [[owl:onProperty::diagnosis value]]
]]]
[[[owl:Restriction::
      [[owl:allValuesFrom::
            Probability values]]
      [[owl:onProperty::
             diagnosis probability]]
]]]


In Turtle:
:Person
      a       owl:Class ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:allValuesFrom 
                   :Diagnosis_Relation ;
                owl:onProperty :has_diagnosis
              ] .
In article Person:
[[rdfs:subClassOf::owl:Class]]
[[[owl:Restriction::
      [[owl:allValuesFrom::
            Diagnosis Relation]]
      [[owl:onProperty::has diagnosis]]
]]]


In Turtle:
:Purchase_1
      a       :Purchase ;
      :has_buyer :John ;
      :has_object :Lenny_The_Lion ;
      :has_purpose :Birthday_Gift ;
      :has_amount 15 ;
      :has_seller :books.example.com .
In Article Purchase 1:
[[rdfs:instanceOf::Purchase]]
[[has buyer::John]]
[[has object::Lenny The Lion]]
[[has purpose::Birthday Gift]]
[[has amount:=15]]
[[has seller:=http://books.example.com]]


In Turtle:
:Purchase
      a       owl:Class ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:allValuesFrom :Purpose ;
                owl:onProperty :has_purpose
              ] ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:cardinality 1 ;
                owl:onProperty :has_buyer
              ] ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:onProperty :has_buyer ;
                owl:someValuesFrom :Person
              ] ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:cardinality 1 ;
                owl:onProperty :has_seller
              ] ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:onProperty :has_seller ;
                owl:someValuesFrom :Company
              ] ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:onProperty :has_object ;
                owl:someValuesFrom :Object
              ] .
In Article Purchase:
[[rdfs:subClassOf::owl:Class]]
[[[owl:Restriction::
      [[owl:allValuesFrom::Purpose]]
      [[owl:onProperty::has purpose]]
]]]
[[[owl:Restriction::
      [[owl:cardinality:=1]]
      [[owl:onProperty::has buyer]]
]]]
[[[owl:Restriction::
      [[owl:onProperty::has buyer]]
      [[owl:someValuesFrom::Person]]
]]]
[[[owl:Restriction::
      [[owl:cardinality:=1]]
      [[owl:onProperty::has seller]]
]]]
[[[owl:Restriction::
      [[owl:onProperty::has seller]]
      [[owl:someValuesFrom::Company]]
]]]
[[[owl:Restriction::
      [[owl:onProperty::has object]]
      [[owl:someValuesFrom::Object]]
]]]


In Turtle:
:is_bought_by
      a       owl:ObjectProperty ;
      owl:inverseOf :buys .
In Article is bought by:
[[rdfs:subClassOf::owl:ObjectProperty]]
[[owl:inverseOf::buys]]


In Turtle:
:is_buyer_for
      a       owl:ObjectProperty ;
      owl:inverseOf :has_buyer .
:is_object_for
      a       owl:ObjectProperty ;
      owl:inverseOf :has_object .
In Article Relation:is buyer for:
[[rdfs:subClassOf::owl:ObjectProperty]]
[[owl:inverseOf::has buyer]]

In Article Relation:is object for:

[[rdfs:subClassOf::owl:ObjectProperty]]
[[owl:inverseOf::has object]]


In Turtle:
:Person
      a       owl:Class ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:onProperty :is_buyer_for ;
                owl:allValuesFrom :Purchase
              ] .
In Article Person:
[[rdfs:subClassOf::owl:Class]]
[[[owl:Restriction::
      [[owl:onProperty::is buyer for]]
      [[owl:allValuesFrom::Purchase]]
]]]


In Turtle:
:Flight
	a owl:Class .

:flight_sequence
   a owl:ObjectProperty , 
      owl:FunctionalProperty ;
   rdfs:domain :Flight ;
   rdfs:range :FlightSegment .

 :FlightSegment
    a owl:Class ;
    rdfs:subClassOf owl:Thing ;
    rdfs:subClassOf
         [ a owl:Restriction ;
             owl:cardinality "1";
             owl:onProperty :destination
         ] ;
   rdfs:subClassOf
         [ a owl:Restriction ;
             owl:allValuesFrom :Airport ;
             owl:onProperty :destination
          ] .

  :next_segment
      a owl:ObjectProperty , 
         owl:FunctionalProperty ;
      rdfs:domain :FlightSegment ;
      rdfs:range :FlightSegment .


:FinalFlightSegment
   a owl:Class ;
   rdfs:comment
      "The last flight segment 
      has no next_segment";
   rdfs:subClassOf :FlightSegment ;
   rdfs:subClassOf
        [ a owl:Restriction ;  
            owl:maxCardinality "0";
            owl:onProperty :next_segment
         ] .

  :Airport
      a owl:Class .

  :destination
      a owl:ObjectProperty , 
         owl:FunctionalProperty ;
      rdfs:domain :FlightSegment .
In Article Flight:
[[Rdfs:subClassOf::owl:Class]]

In Article Attribute:flight sequence:

[[rdfs:subPropertyOf::owl:ObjectProperty]]
[[rdf:type::owl:FunctionalProperty]]
[[rdfs:domain::Flight]]
[[rdfs:range::FlightSegment]]

In Article FlightSegment:

[[rdfs:subClassOf::owl:Class]]
[[rdfs:subClassOf::owl:Thing]]
[[[owl:Restriction::
      [[owl:cardinality:=1]]
      [[owl:onProperty::destination]]
]]]
[[[owl:Restriction::
      [[owl:allValuesFrom::Airport]]
      [[owl:onProperty::destination]]
]]]

In Article Relation:next segment:

[[rdfs:subPropertyOf::owl:ObjectProperty]]
[[rdf:type::owl:FunctionalProperty]]
[[rdfs:domain::FlightSegment]]
[[rdfs:range::FlightSegment]]

In Article FinalFlightSegment:

[[rdfs:subClassOf::owl:Class]]
[[rdfs:comment:=
      The last flight segment
      has no next_segment
]]
[[rdfs:subClassOf::FlightSegment]]
[[[owl:Restriction:::
      [[owl:maxCardinality:=0]]
      [[owl:onProperty:=next segment]]
]]]

In Article Airport:

[[rdfs:subClassOf::owl:Class]]

In Article Relation:Destination:

[[rdfs:subPropertyOf::owl:ObjectProperty]]
[[rdf:type::owl:FunctionalProperty]]
[[rdfs:domain::FlightSegment]]

[edit] Features derived from Use cases

  • Order can vary (which means we have to have named sub-relations)
  • Some of the attributes can be optional (notice that I didn't mention when I enrolled into second college)
  • Syntax should encourage authors to put whole sentences into n-ary relation enclosing tags (triple sq. brackets in this notation) so in addition to facts themselves, system can possibly extract some human readable information regarding each fact.

[edit] Too complicated/confusing and just unnecessary

All of this syntax is just not necessary and way too complicated and confusing for normal (i.e. non-semantic) users. For one, the relationships/attributes/properties (whatever) are too wordy. Instead, these are shorter, more grammatically correct, less syllables, faster to type, etc:

  • has president -> president
  • begin of term -> term begin
  • end of term -> term end
  • location -> place

Prepositions aren't necessary and just add to the overwordiness (like that word) of the syntax. Second, a lot of these relationships aren't even needed with a decent search engine ("set union engine") that allows searching within/across categories (sets), certain namespaces (using an easier-to-use multi-select listbox vs. annoying checkboxes), prefix/suffix (will need a new special page) pages, etc. Wildcard search (this wiki needs MediaWiki interwiki links) would help too. Categories can pick up much of the slack, but even basic backlink lists help (like what Special:Whatlinkshere/N-ary relations and Dynamic Page List can do--though DPL needs improvement regarding redirected pages).

For example, to search for United States president John F. Kennedy's term begin/end dates, it would be just a matter of selecting the appropriate categories "United States" and "Presidents" (note: not the category "United States presidents" since that is just a manually created union category of the previous 2 categories). Kennedy would obviously be in the results which could be in sortable tabular form with other optional (add-/removable) common columns like birth/death date/place, term begin/end, etc, of which the headers would be clickable to go to an expanded set union of all people with, say, birthdates. Now, obviously that list would be quite large, so limiting it to x results per page and then allowing ways to narrow the results down to, say, various time periods throughout history (millenia, centuries, decades, years), places (countries, cities, etc), by last (or first) name, gender, profession, etc, etc. No complicated semantic syntax necessary since it's all done with root category (sets) unions!

Also, with the new property, er, property (attribute? option? parameter?), will it work like relationships do now with [[relationship::name]] where the "::" (double colons) create a link where as [[attribute:=name]] doesn't create a link? I ask because I need that functionality for both parameters ("relationship" and "attribute" now in SMW .7 and I hope "property" can do both links and non-links as well for the next SMW version.

Last, if "property" can also accept just "prop" that would would make it easier to use (and type)--"rel" and "att" could be shortened forms of the current parameter names too.

As I understand them, most of your comments don't apply to the feature of N-ary relations. The one that does, John F. Kennedy's term begin/end dates, is an example of why n-ary relations are important. It would be confusing if his Wikipedia article had [[term_begin:=1961-01-20]], because if you look at it, he had three terms, as president and senator and congressman. The begin and end dates aren't properties of JFK, but of other entities (JFK's presidency, JFK's stint as a senator, etc.) For sure, the syntax for representing this is confusing but it's fundamentally hard.
Regarding your other comments: One man's verbiage is another's self-describing clarity. You very likely need to distinguish "has president" from its inverse "is president of". I find I very rarely type "Relation" or "Attribute", SMW usually infers them from its :: and := syntax; if it really bugs you you could change these terms in your installation's language file. You can already search across multiple categories using || syntax, see Help:Semantic search. Although SMW lets you search on categories, it is way better IMO to search for the property [[gender:=female]] than to have a Category:Female or even worse things like Category:Female_actors — the limitations of MediaWiki categories are a big motivation for SMW. I agree that wildcard search in SMW's semantic search would be useful, and that an easier front-end for it than the bare Special:Ask page would be nice. Your idea, if I understand it correctly, of interactively narrowing/expanding category within a search interface is interesting, maybe some other MediaWiki extension has attempted it. -- Skierpage 11:52, 13 August 2007 (CEST)
Personal tools
Namespaces

Variants
Actions
Navigation
services
Toolbox