Re: Toying with an idea: RDF Protocol

"Karsten-A. Otto" <ottoka@cs.tu-berlin.de> writes:

> I like the idea of an RDF Protocol, but IMHO it should then be
> *pure* RDF and, by consequence, use pure XML. So I dont understand
> your design decision to use FORMFEED as a separator. In my
> experience an XML end tag is enough to delimit scope.

Using packets of well-formed XML, one can use any existing parser to
parse each chunk or block as it shows up.  Using packets of
well-formed XML also scales better over different types of transports
with varying qualities of service, some of which may not be "stream"
connections, or may be stream connections with their own chunking
technique.  This makes for good "canonical" session and event handling.

On the other hand, it's likely that one could easily view it as a pipe
of incoming triples and it really doesn't matter what form they come
in as.  There would appear to be no technical reason not to be able to
support incremental parsers producing streams of triples.

> Also, why do you want each "message" to be a whole RDF Model? There
> is a dc:Type element, which defines the nature of the contents of a
> resource description; among other things it can indicate an "Event".
> You could use this to define a "message" to be an inline resoure
> (rdf:ID) of dc:Type Event, within the context of a singe RDF Model
> that defines a kind of "session" starting with the <rdf:RDF ...> and
> ending with </rdf:RDF> (the later meaning quite literally "There is
> nothing more to be said" :-).  You could also send other RDF than
> Event messages to provide session specific or longer lasting data,
> such as presence information or a list of IRC channels you joined.

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.

What I mean when I say that, is that events need not re-send triples
that have already been transmitted (note quality of service issues --
receivers need to know if they have all the triples they need).

Are you referring to just syntactical or serialization shortcuts?  I
can see how that would be an optimization in the context of a single
stream.

> If you check the Jabber links provided by Alberto, you will see a
> similarity to the ideas above. Actually I am currently using Jabber
> for event passing with some success, but as my project is moving
> towards RDF a pure RDF protocol probably fits better...

Yes, I read several of the links, paying particular attention to the
protocol link.  There's nothing inherently wrong with how Jabber's
protocol works for Jabber.  The question becomes, if we wanted to look
at it this way, how can we generalize it so it works for other
applications, applications that may be completely foreign to the way
jabber works?  Then we take a few steps: 1) send RDF triples instead
of plain XML, 2) seperate 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.

  -- Ken

Received on Tuesday, 27 March 2001 11:28:52 UTC