Hacker News Reader

Not quite. While RDF certainly isn't all that the idealists claim, you can still get some benefit of it without strong AI.

Mainly, it provides a consistent model for handling the notion of a "field". Non-RDF apis typically return fielded JSON or XML, the structure of which is only specified within the documentation. In order to integrate two services not originally designed to inter-operate, you have to write lots of custom glue code.

RDF is at least amenable to writing generic "rules" to govern field mapping and inference, rather than one-off glue code (which usually ends up being a hacky script). So sure, if you're integrating one service, a hacky script is probably easier. But if you want a coherent system for integrating large numbers of services not originally designed to inter-operate, RDF makes things a lot easier.

So there's some benefit, even if it isn't as dramatic as its proponents claim.

Plus, there's the fact that while strong AI isn't yet on the horizon, RDF is a lot easier for weak AI (inference engines, data mining, etc) to ingest, and weak AI is getting better all the time.

Actually, one of the biggest problems with RDF, to my mind, is that it's structure makes it very difficult to get good performance with truly large numbers of subjects and attributes - and unfortunately that's just the area where it'd be most useful.

My claim is that your "generic rules" to govern mapping fields are actually equivalent to hardcoding the names of JSON fields. Instead of seeing "title", and deciding what to do with the data, you see:

    <!DOCTYPE rdf:RDF PUBLIC "-//DUBLIN CORE//DCMES DTD 2002/07/31//EN"
      "http://dublincore.org/documents/2002/07/31/dcmes-xml/dcmes-xml-dtd.dtd">

    <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
      xmlns:dc="http://purl.org/dc/elements/1.1/">

    <dc:title>

... and decide what to do with the data.

In both cases, instead of having a machine understand the (semantic) structure of the data, you have a programmer writing a rule.

Can you provide a concrete example of where this isn't the case, and your RDF-reader is simpler than reading the equivalent (well-designed) JSON of the same data?

It's not just consuming the data though... it's when you go beyond that and start doing inference and combining multiple databases, that the RDF approach really shows it's value.

If you established a standard for doing that kind of field name exposure, using JSON, and then sure, you could achieve the same effect. But, in the end, you'd probably just wind up with a JSON encoding of RDF anyway. Define things as subject/predicate/object is all RDF really is... the RDF/XML encoding is just one way of expressing RDF.

Hey, I really wish that "subject/predicate/object" was all that RDF was, but I'm afraid it's a good deal more:

RDF Syntax: http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/

RDF Schema: http://www.w3.org/TR/2004/REC-rdf-schema-20040210/

RDF Semantics: http://www.w3.org/TR/2004/REC-rdf-mt-20040210/

(Those are all current W3C standards)

I agree that a lot of the standards surrounding RDF are ugly. I've always particularly disliked the RDF-as-XML serialization, which took two fairly simple ideas (triples and XML) and combined them into a complex mess. This is why I always hate parsing RSS 1.0. Also, the full generality of OWL just confuses me: It seems to be Prolog done badly.

But just as with XML, it's possible to ignore the cruft (XQuery, XLink, XML Schema, the current SOAP flavor-of-the-month), and just use the useful bits. A similar argument could be made about HTML: For every HTML 5, there's an XHTML 2.0.

Agreed. You can get all the benefits of RDF while eschewing the stupid parts. Just because something has a spec doesn't mean you have to use it.

The full XML spec, for example, is insanely complicated. But people still derive value from it by utilizing a more or less sane subset.

You don't have to use all of that stuff though. "Stuff" layers on progressively to add functionality.

It seems like the missing piece for you is that RDF is one level of abstraction higher than what you're talking about.

If you're just thinking about parsing data out of the above XML snippet, yeah, of course it's more complicated. But the point of RDF is that you don't think about the serialization format (there's libraries for that). You should be thinking about your data at a higher level of abstraction, at the level of "triples" and "inference rules".

You're expected to use a triples database and an inference engine of some kind, either a library or by rolling your own. If you're not, then I agree, you're not deriving any benefit from RDF. But if you are, then it lets you deal with your data in a more abstract, generalized way that does provide legitimate value for certain use cases.

So sure, if you're integrating one service, a hacky script is probably easier. But if you want a coherent system for integrating large numbers of services not originally designed to inter-operate, RDF makes things a lot easier.

Exactly. If one thinks of RDF (and associated technologies) as having an aim of creating a Semantic Web as one big, decentralized, federated database, then you can really see the value in it.

For any one random website to expose some data for people to use, it's a fair argument that RDF is more awkward than just dumping the data out over an HTTP API as generic XML, JSON, CSV or whatever. But when you look at the bigger picture, RDF becomes desirable.

Ah, but RDF in and of itself isn't any more interoperable than XML or JSON. You still have to agree on the vocabulary of your triples. To that end, you bring in RDF Schema, OWL, and their stacks of definitions:

http://www.w3.org/2002/07/owl

(View source on that page). Absent strong AI, defining your terms in terms of URIs to terms, defined by URIs to terms ... ad infinitum, is no more expressive or powerful than simply saying that a "title" is a "title".

Ah, but RDF in and of itself isn't any more interoperable than XML or JSON.

True, but XML and JSON are both fantastically useful technologies despite that lack of interoperability.

So when is RDF actually useful? If I have hierarchical data structures, I strongly prefer JSON. If I have structured documents, I like XML. But if I have a graph, something like RDF n-triples or Turtle is a reasonable way to serialize it.

Let's also not forget the Linked Data idea. You find a node in an RDF graph that you're interested in? Follow the URI that is its id and get more RDF describing the node, and so on. A web of data. We're not there yet, but the number of RDF-ized resources is growing.

Sure, everything you can do using RDF you could conceivably do using a different suite of technologies... but my point - if there is a broad point to make here - is that you'd wind up recreating a lot of the "stuff" that is part of the RDF ecosystem anyway, to achieve the same end.

Now maybe it's possible that someone could start from scratch and build up a system that is both much simpler does the same things... if so, fine, point me to it when it becomes available.

I've also experienced performance issues with RDF stores, but over the last few years, that has increased a lot and I think in another 1-2 years there will be a bunch of stores that are able to handle reasonable large numbers of triples with a good performance.

Aside from that I think, although RDF might not be the 'holy grail', it is in fact quite usable for a lot of problem domains and saying that it needs to be discarded is a bit harsh :)

You can also publish RDF via JSON: http://json-ld.org/

btw, that is also an issue which is addressed by the newly revived RDF working group - http://www.w3.org/2001/sw/wiki/index.php?title=RDF_Core_Work...

RDF is certainly awkward for many use cases, but it's the same API everywhere. Each custom web API needs custom code to use it.

I don't believe in automatic agents, either. But RDF as a universal data format, forming a web of data, can be useful even without agents. It allows linking, combining, loading and querying data from different sources without writing any code at all.

We're not at a point yet where this is often possible due to the lack of (good) RDF data, but the idea is strong. I work on uniprot.org, providing one of the largest free RDF data sets, and we see strong interest from our users---bioinformaticians who often spend most of their time writing import/export scripts instead of doing their actual work.

APIs are everywhere, and RDF is nowhere.

RDF is hardly ubiquitous, but it's also hardly appropriate to say that it's nowhere. RDFa in particular has seen a big surge in adoption over the last year or two, especially after Google and Yahoo announced that they would start utilizing RDFa.

http://tripletalk.wordpress.com/2011/01/25/rdfa-deployment-a...

To continue to play devil's advocate here ... if RDF is just an awkward API, RDFa is just an awkward microformat.

More specifically, it is an extensible microformat. Microformats are practically a subset of RDFa with locked-down ontologies (hCard, hCalendar etc).

In theory they are semantically equivalent (usually anyway) so the question is, is RDFa particularly awkward. I guess it depends on how you define awkward.

#2

there are also more and more RDF datasets (http://www4.wiwiss.fu-berlin.de/lodcloud/) published, so at least some people seem to think it is a good format.

Personally, I'm of the opinion that any web agent that could possibly puzzle through RDF triplets should have no problem understanding our APIs, in any case.

…or native human language.

You're saying that a standardized formal model of a graph is equally hard to understand for programs than human language? The people working on natural language processing since decades must be really dumb then.