RE: thoughts and some refs about AFS-2 UC (simplicity, minimalism )

Rob - is your concern that any protocol work would slow down query work?

My impression, and given my background, is that there is more work in
getting the details of query pinned down than in a *simple* access protocol
- my impression may well be wrong of course.  (We also have the option of
using invited experts if we feel we do not have coverage.)  I don't see that
protocol work need alter Dan's timescale.

	Andy

Comments inline.

> -----Original Message-----
> From: Rob Shearer [mailto:Rob.Shearer@networkinference.com] 
> Sent: 23 March 2004 18:03
> To: Seaborne, Andy
> Cc: RDF Data Access Working Group
> Subject: RE: thoughts and some refs about AFS-2 UC 
> (simplicity, minimalism )
> 
> 
> I think the JDBC example is quite apt. It's a great 
> technology (compared to what came before), but it's quite 
> independent of its SQL payload.

We agree here - the QL and the access mechanism are reasonably independent.

> 
> I can see a good argument for a JDBC-style standard, however 
> I worry this working group would be wasting its time to dwell on it.
> 
> First, it's worth noting that JDBC is *not* a web service or 
> network protocol. It's a client programming interface. This 
> distinction makes its design much much simpler. If you've got 
> a client library sitting right underneath you, then you have 
> a place to put all your implementation-specific 
> optimizations. This means that you can always err on the "too 
> fine-grained" side during API design. Return of result sets 
> can be broken down into tiny micro-ops like iterating from 
> row to row, and the client library will do lots of clever 
> coordination in terms of when data actually gets shifted 
> across the network. If you're just defining the network 
> protocol itself, you need to build in the superset of all 
> operations that might be useful, providing maximum 
> flexibility. I think this is possible, but I see it as a 
> totally distinct exercise from query language construction, 
> requiring entirely different member backgrounds and 
> expertise. A solid understanding of RDF just doesn't seem 
> that relevent to this task.

We agree the tasks are separate.

The "web" part of the "semantic web" is important to me.  Islands of RDF are
not as good as access to RDF on the web so I see much more value in
query+access mechanism than query on it own.  Today, many toolkits have some
query solution - common query is nice but hardly pressing. As soon as one
system can access another common query sessential.

> 
> I also worry that we'd end up getting bogged down in details 
> that other standards are already working on. There is already 
> plenty of work going on with respect to RPC and access 
> control; is it really worth even tinkering in that area ourselves?

I see it as important that there is one, common way of accessing remote
data.  Because it is possible various different ways does not deliver a
pluggable interface.  The system designer has to be concerned with details
of one approach over another - details that are irrelevant to the app being
built or RDF being published.  As a data provider, I won't want to support
many varieties of SOAP or HTTP packaging - just give me one.

> 
> If we really want to, then I think we can come up with a big 
> set of SOAP functions (or some such) which constitute a 
> mechanism for passing a query and retrieving results. I even 
> think Network Inference could directly benefit from such a 
> standard. I just think we should put first things first and 
> start with the query language itself. Once the language is 
> standardized, simple connectors (with a straightforward client-side
> interface) will be extremely simple to create, and it won't 
> be difficult to write facades to get different systems 
> working together.
> 
> As an engineer, I think standardization of the network 
> protocol is helpful but not necessary. It's the query 
> language I can't build on my own.

We all could build our own, different protocols (I have!) but I think that
is not helpful.  That is also why we are here on query - there are many
different QLs for RDF.

An RDF publisher can't publish data to some application without one, or
both, having to know the details of the protcols of the other - a priori
knowledge of the other end.  Not good for the web.  The value of standards
here is not new stuff but in agreeing the details so code (client-side
library, server-side interface) can be written once and reused.  Otherwise,
each side needs many adapters and take-up is slower.

With a common protocol, all languages work and all library writers (both
client and server) have to implement once.

	Andy

Received on Tuesday, 23 March 2004 15:55:17 UTC