3 ms·

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 de

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.
    - lukev 16y ago
      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.
  - mindcrime 16y ago
    You don't have to use all of that stuff though. "Stuff" layers on progressively to add functionality.
lukev 16y ago
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.

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.
  - lukev 16y ago
    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.
- mindcrime 16y ago
  You don't have to use all of that stuff though. "Stuff" layers on progressively to add functionality.

lukev 16y ago

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.