RDF and Managability

["Sean B. Palmer" <sean@xxxxxxxxxxxxxxxxx>]

[From an IRC discussion on just how easy it is to consume and produce
RDF compared to XML using off-the-shelf XML applications and
off-the-shelf RDF applications.]

Ken MacLeod:
   I think I'm with tbray on this one, "And if you're going to do some
dumbed-down subset instead of full RDF, you might as well just publish
a standardized transformation from a nice idiomatic Atom feed to real
full first-class RDF."

Sean B. Palmer:
   What does he mean by "dumbed-down subset"? It's either RDF, or it's
not RDF, as far as I know, (i.e. you can either parse it with current
RDF/XML parsers, or y'can't).

Ken MacLeod:
   I read "a dumbed-down subset" as a restricted serialization, a la
RSS 1.0.

Sean B. Palmer:
 So did I. But RSS 1.0 is "real full first-class RDF". Restricted
serializations are still fully functioning, operational RDF documents.

Ken MacLeod:
   In one direction.  In the other direction (creating a special RDF
serialization for a specific application, "syndication"), it's "dumbed
down".

Sean B. Palmer:
   I don't think so, unless you're referring to inextensibility. But
then, it'll have just as much extensibility as !(Echo|Atom) would have
with a RELAX NG grammar. RDF is there to build applications on top of,
in every way as much as XML is there to build applications on top of.
I don't think you'd consider XHTML or RSS 0.9x a "dumbing down" of
XML.

Ken MacLeod:
   I'm referring to class of use.  In one class, I can use my RDF tool
to export RDF.  Boom, done.  In another class, I need an output
translator to create a restricted output serialization.  If an output
translator is needed, why not make it bidirectional in the
first-place? The other side of the issue is that dividing it up into
classes like that breaks "view source", when two different syntaxes
are used in the wild (one between RDF tools and one between RDF and
non-RDF tools).

Sean B. Palmer:
   Well, if you can get away with not having to intorduce an extra
step for RDF consumers, rather than producers, I think that that's a
good idea. I don't want to have to write a filter for every new
language that comes along that is "nearly" RDF. If I have to write
filters for the output, then fair enough--you can't get around
canonicalization since XML tools need it.

To summarize, I've produced the following tables. Production refers to
having !(Echo|Atom) information, and having to serialize it in XML or
RDF. Consumption refers to parsing. The grades are EASY => OKAY =>
HARD. For HARD, it denotes having to write a filter or transformation
of some sort. OKAY implies adding a few extra lines of code to get
around some burrs. EASY refers to just having regular code. All of
this is from the point of view of someone wanting to actually write
code with which to parse and output !(Echo/Atom).

XML       | Produce | Consume |
-------------------------------
XML tools |    EASY |    EASY |
RDF tools |    HARD |    HARD |

Canon-RDF | Produce | Consume |
-------------------------------
XML tools |    OKAY |    OKAY |
RDF tools |    HARD |    EASY |

RDF       | Produce | Consume |
-------------------------------
XML tools |    OKAY |    HARD |
RDF tools |    EASY |    EASY |

These are, of course, arguable, and presented quantitatively when
really it's a qualitative issue. How hard is it for XML tools to
accomodate a few RDF elements and attributes? I've said OKAY. RDF
zealots will argue EASY, anti-RDF zealots will argue HARD.

But the underlying tone: it'd be nice if we could keep the discussions
practical, flame free, based on technical issues, and grounded in use
cases and how people will actually feel from day to day being forced
to use the format.

--
Sean B. Palmer, <http://purl.org/net/sbp/>
"phenomicity by the bucketful" - http://miscoranda.com/