Hands up anyone who uses RDF (when they could choose to do otherwise)? Anyone? Bueller?
Why is RDF so old, complicated, unpopular and still not discarded?
11–20 of 45 posts
Re: Why is RDF so old, complicated, unpopular and still not discarded?
#12Earlier quoted context omitted.
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.
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.
Re: Why is RDF so old, complicated, unpopular and still not discarded?
#13Earlier quoted context omitted.
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…
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: ... 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 thi…
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.
Re: Why is RDF so old, complicated, unpopular and still not discarded?
#14Earlier quoted context omitted.
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…
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.…
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".
Re: Why is RDF so old, complicated, unpopular and still not discarded?
#15Hands up anyone who uses RDF (when they could choose to do otherwise)? Anyone? Bueller?
I'm working on some stuff that uses RDF, yeah.
Re: Why is RDF so old, complicated, unpopular and still not discarded?
#16Earlier quoted context omitted.
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: ... 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 thi…
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…
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)
Re: Why is RDF so old, complicated, unpopular and still not discarded?
#17It was the right idea and almost the right implementation, but almost is a big word -- like a rocket that almost has escape velocity.
There's work being done in this space that is really exciting and I think we'll soon see how much potential the semantic web really has.
Re: Why is RDF so old, complicated, unpopular and still not discarded?
#18Hands up anyone who uses RDF (when they could choose to do otherwise)? Anyone? Bueller?
I'm working on some stuff that uses RDF, yeah.
Since you're quite an eloquent defender of RDF in this thread -- would you mind sharing a bit of RDF from your project? If it's not public or finished yet ... perhaps pasting an excerpt on gist.github.com?
Re: Why is RDF so old, complicated, unpopular and still not discarded?
#19[I have a client who sells RDF tools. Here's the latest version of what I've been saying to them.]
Let's look at RDF like a startup: The old RDF marketing from, say, 2003 was hopelessly out-of-touch with reality. Users were never going publish their metadata as RDF, and even if they did, you'd need strong AI to use it. Here are two classic articles spelling out why classic RDF wouldn't work:
http://www.well.com/~doctorow/metacrap.htm http://www.shirky.com/writings/semantic_syllogism.html
But things have been looking up in the RDF market lately. The complicated RDF XML serialization is mostly ignored in favor of simple n-triples. Google is making heavy use of RDFa metadata when searching for products, and something like 3.5% of web pages now contain RDFa. The RDF conferences are booming. There are cool projects like dbpedia that are organizing publicly-available information as RDF.
So if the RDF tool vendors are going to succeed, they need to pivot (and many of them are). They need to drop the AI hype, and focus on what their early users are telling them. Some possible sales pitches:
1) RDF is useful as a distributed, schema-free graph database. Competition: Neo4J, other NoSQL databases. There's a couple of very good sales pitches here, including the fact that RDF databases are available from multiple vendors, and that RDF inference can be used to normalize schemas between different data sources.
2) RDF is useful for embedding small amounts of data in web pages. Competition: Microformats.
Re: Why is RDF so old, complicated, unpopular and still not discarded?
#20Hands up anyone who uses RDF (when they could choose to do otherwise)? Anyone? Bueller?
Plenty of people (including myself) in biomedical fields (especially in bioinformatics, although I know of numerous medically-oriented users) use RDF for a variety of purposes- it's a fabulously flexible way to express and encode complex data models. With a little bit of coordination regarding semantics (OWL, etc.), it's also a great way for people in related but distinct fields to share their data with one another.
That said, RDF has historically had three main problems, IMHO. The first is that its proponents have, historically speaking, done a crappy job of explaining what it actually is, and a worse job of demonstrating what it can do.
The second problem is that it's not really the most human-readable format around, especially in its XML serialization format. This is largely because it wasn't designed for human-readability, but in the age of the Web (where human-readable formats have shown to have major advantages over non-human-readable ones), this is a liability. They've added some more readable serialization formats over the years, but a lot of the documentation and tutorials assume that you'll be working in XML.
When I first tried to learn about RDF, years ago, all I found were tutorials full of really gnarly-looking XML with minimal explanation of what was going on. I spent so much time getting bogged down by the syntax that I missed the point entirely.
The third, and bigger, problem with RDF, is that it's a little hard to "grok" if you don't have a good grounding in predicate logic, description logics, and some of its other theoretical underpinnings. Actually, wait, maybe I said that wrong- I should say instead that most of the old-school RDF people do have solid theoretical backgrounds in description and predicate logic, and have a hard time talking about RDF and other semweb technologies with people who people who don't have that background. So they use lots of jargon that, while useful, isn't very helpful to somebody just trying to get their feet wet.