6 ms·

As a preamble, when RDF was conceived, databases drove many sites on the web, but their data tended to only be exposed as HTML, instead of a more machine-friend

As a preamble, when RDF was conceived, databases drove many sites on the web, but their data tended to only be exposed as HTML, instead of a more machine-friendly format. Now, there are two perspectives on what RDF is. To an idealist, RDF is the universal data format. There are no semantics baked-in, and you can write arbitrary subject -> predicate -> object triplets to express any possible relationship. To an idealist, it's the perfect format for exposing all the structured data on the web in a machine readable form. The dream has always been for automatic agents to crawl the semantic web for you, understanding the meanings of the RDF triplets, and using them to reason out the solution to your query. To a pragmatist, that dream has always sounded like a bunch of bull. Absent the presence of strong AI, it's a complete pipe dream that a piece of software will ever be able to infer the "semantic meaning" of interlinked RDF, just because it happens to be defined by triples. At the end of the day, you're going to have a programmer writing rules against specific terms in RDF, and if that's the case, than RDF is nothing more than an extremely awkward API. Fortunately for the web, the pragmatists won. APIs are everywhere, and RDF is nowhere. Unless strong AI happens to be right around the corner, the web dodged a real bullet there. 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.

lukev 16y ago
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.
- jashkenas 16y ago
  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?
  - mindcrime 16y ago
    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.
    - jashkenas 16y ago
      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/ http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/ RDF Schema: http://www.w3.org/TR/2004/REC-rdf-schema-20040210/ http://www.w3.org/TR/2004/REC-rdf-schema-20040210/ RDF Semantics: http://www.w3.org/TR/2004/REC-rdf-mt-20040210/ http://www.w3.org/TR/2004/REC-rdf-mt-20040210/ (Those are all current W3C standards)
      - ekidd 16y ago
        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.
po 16y ago
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.
- thomas11 16y ago
  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.
mindcrime 16y ago
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-across-the-web/ http://tripletalk.wordpress.com/2011/01/25/rdfa-deployment-a...
- jashkenas 16y ago
  To continue to play devil's advocate here ... if RDF is just an awkward API, RDFa is just an awkward microformat.
  - mindcrime 16y ago
    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.
  - bergie 16y ago
    More specifically, it is an extensible microformat. Microformats are practically a subset of RDFa with locked-down ontologies (hCard, hCalendar etc).
- cosmohh 16y ago
  #2 there are also more and more RDF datasets (http://www4.wiwiss.fu-berlin.de/lodcloud/ http://www4.wiwiss.fu-berlin.de/lodcloud/) published, so at least some people seem to think it is a good format.
thomas11 16y ago
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.

lukev 16y ago

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.

jashkenas 16y ago
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?
- mindcrime 16y ago
  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.
  - jashkenas 16y ago
    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/ http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/ RDF Schema: http://www.w3.org/TR/2004/REC-rdf-schema-20040210/ http://www.w3.org/TR/2004/REC-rdf-schema-20040210/ RDF Semantics: http://www.w3.org/TR/2004/REC-rdf-mt-20040210/ http://www.w3.org/TR/2004/REC-rdf-mt-20040210/ (Those are all current W3C standards)
    - ekidd 16y ago
      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.

po 16y ago

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.

thomas11 16y ago
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.

mindcrime 16y ago

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-across-the-web/ http://tripletalk.wordpress.com/2011/01/25/rdfa-deployment-a...

jashkenas 16y ago
To continue to play devil's advocate here ... if RDF is just an awkward API, RDFa is just an awkward microformat.
- mindcrime 16y ago
  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.
- bergie 16y ago
  More specifically, it is an extensible microformat. Microformats are practically a subset of RDFa with locked-down ontologies (hCard, hCalendar etc).
cosmohh 16y ago
#2 there are also more and more RDF datasets (http://www4.wiwiss.fu-berlin.de/lodcloud/ http://www4.wiwiss.fu-berlin.de/lodcloud/) published, so at least some people seem to think it is a good format.

thomas11 16y ago

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.