- From: Rob Shearer <Rob.Shearer@networkinference.com>
- Date: Thu, 24 Jun 2004 10:40:12 -0700
- To: "Jim Hendler" <hendler@cs.umd.edu>, "RDF Data Access Working Group" <public-rdf-dawg@w3.org>
> WHY do you believe we should keep this independent and that it is > bizarre (your word) to do this? The main point is that a query language is valuable independent of protocol. Further, from a practical point of view I'm quite skeptical that this group will be able to come up with a general or robust protocol. No matter what protocol decisions we make, they will not be appropriate in all circumstances. Want to query a local RDF store (like in-process access to an RDF config file)? You probably want just an API, no network protocol. Want to connect to a remote RDF repository that's not under your control? You probably want an easily implemented universal protocol. Want to build a vertical app with a networked RDF store in its core? You probably want a robust and efficient protocol, even if that requires complex state management between client and server. > It seems to me that many very > successful protocols do indeed interact with the things they serve in > various ways (cf. http and mime types, http design and html) The fact that HTML has meta-data for HTTP headers in it is admittedly some slight inter-mingling (and I argue that's it's generally undesirable). But an HTML file does not, for example, contain different sets of information based on what Accept: header is passed in HTTP. HTML is a useful standard because it does what it does, and no more. If you had to perform complex programming for the special case of somebody wanting a different kind of HTML, then you'd lose both the simplicity of HTML that has spurred widespread adoption and the upper-layer transformations that have been added to web servers and plugins to overcome problems that were not foreseen when HTML was designed. > and the > same is true in many query systems - esp. datalog- and OODB- based > protocols where it is not uncommon for some sort of information about > the query form to be part of the protocol (often simply as a > parameter to the query that can be brought in separate from the query > form itself). I'm not an expert on JDBC, but I understood that it > also had some mechanisms (maybe they're system adds) to do this for > reporting back the results of SQL queries (sort of the opposite - > i.e. the protocol was specifically designed for the query language) This is a very important point. JDBC is not a protocol. JDBC is an API. The actual over-the-wire format is entirely implementation-dependent. JDBC simply provides Java-language wrappers such that you can pass SQL to a database and collect the results. > I'm not arguing, I'm just saying it does not seem /a > priori/ bizarre > to me to see a Web-based protocol and a Web-based language assumign > some sort of interaction with respect to Web formats and language > issues. > thanks > JH I think a query language is much much more important at this stage in the game than a network protocol, and I am quite sure that a good language would be used in many cases where a protocol would not. The concept of publicly-accessible RDF repositories sitting on the network is appealing, but I think it's a long way off. Issues like brokering, discovery, and aggregation need to be addressed before the "global distributed RDF knowledgebase" becomes a reality, and there is no chance at all that this group will find decent solutions to those problems. For the foreseeable future, I am confident that the vast majority of RDF applications will be a client application connecting to an RDF repository for which it was explicitly programmed. To be honest, from a developer's point of view it's the query language that requires the real investment. Hiding protocol behind a JDBC-like API for the purpose of future modification or optimization is already standard programming practice.
Received on Thursday, 24 June 2004 13:42:11 UTC