- From: Thompson, Bryan B. <BRYAN.B.THOMPSON@saic.com>
- Date: Wed, 23 Mar 2005 19:43:12 -0500
- To: 'Bijan Parsia ' <bparsia@isr.umd.edu>, "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>
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