RE: ACTION: elaborate on 4.4

> 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