Re: 20 reasons "rdf sucks"

On 18/11/06, Bill de hOra <bill@dehora.net> wrote:
> Steve Harris wrote:
>
> > I have to say I'm not a huge fan of RDF/XML myself, whilst an XML
> > serialisation is important RDF/XML is difficult to write and very hard
> > to generate neatly. It's a pain to parse too.

I don't disagree (nxml-mode helps a *lot*).

> > My experiences of introducing developers to RDF is that they generally
> > take to N3/Turtle or NTriples much more easily. The RDF/XML syntax is a
> > lot to pick up on top of the RDF model.

I'd got used to putting data in XML, so the angle brackets were a
comfort blanket to lose. But now N3/Turtle seems far more natural,
especially with the consonance of SPARQL patterns.

> If there's a Maslow hierarchy of needs for the Web, syntax is on the bottom.

Awesome.

> I agree with Steve, but no surprise there. The main complaint I had (and
> have seen with others) is that because the syntax is variable, you can't
> line up a few RDF stacks and non-RDF stacks and expect things to work
> out. It fundamentally isn't interoperable across marshallers and
> serializers unless you go end to end with RDF/XML aware stacks (eg it's
> very like a WS-* chain).

That's a painful comparison, but I'm afraid rings true. In general it
seems there's a fairly deep-etched line between systems that do/don't
understand RDF.

That ups the deployment stakes hugely, which
> results in an impasse with adopting RDF across administrations -
> everyone needs to go first. Given RDF itself is interoperable, this is
> clearly a nutso situation.

No disagreement.

> And yes, RDF/XML is difficult to write. After 6/7 years, I can write out
>   flat RDF/XML, but I still need the validator to verify I'm striping
> properly.

Right, in there I suspect is the nub - RDF/XML tries to be two
formats: one which follows the flat statement structure, one which
attempts to maximise the match from XML trees to the graph. Neither of
which are exactly brilliant with regular XML tools.

> Surely nobody thinks RDF isn't widely adopted because of RDF?

More than I'm prepared to admit...

Or are you
> guys maintaining a barrier to entry because RDF gives you a competitive
> advantage ;)

If we're to believe the optimism in some quarters, that could well be
a reality :-)

> Turtle on the other hand is a very decent syntax (it reminds me of RNC).
> Something like a JSON format would be even better for developer
> mindshare - " here's some JSON; it happens to be RDF too, but you don't
> have to worry about that right now, just load it. Come back next week
> and we'll talk about the RDF stuff." - is compelling.

When it comes to the large-scale enterprise, I have to defer here to
the folks with direct experience. I can only imagine it is an
expection that a developer will spend significant time ploughing
through a fairly painful stack of specifications, whether it be the
latest .Net libs, EJB material or WS-something. But where there is an
opening for (er, not sure of the best words) low-overhead, more
immediate fulfilment of what is needed, such an approach will have a
significant advantage. I have only minimal direct knowledge of the
startup culture either, but the simple fact that it exists suggests
that 'lightweight', minimal-knowledgebase approaches can work.

So Turtle & JSON, yeah. Offering otherwise perfectly innocent data
that just /coincidentally/ happens to be RDF is a great inroad. Not
sure I've seen it really with JSON yet, but with GRDDL it's there in
the microformat stuff (if only the profile thing was encouraged).
Trojan triples. Bwahaha.

Although it is clunky in many respects. SPARQL seems pretty darn fine
in this regard too. Queries that look like SQL, effectively
serialisation to arbitrary XML (or JSON). Pattern part of the queries
looks like a (Turtle) data representation. Don't need to learn much to
produce results. Works for me. I've seen argued that being simple
makes it near-useless, but I think only somewhere on a semweb list.

Anecdote: day before yesterday I had a hardware problem with my dev
machine in the run-up to a (remote) demo, when there were some bugs
outstanding. By the time I was connected again one of the other guys
on the project (who is a solid Java coder and knows SQL, but has never
dabbled directly in the semweb arts) had fixed a load of the SPARQL.
Manual not needed.

Having said all that, I have absolutely no clue on how such things can
be leveraged to encourage semweb adoption...

Cheers,
Danny.


http://dannyayers.com

Received on Saturday, 18 November 2006 23:14:31 UTC