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<[email protected]> 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
[email protected]
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
