[
Lists Home |
Date Index |
Thread Index
]
>
> 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.
>
If people wanted simple and to more easily view the tuples, there was
NTriples all along. You can't get more basic and more simplified than
Ntriples. And most of the tools supported NTriples. I don't seriously think
acceptance of RDF had anything to do with the serialization, as much as
people just didn't know what it was, and didn't know why they would need it.
It was more a matter of evangelizing the spec than creating a simpler
syntax.
No, I think that people had XML and just didn't see a need for RDF.
> > 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.
>
Yeah, but who is to say that his new approach would have been better? We can
work and work and work a spec until we're blue in the face and not find a
perfect solution. People learn to work the situation, or they learn to
automate it -- i.e. autoconf, automake, and libtool.
Tim, we need the WG to finish. We have been waiting over a year for them to
finish. We need something stable that we can work with. We do NOT need to
start all over again. I would pack it in at that point. I really would.
> > 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.
>
Again, I don't think people see this 'need', and that's really what the
problem is.
> > 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.
>
Have to disagree with you on this. You don't just throw everything out, say,
oh so sorry and start again. Not really. If the group formalizes the one
form of RDF/XML, based on considerable comments, testing, and discussion --
then can't we accept that and work alternatives? Or use Ntriples? Or use
XSLT to transform? Or APIs? Isn't that a better approach then to continously
scrap where we are to start all over...again?
> > 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.
>
I think I'm going to have to code one of my models in RDF and one in your
syntax and really look at them side by side. Not all aspects of RDF/XML is
that complicated, though I know that namespace is a real sore point.
What we need is a model and a serialization approach that fits the 80%
simple needs, and isn't all that complex, but also can meet the 20% of
complex needs. I really do believe, sincerely and this is my own opinion,
that RDF/XML is this. Unfortunately, I think that people have seen too much
of the 20% and not enough of the 80% implementations and that's turned them
off. Again, IMHO.
<snip>
>
> 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.
>
And that's cool and let's sit down and write this software and start
delivering the alternative RDF/XML syntax and the transformation tool for
people who want to use RDF in their applications but are put off by RDF/XML.
I'll be honest, I don't care about the human readable/writeable aspects of
RDF/XML as much as I do care that there are tools and APIs that manage it
all for me. Sorry -- but I just don't think that is the most important
aspect of either XML or RDF/XML. Again, IMHO.
> 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.
>
Propaganda? Hmmm. Interesting noun use there.
No, I'm not trying to sell the world on RDF/XML -- look back on this thread
and you'll see this. What I am saying to people is that hate it or love it,
the RDF/XML you see in the specs is what will most likely be released at the
W3C. And I'm glad because the group is already months behind in their
effort, and I want to see the spec finished -- good, bad, or indifferent, I
want the damn thing finished so that I can focus on working with it.
> > 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.
>
An alternative to binary was assembly. An alternative to assembly was
programming languages. What we need to do is has a fixed model, and then
develop usable and useful interfaces to same. I won't provide an alternative
syntax because I find RDF/XML to be readable and writeable. You have
provided an alternative. Okay, let's make sure it works and lets provide the
tools to transform it, as we used to transform assembly to binary.
This is a solution, wouldn't you agree? One that all parties could live
with?
Shelley
|
