- From: Jim Hendler <hendler@cs.umd.edu>
- Date: Thu, 24 Jun 2004 13:56:58 -0400
- To: "Rob Shearer" <Rob.Shearer@networkinference.com>, "RDF Data Access Working Group" <public-rdf-dawg@w3.org>
OK, let me put this in my words -- you don't disapprove of the intermingling per se, you disapprove of this WG doing a protocol. In particular, you write: At 13:49 -0400 6/24/04, Jim Hendler wrote: >>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. >> but I find this odd because it is only the remote query of RDF that interests me, and almost all the applications my group does need this capability -- for example, we have a markup tool for images that wants to pull instance data from the RDF-store underlying a web portal -- and the tool needs to be able to work with any ontology against any portal, so we need a standard for both the query and the way to access that query (I admit I could live with a standard API as opposed to a standard protocol -- but the key is we need a standard or our business model fails) -JH At 10:40 -0700 6/24/04, Rob Shearer wrote: >> 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. -- Professor James Hendler http://www.cs.umd.edu/users/hendler Director, Semantic Web and Agent Technologies 301-405-2696 Maryland Information and Network Dynamics Lab. 301-405-6707 (Fax) Univ of Maryland, College Park, MD 20742 240-277-3388 (Cell)
Received on Thursday, 24 June 2004 13:57:33 UTC