4 ms·

It solves the really interesting issue of data integration. When you need to combine and analyze data from various sources having things expressed as triples re

by sktrdie 13y ago

It solves the really interesting issue of data integration. When you need to combine and analyze data from various sources having things expressed as triples really makes a difference. You can merge two datasets that never knew about each other's model with ease. How would you solve data integration issues at a large scale (the web)? The web is full of triples: in webpages (RDFa), in APIs (json-ld), and as large data dumps (freebase n-triples dump). So it does solve a quite realistic issue that is currently driving thousands of different people around the world insane. That is people trying to combine and analyze large quantities of data. If data providers exposed triples instead of their own data model, it would make life easier for everyone. Ps: remember that RDF is not a format but a data model. You can express RDF using json, xml and even csv.

mcot2 13y ago
So that's not really solving any specific problem and it's kind of hand waving to say RDF solves data integration problems for data on the web. Let's break it down a bit. We learned early on that people put information on the web in different ways. Sometimes it's encapsulated within the UI, sometimes people come up with there own formats for things like contact info and comments. So how do we make a system where everyone can understand everyone else's data across the web? Instead of rigidly defined relational models... Where you would need a schema for every type of data... We will attempt to create a universal model consisting of subjects predicates and objects (triples) as the 'schema' for all data. This is essentially RDF. Like most stuff coming from the w3c, they took a pretty good idea and made it needlessly complex with a terrible initial XML syntax and confusing specs. The first implementations were horribly slow for storage and querying. SQL people were laughing at this joke. There is no reason why this entire concept and a simple implementation can't fit on the same sized sheet of paper as the brilliant JSON spec.
acdha 13y ago
> You can merge two datasets that never knew about each other's model with ease. Using triples helps you toss all of that data together but that's like saying CSV helps you combine data from different sources because you can keep appending columns. Once you actually want to reason about or link that data you have to have compatible models or invest the time into translating between them — sometimes that's easy but in many cases it requires intellectual reasoning to map between the way different groups view the world. That's the challenge, not the wrapper.
- 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

mcot2 13y ago

So that's not really solving any specific problem and it's kind of hand waving to say RDF solves data integration problems for data on the web. Let's break it down a bit. We learned early on that people put information on the web in different ways. Sometimes it's encapsulated within the UI, sometimes people come up with there own formats for things like contact info and comments. So how do we make a system where everyone can understand everyone else's data across the web? Instead of rigidly defined relational models... Where you would need a schema for every type of data... We will attempt to create a universal model consisting of subjects predicates and objects (triples) as the 'schema' for all data. This is essentially RDF. Like most stuff coming from the w3c, they took a pretty good idea and made it needlessly complex with a terrible initial XML syntax and confusing specs. The first implementations were horribly slow for storage and querying. SQL people were laughing at this joke. There is no reason why this entire concept and a simple implementation can't fit on the same sized sheet of paper as the brilliant JSON spec.

acdha 13y ago

> You can merge two datasets that never knew about each other's model with ease. Using triples helps you toss all of that data together but that's like saying CSV helps you combine data from different sources because you can keep appending columns. Once you actually want to reason about or link that data you have to have compatible models or invest the time into translating between them — sometimes that's easy but in many cases it requires intellectual reasoning to map between the way different groups view the world. That's the challenge, not the wrapper.

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