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