My two centimes/pfennigs below: Jon Lang wrote: > Robert Murphy wrote: > > Dear Developers, > > I run a wiki with a vast amount of N-ary data. I have yet to hear > from anyone who has successfully figured out how to query N-ary data. > Some of you may have seen my many question on the User Mailing List, > but no has ever said anything other than "I hear someone somewhere at > sometime solved that with templates." I have not been able to solve > it with templates and no semantic mediawiki I've found has either. > I'm afraid no one has seriously considered the possibility that N-ary > data is inaccessible from with Mediawiki. > > Basically, if you do pass a query to templates, and one of the > parameters is N-ary, then a comma separated list of all fields is > passed and there seems to be no way to handle that data from within a > template, even if there's only one instances of the n-ary value. If I > were just within Perl of PHP, splitting on regex's the passed N-ary > data would be a piece of cake. However, such programming language > features as "split" and arrays are not possible within a template. I > think this problem warrants serious developer attention. > > > I've been thinking about this, and I think that both N-aries and > queries need some refinement, and soon. > > On the N-ary front, I'd recommend introducing field names so that > individual fields can be referenced. The simplest way to do this > would be to allow "name=value" pairs anywhere that an N-ary currently > permits a value. (Note: "allow"; not "require". This allows for full > backward compatibility.) One application of the "field name" concept > would be the ability to use something like '[[Property::field=+]]' in > a query to find only those pages where Property has 'field' as a > field; or '?Property::field' to include the value of Property's field > in the output. > > On the querying front, I think we need something akin to SQL's 'FROM' > clause. Right now, it's assumed that the query is always looking for > pages that match the given criteria; the new feature would allow you > to specify that you're looking for every instance of a given property > where the criteria are satisfied. This would be ideally suited for > N-ary properties, but might be useful elsewhere. > > Here's what I envision: > > on Page [[N-ary]]: > [[Contributer::Robert Murphy, [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>]] > > on Page [[Property:Contributor]]: > [[type of::text, email=text]] > > on some other page: > {{ask: [[Contributer::email=+]] | ?Contributer::email }} > > this would produce something like: > {| > | [[N-ary]] || [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > |} > > I'd like to implement this myself; but I'm having some difficulty > puzzling out how the code for the N-ary type works. Any advice would > be appreciated. > > -- > Jonathan "Dataweaver" Lang
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. For example: say that one of my editors wants to discuss the nebula theory for the formation of the solar system, and in particular the "angular momentum problem" (that is to say, why does the sun have more than 99 percent of the mass while its satellites have 99 percent of the angular momentum?). A directly relevant consideration is the current sidereal rotation period of the sun. Well, at present, my fellow editor has to: 1. Browse "Sun" in the Browse page (or look up the article itself and scroll down to the Factbox). 2. Read the value of the sidereal "day" of the Sun. 3. Copy this value to the clipboard. 4. Return to the article on "Nebula theory." 5. Paste the value into his text. And if we later find out that our value for the sidereal day of the Sun is incorrect, now my editor has to set a watch on the Sun article and change his own article to stay consistent. Now Markus can correct me if I misunderstand, but I understood that the ultimate goal of the Semantic Web is to obviate that kind of messy retroactive edit. 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). In that manner, any change to the value stored in "Sun" (to reflect further research) would propagate to the article that mentions that value. 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. Temlakos ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
