Fwd: Re: [RSS-DEV] To RDF, or not to RDF? That is the question!

----------  Forwarded Message  ----------

Subject: Re: [RSS-DEV] To RDF, or not to RDF?  That is the question!
Date: Thu, 25 Jul 2002 13:06:36 -0400
From: Joseph Reagle <reagle@mit.edu>
To: rss-dev@yahoogroups.com

On Wednesday 24 July 2002 07:37 pm, burton@openprivacy.org wrote:
> I am having the same problem with the modules I am working on right now.
> When I use all of them at once (and they are RDF) the format is NOT
> simple (far from it).  However when I simplify the format, make it
> nested, simple, and more 'XML friendly' the format is easy to use but
> ceases to be RDF.

I've been through the XML v. RDF ringer a few times, and I've been thinking
about this very issue since I'd like to see RSS become more widely
(interoperably) used. In my understanding, the issues fall into three
categories: the model, the syntax, and the application. I'll give some
examples from my experience with XML Signature (xmldsig)

THE MODEL: How do you take your pain?

One of the difficulties with many applications, particularly XML, is that
people tend to "write syntax first, argue semantics later." The nice thing
about XML is I can quickly right some syntax, get about 80% of the
semantic/processing out there quickly, and worry about the other  stuff
later. Ah, but that "other stuff" can end up also causing you 80% of your
headaches [1], particularly in the security space. In xmldsig, I thought
about the KeyInfo model and had a decent understanding of the semantics
which informed the spec, but wasn't explicitly represented. KeyInfo was
supposed to contain the key (and other optional information) used to
validate a signature. For instance, I could have:
  <KeyInfo><KeyName/><KeyValue/><KeyInfo>
I know there is some key, used to validate the signature, and it has a
properties (e.g,. names) and a value. However, after time folks asked, "if
there is only one validating key, I can understand it having more than one
name associated with it, but there should be only one KeyValue, why does
the schema permit more than one?" This was an error in the schema on my
part, but it then invited debate between those that wanted to preserve the
existing "singular semantic" of the text and those that wanted to continue
to use the liberal schema definition in which KeyInfo is a bucket of key
stuff with no necessary correspondence between any of the children. This
was an unfortunate argument to have that late in the game. *So* the model
(be it in RDF, UML, or some other thing) is important to the hygiene,
interoperability, and reuse of your application. Of course, you have to
balance the upfront cost of designing a perfect model to the later cost of
snafu's like this one [3]. I think RDF itself is similar. There's a global
benefit of "semantic interoperability" [4] (once the network effect kicks
in) but with a localized and upfront comprehension cost.

[1] http://goatee.net/2002/07#_11th
[2] http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2001JanMar/0117
[3] http://goatee.net/2002/07#_18mo
[4] http://www.w3.org/TR/md-policy-design#_Applications_and_Semantics

THE SYNTAX: Sugar or Salt

While I now would've preferred a better and more widely understood data
model for xmldsig, I unfortunately approached RDF just like most approach
XML: I started fidgeting with the syntax first! If you haven't given much
thought to the model, the RDF syntax is unmotivated and ugly: syntactic
salt. For instance, in xmldsig we had a <SignedInfo> element which includes
digests of the actual things being signed and the canonicalization and
signature method. I was never sure how to model this because the reason
this syntax existed was for processing and security purposes: you need to
create a bucket of bits to sign, including the signature method, to prevent
attacks. This wasn't so much about modeling an assertion, but marshaling a
bunch of syntax to be hashed. However, I think xmldsig (and encryption even
more so) are the exceptions. They are really octet and XML processing specs
-- less so applications written in XML. To those that are unconcerned about
the model or those that aren't terribly good at it -- I count myself in
this group -- the salt can be minimized. I thought RSS 1.0 did this well.
Additionally, things can be sweetened up a bit. As many folks have already
suggested, I feel RSS 1.0 could've done a better job explaining what those
constructs mean to someone who doesn't give a fig about RDF.

THE APPLICATIONS: How's it taste?

This is the critical bit of course, forgetting historical and philosophical
arguments, do the content syndication applications work and interoperate?
The better your model, the better you are served -- but nothin is perfect.
To those that don't like it bitter, the brew can be sweetened. And, I
believe, that a requirement on future work should be that a future RSS
should be able to be easily used by both "fast custom crafted XML" and
"flexible generic RDF" applications. <smile/>

--

Regards,          http://www.mit.edu/~reagle/
Joseph Reagle     E0 D5 B2 05 B6 12 DA 65  BE 4D E3 C1 6A 66 25 4E

* This email is from an independent academic account and is
  not necessarily representative of my affiliations.

-------------------------------------------------------

-- 

Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature/
W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/

Received on Thursday, 25 July 2002 13:10:53 UTC