- From: Rob Shearer <Rob.Shearer@networkinference.com>
- Date: Tue, 23 Mar 2004 10:02:37 -0800
- To: "Seaborne, Andy" <andy.seaborne@hp.com>
- Cc: "RDF Data Access Working Group" <public-rdf-dawg@w3.org>
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. 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. 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? 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. > -----Original Message----- > From: Seaborne, Andy [mailto:andy.seaborne@hp.com] > Sent: 23 March 2004 02:28 > To: Rob Shearer > Cc: RDF Data Access Working Group > Subject: RE: thoughts and some refs about AFS-2 UC > (simplicity, minimalism ) > > > Rob, > > A query language on its own provides some benefits but it still means > developers are tied to a single toolkit for their application > and their > storage. I would like to see a simple protocol (c.f. the > concept of JDBC > but without the need for client-side specific drivers) so > that selecting the > RDF storage technology is separate from the choice of > application/business-logic level software. Whether that separation is > across the web or across a LAN, still requires agreement. A > recommendation > means that software providers can choose to provide systems > that can be > mixed. > > I'm not sure exactly what you mean by the term "distributed > query" - to me > it means wide area, federated data sources with source selection and > possibly query partitioning and routing. That is out of scope. > > Earlier Rob said: > > If one were able to express a query > > in text form and get a text result, then I think all the > other standards > > take over from there; it's pretty hard to screw that up in SOAP. > > True - but if the way one system decides to do it in SOAP is > different, even > at a trivial level, to another system means that apps are tied to one > toolkit. I see the access protocol as being the communicate means - > "protocol" is a grand, more like a documenting of a way to > use SOAP or HTTP > so there is mix-and-match of software components. > > Andy > > -------- Original Message -------- > > From: Rob Shearer <> > > Date: 22 March 2004 19:34 > > > > Sorry if I wasn't clear. I think KC and I are actually in > agreement (for > > the most part). > > > > I worry that two such deliverables are so independent that > they're not > > two parts of a single recommendation; they're two > completely independent > > recommendations. Scope, time frame, and member interest all > seem very > > different between the two. > > > > It also seems that the second document (distributed architecture) is > > dependent on the first (query language). > > > > I propose that this working group work towards an initial > free-standing > > recommendation which addresses query language only (as > always keeping > > longer-term goals in mind). After delivering that > recommendation, we can > > work toward a network protocol and distributed querying > architecture. > > > > > -----Original Message----- > > > From: Kendall Clark [mailto:kendall@monkeyfist.com] > > > Sent: 22 March 2004 11:21 > > > To: public-rdf-dawg@w3.org > > > Subject: Re: thoughts and some refs about AFS-2 UC > > > (simplicity, minimalism ) > > > > > > > > > > > > On Mon, Mar 22, 2004 at 10:59:32AM -0800, Rob Shearer wrote: > > > > > > > > I'm very skeptical of the "two document" approach to a > single RDF > > > > query spec. It strikes me as an artifical link between two > > > > independent issues. If we want to address both > problems, let's let > > > > them stand independently and vote up or down on them > independently. > > > > > > Maybe I wasn't clear? Our charter talks about a query > language and a > > > data access protocol. These strike me as rather orthogonal; hence, > > > specifiable in separate documents, both of which would be > deliverables > > > of this WG. Eventually we'll have to start thinking about the > > > documents this WG is going to produce, and it seems, at this very > > > early date, that something like a doc for the query > language and a doc > > > for the data access protocol (plus some supporting docs, > notably, a > > > primer) seems a relatively decent starting place. > > > > > > I'm not sure I know what you mean about "two independent > issues" and > > > "artificial links" between them, Rob. > > > > > > Best, > > > Kendall Clark >
Received on Tuesday, 23 March 2004 13:03:46 UTC