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

Dan,

Sorry that I can't respond in depth. On deadline in one of the other 
standard universes. ;-)

You mention in closing:

> 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.
>
>    
Well, let's assume for the moment that the specs are what they are and 
we have decided to accept that.

Realizing that I prefer a more, ahem, pluralistic approach to 
identification, I wonder what "other" things we can fix other than the 
specs.

In OpenDocument, we are using RDF/RDFa to construct an extensible 
metadata mechanism that I think is one of the bright spots for the 1.2 
release. Arbitrary metadata for any content in the document, not just 
the document itself. I think there is enormous potential for greater 
granularity of access, etc. (sorry, for the promotional comments)

But, in the drafting of that part of the standard, I made some reference 
to the issue of users not following the advice (they never have in my 
opinion) of seeking common identifiers. They make up their own if they 
go that far. The response from an RDF expert was, "...that's a user 
problem."

Well, yes and no. We can say that users not following specifications, 
which we don't want to change, is a "user problem," but at some point if 
enough users don't follow the specification, doesn't that become our 
problem?

It is far from a settled question and I don't mean to imply otherwise 
but it seems to me that while stretching users by teaching new ideas, 
techniques, etc., that we also need to be mindful of their capabilities. 
It doesn't help to have the "best" system possible if no one is capable 
or willing to learn it. Or simply don't use it in fact.

Hope you are having a great day!

Patrick

PS: The comment was made in the "Subjects as Literals" thread:

> To be brief: I don't care if there are usecases for literals in the subject position. It you could rewind time 10 years I might like them in there, but we've invested millions of pounds in engineering RDF stores conforming to RDF 2004. I can't, and won't throw that work away for some relatively obscure benefits.
>    

I don't understand the fixity of RDF stores. If there is any continuity 
in computer science it is that data structures change. At one time 
relational databases were simply a hot new idea. Imagine all the money 
that had gone into the databases that came before them. It isn't lost 
investment anymore than any prior investment was lost. We do the best we 
can and then improve (hopefully, although I acknowledge that is a 
debatable point).


On 7/1/2010 6:30 AM, Dan Brickley wrote:
> Hi Patrick,
>
> On Thu, Jul 1, 2010 at 11:39 AM, Patrick Durusau<patrick@durusau.net>  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
> 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?
>
>    
>> 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.
>
> 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
> computers.
>
>    
>> 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!
>
> 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 Thursday, 1 July 2010 11:02:49 UTC