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

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
patrick@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

Received on Friday, 2 July 2010 09:09:53 UTC