4 ms·

The difference is in the details. You could combine several CSVs and you could probably come up with a bunch of rules that would make data integration easier. B

by sktrdie 13y ago

The difference is in the details. You could combine several CSVs and you could probably come up with a bunch of rules that would make data integration easier. But then you'd be reinventing exactly the triples model. And it's different than combining different CSVs because you can't specifically combine a CSV that talks about cars and another that talks about houses. You could achieve this if you decide on specific column rules allowing you to probably express various types of data as CSV, but again you'd be reinventing the triples model and you already can express triples within CSV http://jenit.github.io/linked-csv/ http://jenit.github.io/linked-csv/. It's true that RDF doesn't magically solve data interoperability, and obviously requires you do reason upon the data you want to integrate before you can make sense out of it. But the important part is that RDF does actually make the process easier, probably easier than any other model out there.

acdha 13y ago
I'm not saying that namespaces aren't useful but simply that the value of having a standard namespace mechanism in a triple is severely undercut by the complexity of RDF and the poor quality of the tools. Consider: I want to use data from two sources. Do I spend months not working on the hard part of the problem — reconciling the different data models — because I'm learning how to use RDF, configuring, fixing and tuning a bunch of niche tools or do I just pick one of many database options which have much higher performance, are well tested and highly durable, have great documentation and language support, and simply JOIN two tables (classic SQL) or add a namespace in a document (NoSQL or hybrids like Postgres)? Unless you're in one of the few semweb shops, you need to have a HUGE amount of disparate data for that not to be a grossly uneven trade-off, which should not be the case.
- sktrdie 13y ago
  The RDF scene is much more mature nowadays. You could simply get an RDF dataset and start analyzing using a large variety of tools. No need to configure/fix/tune anything. It would be as simple as doing the tables JOIN of your example. I guess if you're more comfortable with that, then perhaps yes, a CSV dataset would be better for you and it would make no difference for your use case. But for me, I could say the same: that with CSV I'd have to learn how to import it into an SQL database and figure out exactly what to JOIN because it's not a graph but a relation db made of tables. So it really depends on what you're used to. But RDF adds more to the table really. Things like URIs for identifying things which could be directly deferenceable (if HTTP URIs). So you know what your columns actually mean and they're not simply a string of letters. And you'd know what it's in your cells and exactly what type of data it's in the cells. These are important features that make data integration a lot simpler imho. But if you're used to CSVs and don't care to make your workflow more efficient with the features RDF offers, then I guess you're better off? Also please check out this interesting answer by Jarven: http://answers.semanticweb.com/questions/19183/advantages-of-rdf-over-relational-databases http://answers.semanticweb.com/questions/19183/advantages-of...

by sktrdie 13y ago

acdha 13y ago

I'm not saying that namespaces aren't useful but simply that the value of having a standard namespace mechanism in a triple is severely undercut by the complexity of RDF and the poor quality of the tools. Consider: I want to use data from two sources. Do I spend months not working on the hard part of the problem — reconciling the different data models — because I'm learning how to use RDF, configuring, fixing and tuning a bunch of niche tools or do I just pick one of many database options which have much higher performance, are well tested and highly durable, have great documentation and language support, and simply JOIN two tables (classic SQL) or add a namespace in a document (NoSQL or hybrids like Postgres)? Unless you're in one of the few semweb shops, you need to have a HUGE amount of disparate data for that not to be a grossly uneven trade-off, which should not be the case.

sktrdie 13y ago
The RDF scene is much more mature nowadays. You could simply get an RDF dataset and start analyzing using a large variety of tools. No need to configure/fix/tune anything. It would be as simple as doing the tables JOIN of your example. I guess if you're more comfortable with that, then perhaps yes, a CSV dataset would be better for you and it would make no difference for your use case. But for me, I could say the same: that with CSV I'd have to learn how to import it into an SQL database and figure out exactly what to JOIN because it's not a graph but a relation db made of tables. So it really depends on what you're used to. But RDF adds more to the table really. Things like URIs for identifying things which could be directly deferenceable (if HTTP URIs). So you know what your columns actually mean and they're not simply a string of letters. And you'd know what it's in your cells and exactly what type of data it's in the cells. These are important features that make data integration a lot simpler imho. But if you're used to CSVs and don't care to make your workflow more efficient with the features RDF offers, then I guess you're better off? Also please check out this interesting answer by Jarven: http://answers.semanticweb.com/questions/19183/advantages-of-rdf-over-relational-databases http://answers.semanticweb.com/questions/19183/advantages-of...