Hey Mark,
Ah. My current understanding (which isn't very current ;) is that
this isn't the intent of OPES. I think OPES is restricted to:
1. using the ruleset as a heuristic to match messages
2. doing things to those messages as a result
I'm trying to figure out the exact scope too. But I didn't mean to
suggest that all the workings of my example were part of OPES. It was
mostly just to point out how unimportant (IMO) a callout protocol is.
"doing things" encompasses vectoring to a proxylet/servelet; the
responsibility for honoring the semantics of the protocol (e.g.,
HTTP) are entirely the responsibility of the service. (OPES folks, is
this still the case?)
Hmm, not sure I follow that.
One of the things that always bothered me about ICAP was that it
advertised itself as taking away the burden of understanding HTTP
from the service authors. This simply isn't true; while some
low-level stuff like connection handling can be taken away, the hard
and most delicate part - the semantics - still need to be dealt with.
Exactly right. You can't abstract away the application semantics.
So, as I understand OPES, you have a situation where a service is
effectively split into two; the service provision and the heuristics
to stick in the ruleset to invoke it. If you're going to do this, I
think it makes sense to keep the protocol-specific semantics split
out into the rulesets, if possible.
Not sure I understand that either, but I'm sure that I just need to
do some more reading.
Mark, I know you've stuck your head into RDF/SW stuff. One of the
things I've been interested in doing for a while is writing a
"Semantic Web Server"; i.e., where HTTP messages are parsed into RDF
statements, and then contextual logic is applied to affect handling.
E.g.,
log:forAll :x, :y, :z .
{ :http_request headers:accept_language :x .
:http_response headers:content_language :y .
}
log:implies
{ http_response opes:invoke [ :service :lang_trans ; :from :y ; :to :x ] .
http_response headers:content_language :x .
} .
I think this is along the lines of what you're talking about. Doing
it as statements gives a nice way to introduce access control, trust,
etc.
For sure. But that looks more like a script rather than an assertion,
no (calculus vs. algebra)? Very IRML-like. For HTTP & the Semantic
Web, I was thinking more along the lines of redirects as statements
about resource identity, 4xx response codes as statements about the
client request, and 2xx as statements about the response. Headers are
also commonly statements about something. Roy Fielding identified
three types of headers[1]; two of these (the ones called "metadata") are
statements about things as well.
[1]
http://www.ebuilt.com/fielding/pubs/dissertation/rest_arch_style.htm#tab_5_1
But I digress ...
MB
--
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA. mbaker(_at_)planetfred(_dot_)com
http://www.markbaker.ca http://www.planetfred.com