- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Thu, 1 Jul 2004 16:22:19 +0100
- To: public-rdf-dawg@w3.org
We have two protocol suggested: Joseki's RDF WebAPI [1] and in N3QL [2]. Both are HTTP GET based, using the GET query string. RDF WebAPI: The request is "http://modelURL?lang=<langURI>&query=<queryString>". The result is the matching subgragh. It can take additional parameters such as forcing the return of a result set as a graph. N3QL: The request is "http://serviceURL?<queryString>" The result is the constructed graph from the RHS of the "select". The difference in approach is between naming the query service and naming the query model. N3QL has a URL to a query service, and so does not need to name the query language. Different query languages would appear as different query services. It is simple to say what features a query service has in an RDF description because the query service has a URI. It is hard to describe the knowledge base characteristics - there is no name for the knowledge base itself. The RDF WebAPI names the model, and the service is identified by the addition "lang=" parameters but does not have a proper URI. It is hard to describe features of the service because it does not have a URI; it is easy to describe the knowledge base because it does have a URI (this helps in extending to an update protocol because the knowledge base updated is named). 3.8 Bookmarkable Queries Both have URLs for requests so are bookmarkable and cacheable. 3.12 Streaming Results Neither meet the streamability requirement. 4.4 User-specifiable Serialization Both allow MIME type negotiation. 4.5 Aggregate Query Both only allow one specified service. 4.7 Bandwidth-efficient Protocol Content negotiation can request compression. Andy [1] http://www.joseki.org/protocol.html [2] http://www.w3.org/DesignIssues/N3QL#HTTP
Received on Thursday, 1 July 2004 11:22:36 UTC