On Monday 14 August 2006 22:48, Yaron Koren wrote:
> Hi,
>
> A little bit of background: a friend of mine (Nick Grandy) and I are
> working on a user-editable database site, built around Semantic MediaWiki.
> Also, we're making some customizations to the Semantic MediaWiki codebase
> for this purpose: most importantly, in our version, the "ask" tag can take
> in a user-created format name, to let users dictate how inline query
> results are displayed on the page. So, for instance, if a user enters text
> like
>
> <ask format=3D"MyFormat">...</ask>
>
> then the parser looks for a page called "Template:MyFormat"; if it finds
> it, it uses that template to display the results. Currenly, only HTML
> formatting, not MediaWiki formatting, gets parsed in these "query
> templates". We hope to contribute this feature into the Semantic MediaWiki
> codebase, after discussion with Markus and others (we can see, via Markus'
> last update, that this a feature that there's already some demand for).
OK, could be nice. The feature that was demanded recently, however, was qui=
te=20
the converse: using templates within an <ask>-block to constitute the actua=
l=20
query. Currently, when you write some {{...}} or {{{...}}} within ask, it i=
s=20
most certainly not resolved before querying.
What you suggest is also very nice, and I thought about it. The main issues=
=20
are:
* The plain HTML you mentioned. This could create huge security holes if no=
t=20
sanitised properly.
* If you switch from plain HTML to Wikitext, you have to prevent loops caus=
ed=20
by having annother <ask> within the template.
But other than this I would be happy to inlude this feature.
>
> Alright... it seems odd to first supply those two pieces of information as
> part of a technical help question, but that's the way it's worked out. So,
> the question is: without getting into the details of what kinds of
> information the site will hold, we would like some pages to be, basically,
> "summary" pages, giving a high-level overview of all the data in the site.
> This will involve getting more information than what can be retrieved in a
> single inline query: it involves not just relations to one entity, but al=
so
> relations and attributes of those relations, etc. In short, we're trying =
to
> replicate a "join" query in Semantic MediaWiki; apparently other people on
> this list have wondered about this same issue.
Yes, I know of use cases for this. <ask> currently displays results only up=
to=20
distance one from the retrieved articles (i.e. you can display things=20
relating to the article, but not things that again relate to these). I hope=
I=20
understood your request correctly ...
>
> We can think of four ways to implement it:
>
> - Embedding of new <ask> tags within query templates - using the
> custom-format feature we created, it might be possible to embed queries
> within one another, to give the desired results. There are possible
> problems with this approach: it might not be technically feasible (we
> haven't been able to get it working yet), it could result in infinite
> loops, and it could cause a performance problem if users create a chain of
> too many queries.
You cannot embed <ask> into <ask> due to parser issue in MediaWiki. MW=20
currently finds the ask-blocks for us, and it is confused if they are neste=
d.
But you are aware that there is a <q> tag that does exactly this? E.g. you =
can=20
have
<ask>[[borders::<q>[[population:=3D>80,000,000]]</q>]]</ask>
("What borders something with more than 80Mio inhabitants?")
Resolving those queries to their (string) results would be too slow, so the=
y=20
are currently incoporated into the SQL query directly.=20
>
> - Using SPARQL - use non-wiki pages that contain SPARQL queries to get the
> site's information via RDF export.
SPARQLing on the RDF-export is not feasible. You would need some backend fo=
r=20
doing this, probably some fast triple-store. Keeping this in sync with the=
=20
wiki is not so easy (we do this with the SPARQL endpoint provided for=20
ontoworld by selective crawling based on recent changes). But maybe it=20
suffices to have a synchronisation once a day -- I am writing an RDF dump=20
that will facilitate this.
>
> - Using SQL in the PHP - we could hard-code SQL queries into any page
> labeled as a "summary" page, the same way "category" pages have a special
> hard-coded query to give an alphabetical list of all pages with that
> category.
Sure, if your queries are that static. In fact, this could easily be an=20
extenstion to the extension (i.e. it need not even touch the code of SMW).
>
> - Custom inline queries - we could add a new parameter into <ask> tags,
> called "query". That way a user could just use <ask query=3D"queryname">,
> that would basically call a pre-defined, complex SQL query, with whatever
> parameters are passed in, and return HTML output.
That is a funny idea. Maybe a new tag different from <ask> should be used=20
there in order to prevent confusion (e.g. what happens if you have conditio=
ns=20
between the tags of a custom IQ?). Maybe such a mechanism of creating=20
approved query templates would be quite nice to have, also in order to allo=
w=20
some more expressive queries that would be restricted in general (e.g.=20
intersection of categories is problematic for large ones, but could work in=
=20
smaller cases).
If you go for this, then it would be nice to still consider whether the out=
put=20
facilities of the current IQ code could be reused in order to preserve comm=
on=20
look and features (e.g. result sorting).=20
>
> Any thoughts are welcomed.
Here they are.
Regards,
Markus
=2D-=20
Markus Kr=F6tzsch
Institute AIFB, University of Karlsruhe, D-76128 Karlsruhe
mak@... phone +49 (0)721 608 7362
http://www.aifb.uni-karlsruhe.de/WBS/ fax +49 (0)721 693 717
|