RE: Data binding resource

Bijan,

I'm not arguing for or against anything SPARQL specific.  What you
describe could certainly work for a large majority of use cases. However,
there will be use cases where the application wants to take advantage
of the native features of the protocol, or the optional or extension
features of the protocol that are supported by a given service.  What
is missing is perhaps a "protocol" description layer, since there are
interactions that can be only described when the connection to the
service is using a given protocol.  This means that the protocol is
part of the application, which, no surprise, is what it means to be
an application protocol.

What kinds of things are necessarily protocol features?  Caching,
intermediaries and the like.  Many other things which are sometimes
pushed into the protocol could, of course, be seen as service features,
but caching and intermediaries, etc. are features of the connection,
not the service, but nevertheless can also often features of the
application.

-bryan

-----Original Message-----
From: Bijan Parsia
To: Thompson, Bryan B.
Cc: 'public-rdf-dawg-request@w3.org '; 'DAWG Mailing List '
Sent: 3/23/2005 6:16 PM
Subject: Re: Data binding resource

On Mar 23, 2005, at 4:59 PM, Thompson, Bryan B. wrote:

> Bijan,
>
> The only problem that I have with data binding is that protocol
> messages can be more complex than the parameters exposed for a
> give message.

That's probably true in general, though you can use fairly complex 
schema typing to handle a lot of that. Union types for example. In any 
case, the case seems clear enough for SPARQL, where the protocol 
messages aren't that complex or variant.

>   Sometimes you can configure these parameters in
> a factory for messages for the protocol for a target, but that
> is an attempt to factor out additional complexity, e.g., header
> options, that are not making it into your method description.
> The thing about the protocol layer is that it is partly orthogonal
> to the service description layer.  It is hard to get all of those
> rich options into an API for a strongly typed language.

There are, of course, tradeoffs with using static types, including the 
loss of certain types of expressivity (i.e., usually fewer legal 
programs). Also, most type systems are too inexpressive to capture all 
the constraints one is interested in. In general, you have to decide 
what constraints are usefully pushed into the type system and which 
should be handled elsewhere.

Again, in the SPARQL context, I think we can push a considerable and 
useful amount in. I'm particularly interested in data binding the 
results which I think could shield a lot of programmers from even 
imagining that they are using RDF at all. I imagine it will be even 
smooth for XQuery.

Cheers,
Bijan.

Received on Thursday, 24 March 2005 00:43:24 UTC