On Dienstag, 22. April 2008, Sergey Chernyshev wrote: > Yes, one way is to export to RDF, another way is to write a converted to > KML similar how there are ones for RSS and now iCal. > > I don't know how you plan this "another feature", but you can write an > extension that talks runs SMW query within the code and interpret it > however you like. > > If you want to go beyond RDF export, it will most likely require > development of some sort.
Exactly. I take the opportunity to briefly explain how to get started making
custom query output formats in Semantic MediaWiki.
Formatting of query results is achieved in SMW by not-so-complicated
QueryPrinter classes. They get the result data of a query in a PHP-based
format (class SMWQueryResult), and can translate it into any string they
want. Basically, you want to create a new such class that creates the format
you want. The printer classes are in the files includes/SMW_QP_* (the
SMW_QP_Table.php might be the most basic case). The code in general is
somewhat lengthy, since every query result is a 3D-array (a table with a list
of entries in each cell), but it is not really complicated. As of SMW >1.1,
query printers can create three formats: Wikitext, HTML, and stand-alone
files (like RSS). A parameter $outputmode specifies what is requested. So
only one 200-line file needs to be created for adding some basic new query
format or metadata export.
Now there are various options for you, depending on what you need exactly:
(1) You need the KML data outside the wiki (e.g. for an external map service
that imports KML files). In this case, you also will want to write a query
printer. Get the most recent SVN or wait until the next minor release (very
soon!). Writing an RSS-type printer will be much simpler in that version.
Basically you can copy SMW_QP_ICalendar.php and modify that to fit your needs
(mime type and output). SMW_QP_RSSlink.php is another example, but somewhat
less simple.
(2) You need the KML data within the wiki (e.g. for another extension working
on the data). Then the main challenge is to squeeze two steps (query
processing *and* map data processing) into one parsing run of MediaWiki. It
will be easy to create KML data in a result printer, but of course you do not
want to show that KML to the users.
(2a) If your mapping tool is a JavaScript, you need to encode your KML in a
way that allows embedding into the html wiki page, where JavaScript can find
the data. An adaptor script that scrapes HTML first might be needed since KML
is probably not directly embeddable into valid (X)HTML. SMW has one printer
that works like that: SMW_QP_Timeline.php.
(2b) If your mapping tool is another MediaWiki extension (that normally works
with literal user input), then you need to find out when this extensions does
its work. The MediaWiki page processing has many steps, and it might be that
the mapping extension is actually earlier than the query answering. Also,
query answering has two modes: {{#ask }} (preferred!) and <ask> </ask>
(legacy). The latter mode makes it hard for other MediaWiki extensions to
work on the result. So, summing up, it might sometimes happen that you need
to call the mapping extensions functions internally to help you create the
map output directly.
In all cases, you need to register the new query printer by extending
SMWQueryProcessor::$formats and adding an Autoload path for the printer class
(you can do both in LocalSettings.php).
I think (1) is easiest, but it disables query caching (since all data always
comes from Special:Ask which does not cache anything yet). (2) is not really
using KML, since you more or less directly feed the data into the application
that displays it. Of course, (1) and (2) do not exclude each other (i.e. you
can have a KML export anyway).
Good luck :-) (feel free to ask further questions)
Regards,
Markus
>
> Sergey
>
>
> On Tue, Apr 22, 2008 at 8:51 AM, Alex Le Bek <[EMAIL PROTECTED]>
>
> wrote:
> > Hi,
> >
> > I would like to save the results of a query to be used by another feature
> > (in this case displaying geographical data on a map). The geographical
> > data is marked up using properties. Can this be achieved with the 'rss'
> > format type on #ask ? If so what is the syntax for the 'rss' format? My
> > other thought was to export as RDF, convert to KML and read back into
> > maps that way(probably through a parser tag? But that seems messy). The
> > semantic component is tantalizing – I know the data's there, and I know I
> > can see it in a table – I'm just not sure how to get it out and into
> > another part of the wiki! Any ideas?
> >
> >
> >
> > Thanks
> >
> > Alex
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> > Don't miss this year's exciting event. There's still time to save $100.
> > Use priority code J8TL2D2.
> >
> > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/ja
> >vaone _______________________________________________
> > Semediawiki-devel mailing list
> > Semediawiki-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
--
Markus Krötzsch
Institut AIFB, Universität Karlsruhe (TH), 76128 Karlsruhe
phone +49 (0)721 608 7362 fax +49 (0)721 608 5998
[EMAIL PROTECTED] www http://korrekt.org
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
