3 ms·

>The problem with the "semantic web" projects is that they are always proposing "pie in the sky" projects I have read this sentiment countless of times, but I

• emmanueloga_ 6y ago
  The first thing you should read is the RDF primer [1]. It explains the basic data model that the semantic web uses as building block for anything else. The gist of it is to provide a way to model data as a graph, and make it almost trivial to exchange data between parties. A simple example is, if you and I want to share, say, user data, and you have a "people" table and I have "Users", and my fields are "first_name" "last_name" and yours "given" and "proper", and so on, how do we match the same user across tables? RDF provides a solution for that. The "pie in the sky" part is that, from this basic building block, a whole host of other technologies can be built, some of them dealing with artificial intelligence, machines being able to _infer_ more information from what you have already said [2]. Inferences can work best when there's more data, that's were the ability to mix your data with third party databases comes handy. Solid adds even more stuff to the table. In their words: derived from "social linked data", is a proposed set of conventions and tools for building decentralized social applications based on Linked Data principles. I think "decentralized" is the keyword here. I haven't even started looking at it :-) 1: https://www.w3.org/TR/rdf11-primer/ https://www.w3.org/TR/rdf11-primer/ 2: https://www.w3.org/standards/semanticweb/inference https://www.w3.org/standards/semanticweb/inference
  • Vinnl 6y ago
    > A simple example is, if you and I want to share, say, user data, and you have a "people" table and I have "Users", and my fields are "first_name" "last_name" and yours "given" and "proper", and so on, how do we match the same user across tables? RDF provides a solution for that. What solution does RDF provide for that? I know of `owl:sameAs`, but even if it were feasible to look up those statements and reason about them (assuming someone reliable went to the effort to actually define them, and did so correctly), that already breaks down if I have to match a single field "name" (or, say, vcard:fn) with two fields "first name" and "last name" (or, say, foaf:givenName and foaf:surName). So as far as I know, there's still no practical solution - or is there?
    • emmanueloga_ 6y ago
      Not an expert on OWL but I heard owl:sameAs is supposed to be a strong equivalence assertion (commutative) and perhaps not necessarily the tool you want to use for integration To be able to say that two subgraphs describe the same thing, at some point, a mapping is needed between the different sub graphs (for users could be, say, a common schema:email statement). A good practice is to use some existing ontology when modeling (say, FOAF or schema.org), this can fix the problem of having to map fields since both sources would already be using the same conventions. I think what's normally done is some sort of normalization pass or passes after ingesting the triples, so at the end of the process your app can always use your preferred property (say vcard:fn) or just ignore the subgraph in the worst case. There are a number of tools to perform this kind of normalization.. I know of SPARQL construct queries but I've seen others out there (rml.io).
      • Vinnl 6y ago
        Right, but is that feasible in practice? Do people actually successfully do that, on a large scale? Or does it run into: - Having to create your own mapping for every piece of data of every divergent data source, with a not-insignificant amount of work involved? - Those mappings inevitably containing mistakes/different interpretations that result in invalid data? - Some of the data not being amenable to lossless mapping in the first place? In other words: is "RDF provides a solution for that" not overselling it a bit?
        • emmanueloga_ 6y ago
          If you are asking if RDF provides a silver bullet to integrate data sources, the answer is no, everything requires effort. But I think the integration story is way better than when integrating other data models, say, relational databases. The other aspect is that URLs being the ids for statements, I can peek at the implementation of a 3rd party data model and use that _in advance_, instead of integrating later. For instance, when I write my blog I can use the URLs of existing wikidata entities to model my own entities. If wikipedia entities used a relational model, the IDs of these entities would be opaque and could change at any time, so I wouldn't be able to do that.