Temlakos wrote:
One thing I would like to see with semantic queries, whether with N-ary
or singular properties, is the ability to retrieve the value of any
property of any page and embed this value in the text on another page.

Agreed.  It wouldn't take much to extend the current {{#ask}} functionality to allow for this sort of thing: just add the ability to filter on the page title.  Then you could perform an inline query that looks at one particular page (by filtering according to an exact page name) and returns the value of a particular property.  Voila!  You now have that value pasted onto another page. 

That said, there may be value to having some shorthand for this sort of thing, if it is to be used a lot. 
Here's what I'd like to do:

* In the article on Sun, keep that article up-to-date with the annotated
number of the sidereal day.

* In the article on the Nebula theory, at the point for discussing the
sidereal day of the Sun, enter a template or a query that will
automatically retrieve the then-current annotated value for "Sidereal
day" from the page titled "Sun" and show it.

* Further in the article, in a discussion of how fast the Sun would have
to spin to have its share of the angular momentum of the solar system,
use a query or template that would /calculate/ this hypothetical spin
rate, sidereal rotation period, or whatever, from the actual value
(retrieved from the article called Sun) and a scaling factor (specified
as a parameter to the template, perhaps).

The ability to calculate a value is already provided by a fairly common Mediawiki extension; all SMW needs to be able to do is to insert a value into the calculation from elsewhere in the wiki. 

Now about N-ary properties: our wiki has a number of articles on various
celestial bodies. Most, if not all, have annotated listings of all the
rocket probes that have visited them. (For example: [[Visiting
mission::Voyager 2]]) Now I know that I could define an N-ary property
that would at least store a date of first rendezvous with the mission
name, thus: [[Visiting mission::Voyager 2, 28 February 1981]] (And here
again, I recognize that if N-ary properties use comma-separated
annotation, then I cannot annotate text containing commas; happily both
the standard Date datatype and my Historical Date datatype recognize the
format I used in my example.)

But what I would like to do, in the article on Voyager 2, is set up a
query that creates a table of every target that Voyager 2 ever had, and
the date that Voyager 2 visited that target. Right now, with n-ary
properties, I cannot do this. If I had annotated a single
date-of-first-visit in the article on each body, then I could set up a
query that would produce this kind of table. But we all know that,
except maybe for the planets Uranus and Neptune and their satellites,
any celestial body that has been visited by /one/ rocket probe, has in
fact been visited by at least /two or three or more/. (The Jovian
system, for example, has documented visits by Pioneer 10 and 11, Voyager
1 and 2, and the later spacecraft Galileo, Ulysses, and even Cassini.)

Now if this were SQL, and not SMW, this would be easy to handle:

SELECT rendezvous FROM Visiting_mission ORDER BY rendezvous WHERE
spacecraft='Voyager 2';

With that I could get a list of every one of Voyager 2's targets, sorted
in order from first to last.

But right now, all I can do is display an alphabetized list of Voyager
2's targets in the Factbox--though I understand that with SMW 1.2, I'll
be able to sort those targets by some property other than the article's
name, even in the Factbox.

Now if I'm missing anything, I'd like to know. But I thought the
developers ought to know something that would make SMW even more
worthwhile than it is now.
This is a very good example of exactly what I was talking about.  In essence, I'm suggesting that the N-aries and {{#ask}} functionality be enriched to the point that you could map an {{#ask}} query of an N-ary Property directly to an SQL query of a table.  The field definitions of the N-ary property would define (most of) the fields of the table, and the inline query would have components corresponding to the various parts of a n SQL SELECT statement.  For example:

  {{#ask: [[spacecraft='Voyager 2']] | ?rendezvous | sort=rendezvous | find=Visiting mission }}

'find=Visiting Mission' would mean that you're not searching for pages; you're searching for Visiting Mission properties.  Analogous to 'FROM Visiting_mission'. 

'[[spacecraft='Voyager 2']]' would filter the results to include only those cases where the spacecraft field of the Visiting_mission property has the value 'Voyager 2'.  Analogous to 'WHERE spacecraft='Voyager 2'. 

'?rendezvous' tells the query to include the rendezvous field of the Visiting_mission property in its results.  Analogous to 'SELECT rendezvous'. 

'sort=rendezvous' tells the query to order by the rendezvous field of the Visiting_mission property.  Analogous to 'ORDER BY rendezvous'. 
The one 'flaw' of the above is that it would search the entire wiki for Visiting_mission properties, not just a single page.  I put 'flaw' in quotes because sometimes that's exactly what you'd want it to do.  So the trick is figuring out how to tell the query to only search certain pages and not others. 

There are additional issues that would have to be worked out; but I don't see any show-stoppers other than the need for a programmer who knows how to modify the code and who has the inclination to do this and sufficient time on his hands to implement it. 

Jonathan "Dataweaver" Lang