4 ms·
The problem with the "semantic web" projects is that they are always proposing "pie in the sky" projects that require a big leap of faith to get invested on. I
by emmanueloga_ 6y ago
The problem with the "semantic web" projects is that they are always proposing "pie in the sky" projects that require a big leap of faith to get invested on. I see solidproject.org as an example of this.
I've been exploring semantic technologies from the cold and incredible practical angle of "my own needs" :-). The RDF model offers a lot even when keeping data for myself: I can use RDF to infer new things from existing data and visualize relationships. An RDF triplestore can be used to store pretty much anything, and works well for CRUD. RDF is about graphs, so a triple store can be used to model documents too, since trees are a subset of all graphs.
RDF4J has really nice documentation and supports a lot of modern features. The getting started guide is great [1], and there's also a super friendly gitter room to ask questions [2].
1: https://rdf4j.org/documentation/tutorials/getting-started/ https://rdf4j.org/documentation/tutorials/getting-started/
2: https://gitter.im/eclipse/rdf4j https://gitter.im/eclipse/rdf4j
- darkhorse13 6y ago>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 don't quite understand it. Maybe because I am not familiar with the semantic web. Can you please suggest some reading list for a person who is unfamiliar with semantic web to better understand these issues?
- emmanueloga_ 6y agoThe 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 agoNot 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 agoRight, 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?