Earlier 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…
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.