Re: Toying with an idea: RDF Protocol

Ken MacLeod wrote:

> Using packets of well-formed XML, one can use any existing parser to
> parse each chunk or block as it shows up.

You are right here, it is difficult enough to make a parser parse
stream data "as it arrives" without waiting for an EOF. On the other
hand you get some overhead from the <?xml...> and <rdf:RDF xmlns:...>.
At least the namespaces can be established once at the beginning of
the session (the M&S states that "The RDF element is optional if the
content can be known to be RDF from the application context").

The main difference between chunked and streaming approach here is the
semantics of transmitted data. With (self contained) chunks, each
message represents a complete RDF model. With a "stream" of triples,
a "session" is a single RDF model that changes over time.

The choice of semantics depends on the way the message data is supposed
to interact with the sending/receiving application. Are the message
triples simply added to the applications internal data model? Is it
an "event" that the application interprets to change its internal model?
What if the application does not use RDF internally?

> If I understand correctly, you're saying that the session can hold
> more of the context of the session, so that each event doesn't need to
> duplicate information.  I agree with that in principal, so there
> shouldn't appear to be a conflict in what I wrote.

Yes, and some more. This again refers to the incremental model
represented by a "stream". Obviously one needs a way to mark data as
volatile, that is, after the application processed it it is removed
from the model. For example, you probably don't want to keep each IRC
message that you ever received. However, non-volatile data can also
be transmitted, which stays a part of the model and thus of the session
as long as it lives. This feature can be used to store session context,
as you say.

> Then we take a few steps: 1) send RDF triples instead
> of plain XML, 2) separate the concept of "unit of information"
> (packet) from "carrier" (stream), 3) allow packets to be carried in
> ways other than streams, and within different types of streams.

I agree. Let me clarify that by saying "stream" above I only mean
successive chunks of data, not a TCP stream. The data is RDF serialized
as XML. Any additional features such as sequence ordering needs to be
done by the application, preferably contained in the transferred RDF
itself. For example, there could be an rdfp:sequenceID property with
the message, or the the same rdf:ID could be used for an "response" to
a "request" message.

KAO

Received on Wednesday, 28 March 2001 07:59:24 UTC