W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2005

Re: Data binding resource

From: Bijan Parsia <bparsia@isr.umd.edu>
Date: Wed, 23 Mar 2005 18:16:24 -0500
Message-Id: <75a6f552faef4bdaeb23f703821fa4cd@isr.umd.edu>
Cc: "'public-rdf-dawg-request@w3.org '" <public-rdf-dawg-request@w3.org>, "'DAWG Mailing List '" <public-rdf-dawg@w3.org>
To: "Thompson, Bryan B." <BRYAN.B.THOMPSON@saic.com>

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 Wednesday, 23 March 2005 23:16:27 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:22 GMT