[
Lists Home |
Date Index |
Thread Index
]
Shelley Powers wrote:
> Because, Tim, there are implementations of RDF/XML as described, including
> Mozilla and RSS 1.0. I know you don't approve of them, but they are real,
> they are production, they are in use. Bitch about them as much as you
> want,
> but people use them.
My problem is that there are not as many implementations as there should
be, given the Web's crying lack of machine-processable information. I
think one of the main reasons is people looking at RDF instances and
saying "that's hideous and I can't see those 3-tuples you're telling me
about", then maybe warming up to it a bit and actually trying to *write*
RDF for the first time and always getting it wrong.
> Someone mentioned recently that as grand as it sounds to just throw out a
> spec when everyone decides that it's "bad", one has to take into account
> existing customers. This includes at least 50+ tools and apis that are
> built
> on the existing RDF/XML, not to mention applications that are using these
> tools, APIs, and the RDF/XML as written.
<famous-anecdote>Stuart Feldman, the Bell Labs guy who invented "make",
woke up one morning a few weeks after he'd released it, and realized
that the syntax basically sucked - all those tabs and colons and weird
continuation rules. He started working on something better and was shot
down because someone said "Stuart, there are *dozens* of people using
this, it's too late to change it."</famous-anecdote> I think the number
of people who are now using RDF is comparable, in relation to the number
of people who need something like RDF, to the couple of dozen make users
in 1970-something. It is *not* too late to fix the RDF syntax, it just
takes some courage and initiative.
> HTML was also "bad". But when XML came along we didn't throw out HTML
???? HTML was by no means "bad". It was exactly what the world needed,
and millions of people started using it because they liked it and
because they could do "view source" and figure it out. My gripe with
RDF/XML is precisely that it's failing to learn this lesson from HTML's
success. Thus not enough people are using it, even though it's arguably
what they need.
> The RDF Working Group was given a charter not to rewrite RDF/XML but to
> answer issues and provide as much cleanup and clarification as they could
> but to still remain within that support for previous implementations. It's
> sad that one can't just throw things out and start over again, but that's
> the way of the real world.
No it's not and yes you can, and you should.
> You came up with a RDF/XML that you say meets all of the requirements
> of the
> RDF model.
I make no such claim. I came up with a syntax that is good sound XML
and allows the encoding of triples in a way that's obvious to the human
eye and to the machine and eschews qnames so that there's only one way
of naming things, one that all deployed Web machinery already supports.
I do *not* claim that it meets all the requirements of RDF, but I do
claim that any "requirements" it doesn't meet are likely on the other
side of the 80/20 divide. There are people in the RDF camp who think
that to gain acceptance RDF needs to grow and become richer. On the
contrary: I think RDF is where SGML was in 1996, i.e. proven to be a
good idea but not widely implemented because ordinary people couldn't
figure it out. What RDF needs is the equivalent of XML, a brutal
reduction (at least at the syntax level) that hits 80/20 points and
anybody can figure out in 15 minutes by looking at it.
> In fact, as contentious as the XML world is, we can
> guarantee that people will find fault with whatever you come up with. With
> what anyone comes up with. It's a fact of a life.
You're right, but that's not necessarily bad. When smart people hash
out technical disagreements in public, progress occurs. A thick skin is
pretty essential.
> But don't just come along and say it's "bad" without coming up with a plan
> that will allow a better version to co-exist with previous
> implementations,
You or I could write the software by this time tomorrow that could parse
RPV and turn it either into conventional RDF/XML or feed it as triples
into one of the APIs out there. I'm not saying RPV is the way to go,
it's just a challenge: it proves that you there is a way to encode
resource/property/value triples in XML that is human-readable and
human-writeable.
The proponents of RDF (including myself) say that RDF's value add is
that it allows the efficient interchange and manipulation of R/P/V
triples. I happen to believe this propaganda and I also believe that
one of the obstacles is the human-incomprehensible syntax. If you
believe that RDF/XML's current syntax is not a problem please continue
with your project of trying to sell it to the world, but it feels to me
you're trying to accomplish a good thing with one hand tied behind your
back.
> But I do tire of people saying "bad", without specifics and solutions.
Specific: RDF is a good idea whose acceptance is being hampered by a
syntax that many people are empirically observed to dislike on the
grounds that they find it difficult to understand.
Solution: Provide a more understandable syntax.
All I've done is shown that in principle such a syntax is possible. If
the WG chooses to continue to ignore that direction of work, that's
their call. -Tim
|
