Re: "destabilizing core technologies: was Re: An RDF wishlist

Hi Patrick,

On Thu, Jul 1, 2010 at 11:39 AM, Patrick Durusau <> wrote:
> Dan,
> Just a quick response to only one of the interesting points you raise:
>> It's clear that many workshop participants were aware of the risk of
>> destabilizing the core technologies just as we are gaining some very
>> promising real-world traction. That was a relief to read. For those
>> who have invested time and money in helping us get this far, and who
>> had the resources to participate, this concern was probably enough to
>> motivate participation.
> It might be helpful to recall that "destabilizing the core technologies" was
> exactly the approach that SGML took when its "....little annoyances
> [brought] friction and frustration to those working with [SGML]..."
> There was "...promising real-world traction."
> I don't know what else to call the US Department of Defense mandating the
> use of SGML for defense contracts. That is certainly "real-world" and it
> seems hard to step on an economic map of the US without stepping in defense
> contracts of one sort or another.

Yes, you are right. It is fair and interesting to bring up this
analogy and associated history. SGML even got a namecheck in the
original announcement of the Web, see and
even today HTML is not yet re-cast in terms XML, much less SGML. Many
today are looking to JSON rather than XML, perhaps because of a lack
of courage/optimism amongst XMLs creators that saddled it with more
SGML heritage than it should now be carrying. These are all reasons
for chopping away more bravely at things we might otherwise be afraid
of breaking. But what if we chop so much the original is
unrecognisable? Is that so wrong? What if RDF's biggest adoption
burden is the openworld triples model?

> Clinging to decisions that seemed right at the time they were made is a real
> problem. It is only because we make decisions that we have the opportunity
> to look back and wish we had decided differently. That is called experience.
> If we don't learn from experience, well, there are other words to describe that.


So, I wouldn't object to a new RDF Core WG, to cleanups including eg.
'literals as subjects' in the core data model, or to see the formal
semantics modernised/simplified according to the latest wisdom of the

I do object to the idea that proposed changes are the kinds of thing
that will make RDF significantly easier to deploy. The RDF family of
specs is already pretty layered. You can do a lot without ever using
or encountering rdf:Alt, or reification, or OWL DL reasoning, or RIF.
Or reading a W3C spec. The basic idea of triples is pretty simple and
even sometimes strangely attractive, however many things have been
piled on top. But simplicity is a complex thing! Having a simple data
model, even simple, easy to read specs, won't save RDF from being a
complex-to-use technology.

We have I think a reasonably simple data model. You can't take much
away from the triples story and be left with anything sharing RDF's
most attractive properties. The specs could be cleaner and more
accessible. But I know plenty of former RDF enthuasiasts who knew the
specs and the tech inside out, and still ultimately abandoned it all.
Making RDF simpler to use can't come just from simplifying the specs;
when you look at the core, and it's the core that's the problem, there
just isn't much left to throw out.

> Some of the audience for these postings will remember that the result of
> intransigence on the part of the SGML community was XML.

XML was a giant gamble. It's instructive to look back at what
happened, and to realise that we don't need a single answer (a single
gamble) here. Part of the problem I was getting at earlier was of
dangerously elevated expectations... the argument that *all* data in
the Web must be in RDF. We can remain fans of the triple model for
simple factual data, even while acknowledging there will be other
useful formats (XMLs, JSONs). Some of us can gamble on "lets use RDF
for everything". Some can retreat to the original, noble and neglected
metadata use case, and use RDF to describe information, but leave the
payload in other formats; others (myself at least) might spend their
time trying to use triples as a way of getting people to share the
information that's inside their heads rather than inside their

> I am not advocating in favor of any specific changes. I am suggesting that
> clinging to prior decisions simply because they are prior decisions doesn't
> have a good track record. Learning from prior decisions, on the other hand,
> such as the reduced (in my opinion) feature set of XML, seems to have a
> better one. (Other examples left as an exercise for the reader.)

So, I think I'm holding an awkward position here:

* massive feature change (ie. not using triples, URIs etc); or rather
focus change: become a "data sharing in the Web" community not a
"doing stuff with triples" community
* cautious feature change (tweaking the triple model doesn't have many
big wins; it's simple already)

If we as a community stop overselling triples, embrace more
wholeheartedly their use as 'mere' metadata, fix up the tooling, and
find common cause with other open data advocacy groups who [heresy!]
are using non-triple formats, the next decade could be more rewarding
than the last.

If we obsess on perfecting triples-based data, we could keep cutting
and throwing out until there's nothing left. Most people don't read
the W3C specs anyway, but learn from examples and tools. So my main
claim is that, regardless of how much we trim and tidy, RDF's core
annoyingness levels won't change much since they're tied to the
open-world triples data model. RDF's incidental annoyingness levels,
on the other hand, offer a world of possibility for improvement.
Software libraries, datasets, frameworks for consuming all this data.
This being in the W3C world, we naturally look to the annoyingness in
the standards rather than the surrounding ecosystem. I'm arguing that
for RDF, we'd do better by fixing other things than the specs.

> Hope you are having a great day!

Yes thanks, and likewise!



Received on Thursday, 1 July 2010 10:39:27 UTC