RE: ACTION: elaborate on 4.4

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