Re: Google API -> Jena

----- Original Message -----
From: "Dan Brickley" <danbri@w3.org>
To: "Jeremy Carroll" <jjc@hplb.hpl.hp.com>
Cc: <www-rdf-interest@w3.org>
Sent: Friday, April 19, 2002 8:34 AM
Subject: RE: Google API -> Jena

[...]

> I've started to hack on this (in Ruby, having dumped Perl :)
>
> rough scribbles:
> http://www.w3.org/2001/12/rubyrdf/squish/service/webfetch_tests.rb
>
> ...currently gets a result set through (by hand) doing part of the query
> against a local RDF graph, and part by calling a (different, scraped
> still) Google backlinks API. This is an obvious candidate for automation
> based on Web service description, and seems to offer a nice curve from
> 'simple stuff do-able now' to 'phd territory distributed query'. I've no
> plans to go near the latter end! I do want to make demos that show some
> basic Web service composition techniques though, ie. a single RDF query
> serviced by consulting multiple Web services and binding the results
> together, where the decomposition into sub-tasks is done by reading
> RDF service descriptions (WSDL++++?).

Hi Dan,

We experimented with this concept some a bit ago
(http://www.intellidimension.com/SWB/beta/). We used simple (home-grown) rdf
service descriptions
(http://www.intellidimension.com/SWB/Docs/sentences.asp) to chain together
web services (generally of the scraped variety) to get to desired results
from available input. We were working on the client side so we provided an
interface that allowed the user to choose between paths when multiple paths
were available (e.g. when two web services provided the same type of
information needed as input for another service). Of course in a different
implementation you could imagine making that decision based upon other
factors such as cost, reliability, speed, etc. (i.e. based upon the value of
the information source to the query - see
http://www.intellidimension.com/Whitepapers/sw_value_chain.htm for some
rough thoughts on that topic)

We also experimented some with using the web services as data services
(which in our system means things that have a triple interface). In that
usage, they just become triple feeds to queries. We also found as you did
that it's often awkward to expose services through this interface (i.e. they
often can be called with only a single binding pattern and with certain
fixed properties - something the query writer must be aware of to get
results). We looked at some combination of these two models (chaining of
richly described services vs. data services) to try to get around this
problem but never got as far as implementing the ideas. It would be
interesting to hear about what you come up with.

- Geoff

Received on Friday, 19 April 2002 09:42:17 UTC