RESTful Web Service Description
This is a small work on how a RESTful web service be defined based on the description on the page on http://knoesis.wright.edu/research/srl/standards/sa-rest/ . This work treats SA-REST as a mechanism for only annotating RESTful Web services, as it is mentioned on the page. Other extensions of SA-REST are not considered.
E.g. Yahoo Geocode API
The Yahoo Geocoder has a RESTful API that can be used for performing Geocoding. Here is the sample URL
This returns the following output:
<?xml version="1.0"?> <ResultSet xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:yahoo:maps" xsi:schemaLocation="urn:yahoo:maps http://api.local.yahoo.com/MapsService/V1/GeocodeResponse.xsd"> <Result precision="address"> <Latitude>37.416397</Latitude> <Longitude>-122.025055</Longitude> <Address>701 1st Ave</Address> <City>Sunnyvale</City> <State>CA</State> <Zip>94089-1019</Zip> <Country>US</Country> </Result> </ResultSet> <!-- ws01.ydn.re2.yahoo.com uncompressed/chunked Fri May 15 18:50:28 PDT 2009 -->
This is the sample SA-REST description that I started off with. A few modifications and Issues are discussed following this
<html xmlns:sarest="http://lsdis.cs.uga.edu/SAREST#"> Geocoder Service : <p about="http://local.yahooapis.com/MapsService/V1/geocode"> <br/> <br/> The logical inputs of this service are <br/> The Yahoo Application Key : <span property="sarest:input" sarest:messageName="appid"> http://localhost:8080/YahooAPIs#YahooAPIKey </span> <br/> The Street : <span property="sarest:input" sarest:messageName="street"> http://localhost:8080/geocoder.rdf#Address </span> <br/> The City : <span property="sarest:input" sarest:messageName="city"> http://localhost:8080/geocoder.rdf#City </span> <br/> The State : <span property="sarest:input" sarest:messageName="state"> http://localhost:8080/geocoder.rdf#State </span> <br/> <br/> <br/> The logical outputs of this service are <br/> Longitude : <span property="sarest:output" sarest:messageName="longitude"> http://localhost:8080/geocoder.rdf#Longitude </span> <br/> Latitude : <span property="sarest:output" sarest:messageName="latitude"> http://localhost:8080/geocoder.rdf#Latitude </span> <br/> This service should be invoked using an <span property="sarest:action"> HTTP GET </span> <meta property="sarest:lifting" content="http://localhost:8080/SAREST/lifting.xsl"/> <meta property="sarest:lowering" content="http://localhost:8080/SAREST/convert.xslt"/> <meta property="sarest:operation" content="http://localhost:8080/ontologies/Services.owl#Location_Search"/> </p> </html>
A Java API for this was implemented. The API parses the SA-REST description into a service object. upon specifying the inputs, it performs the XSLT translation on the inputs and executes the service to produce a result. Converting back into RDF was difficult and left unimplemented as of now.
These are some issues that I have faced in the Implementation of a JAVA API that can be used for executing such a service. It would be great if we could discuss these from the point of view of a RESTful web service.
1. I have used a property sarest:messageName="appid" which helps in discerning what part of the REST URL string it is. (Refer the Yahoo API string)
2. Lifting and Lowering is defined to map the schema to the ontology and vice versa. However the input to the Input parameters do not have a schema - they just are strings that are appended to the URL. So it would make sense to have lifting and lowering for each input and output.
3. XSLT is not enough for lifting and lowering from RDF/OWL - the reason being RDF/OWL elements may have object type properties linked by references. XSLT cannot traverse these references. Moreover XSLT is implementation specific. I hence think that there might be a possible way to represent using another subject using language independent stuff. I am looking into things like SPARQL
4. Generating the URL string from the transformed inputs might require some specification as well- e.g. this particular example has parameters like a GET query. But some service might have a URL where the URL is made to look like a folder structure - e.g. in Flicker you might have http://www.flickr.com/photos/tags/fish/clusters/
5. Thinking about how a 'runat' property would affect the lifting and lowering