Dan,
A somewhat longer response with references to some of the discussion on
the list yesterday.
On 7/1/2010 6:30 AM, Dan Brickley wrote:
Hi Patrick,
<snip>
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
http://groups.google.com/group/alt.hypertext/msg/395f282a67a1916c 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?
Without pre-judging what needs to be changed (if anything), consider the
history of HTML 3.2. Possibly the most successful markup language of all
time.
HTML 3.2 did not:
1) Have puff pieces extolling its virtues in Scientific American
2) It did not have a cast of thousands of researchers publishing papers
and dissertations
3) It did not have near the investment in $Millions in various software
components
4) It did not take ten years and even then have people are lamenting its
lack of adoption
HTML 3.2 did have:
1) *A need perceived by users as needing to be met*
2) *A method to meet that need that was acceptable to users*
Note for purposes of the rest of this post I concede that I *don't know*
the answer to either of those questions for any semantic integration
technology. If I did, that answer would have been on the first lines of
this post.
What I am suggesting is that we need to examine those two questions
instead of deciding that RDF was right all along and users are simple
failing to do their part.
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
gurus.
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.
The proposed changes *may not* be the ones that are required.
On the other hand, saying that "we have invested $millions in RDF as is
so it has to work" should result in a return of "false" from any
reasoning engine. Including human ones.
The amount of effort expended in trying to stop the tides may be
enormous that that isn't a justification of a technique or even the project.
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.
It may not be a problem with RDF at all.
It could be that RDF is an entirely consistent and useful model, but
just not for any problem that users see.
That is really the question for adoption isn't it?
Do users see the same problem?
If they don't, building systems for problems they don't see seems like a
poor strategy.
Moreover, knowing they don't see it and continuing with the same
activity and expecting a different result, well, you know what repeating
the same thing and expecting a different result is.
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
computers.
Well, yes and no. XML enabled users to do what they wanted to do.
RDF on the other hand offers a single identity model. Not exactly the
same thing. Particularly not when you layer all the other parts onto it.
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.
The most awkward part of your position (and mine to be honest) is that
we are evaluating technologies from *our* perspective. What do *we* have
to do to *our* models, etc.
What's missing? Oh, yeah, those folks that we want to use our models.
;-) As Gomer Pyle would say, "Surprise, surprise, surprise."
Semantic technologies (and I would include RDF, topic maps and other
integration strategies) left users behind about a decade ago in our
quest for the *right* answer. I think we have the public's verdict on
the answers we have found.
That is not to say anything negative about RDF or topic maps or whatever
the reader's personal flavor may be, but to point out that we haven't
found the sweet spot that HTML 3.2 did.
I don't think there is a magic formula to determine that sweet spot but
I do know that telling ourselves that:
1) We have invested too much time and effort to be wrong
2) With better tools users are going to use what they haven't for a decade
3) Better user education is the answer
4) We have been right all along
5) etc.
isn't the way to find the answer.
Nor am I advocating that we spent years in recrimination about who said
what to who on what list and why that was at fault.
What I am advocating is that we fan out to try a variety of approaches
and keep up the conversations so we can share what may be working, what
looks like it is working, etc. Without ever tying ourselves into
something that we have to sell to an unwilling market of buyers.
Apologies for the length but I did not have time to respond adequately
yesterday and so have too long to think about it. ;-)
Hope you are having a great day!
Patrick
Hope you are having a great day!
Yes thanks, and likewise!
cheers,
Dan
--
Patrick Durusau
patr...@durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)
Another Word For It (blog): http://tm.durusau.net
Homepage: http://www.durusau.net
Twitter: patrickDurusau
