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:
(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.
Comments
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.