Fwd: Re: [RSS-DEV] Re: Time for a name change?

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

Subject: Re: [RSS-DEV] Re: Time for a name change?
Date: Wed, 18 Sep 2002 10:01:47 -0400
From: Joseph Reagle <reagle@mit.edu>
To: rss-dev@yahoogroups.com, "e_vitiello_jr" <yahoo@perceive.net>

On Wednesday 18 September 2002 08:57 am, e_vitiello_jr wrote:
> 2. RDF.  Someone stated to me yesterday (it might have been Bill)
> that RDF doesn't impose that much of an overhead, and it helps the
> RDF people - they won't have to convert things to RDF before they can
> use them.

I was recently in a WG meeting where I asked why the spec made use of the
term "asynchronous" in the context of the term "channel" (which was not
appropriate) and spoke of a "Two Phase Request / Response" protocol: what
did asynchronous (and channel) mean in this context, and was this the same
or difference concept as the two phase? When the issue was raised someone
dismissed it with, "everyone knows what asynchronous means." I happily
responded, "in this context, I don't." (I figure I'm stupid enough to be
useful, but no more, no less. <smile/>) The fact that the question was
raised is evidence that it's not clear!

I have bountiful factual evidence (aside from the tautology <grin/>) that
for those that don't understand or care to understand RDF, understanding
RDF is a significant problem. Yes, one can say "it's only a little bit of
syntax" but if you don't explain that syntax well and *sell* the benefits
(which RSS1.0 does not do since it was written by folks fond of RDF), it's
a problem. There's three ways to sell RDF/SW:

(1) data hygiene: if you think about what you are representing your design
will be cleaner regardless. This is in contrast to the way most XML apps
are written, "write XML now, argue semantics later."
(2) semantic interoperability: being able to define these types and
equivelances can have a long term benefit in terms of semantic sharing and
interop.

In both (1,2) that's an up-front comprehension cost amortized with respect
to a longer term cost of extensibility/elegance. (See [1] for more.) That's
a hard sell to make, and some folks have bought into it, but not everyone,
understandably.

(3) useful tools: provide everyone with the tools to lower their short term
costs. (You can require X unit of tool comprehension cost, but then the
immediate unit of benefit must be greater than X.)

Given a relative limited number of RDF tools (though it's great to see all
the work going on!) that makes creating and generating RSS easier for the
ordinary developer (who is already using XML, XSLT, etc.), the short term
costs of 1&2 needs to be *minimized*. I'm a big supporter of the various
simplification schemes that minimize the RDF artifacts in XML (for those
who don't care and don't want "taxation without representation" -- to
extend Rael's metaphor) but preserves the model for those that do. I'm not
sure where I would stand if forced to choose between: no RDF artifacts
versus an extra step for RDF parsing (schema annotations, or some
transformation). Regardless, folks can even choose to proceed in the
context of presumed RDF comprehension but to say it's a trivial thing that
bothers no one is clearly and, as demonstrated over the years, painfully
wrong.

[1] http://goatee.net/2002/07.html#_18mo

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

-- 
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.

Received on Wednesday, 18 September 2002 10:05:45 UTC