Hi!
One question: were there particular reasons why you
went for wrapping a
SERVICE round the Mediawiki API, rather than eg a SPARQL layer round the
SQL tables, suitable for SPARQL federation?
Yes, we don't have any idea how to do such SPARQL layer :)
Are there efficiency issues? Or did you think that
the SERVICE approach
was simply more user-friendly for the most commons APIs ?
Probably there will be efficiency issues too, in general RDF data model
is rather different from relational database date model, so translating
between them is not trivial, unless you take extremely naive approach,
in which case performance probably will be horrible.
SERVICE otoh is pretty easy to implement and it's flexible enough to
allow talking to many external APIs. Current proposal seems to be OK,
though may be changed if more user-friendly ideas come up.
--
Stas Malyshev
smalyshev(a)wikimedia.org