4 ms·

"Our feeling on interacting with the semantic web community is that innovation - especially when it conflicts with core ideology - is not welcome." I wasn't a

by jerf 6y ago

"Our feeling on interacting with the semantic web community is that innovation - especially when it conflicts with core ideology - is not welcome." I wasn't a big fan of the "semantic web" community when it first came out, and the years have only deepened my disrespect, if not outright contempt. The entire argument was "Semantic web will do this and that and the other thing!" "OK, how exactly will it accomplish this?" "It would be really cool if it did! Think about what it would enable!" "OK, fine, but how will this actually work!" "Graph structures! RDF!" "Yes, that's a data format. What about the algorithms? How are you going to solve the core problem, which is that nobody can agree on what ontology to apply to data at global scale, and there isn't even a hint of how to solve this problem?" "So many questions. You must be a bad developer! It would be so cool if this worked, so it'll work!" There has always been this vacuousness in the claims, where they've got a somewhat clear idea of where they want to go, but if you ever try to poke down even one layer deeper into how it's going to be solved, you get either A: insulted B1: claims that it's already solved just go use this solution (even though it is clearly not already solved since the semantic web promises are still promises and not manifested reality) B2: claims it's already solved and the semantic web is already huge (even though the only examples some using this can cite are trivial compared to the grand promises and the "semantic web" components borderline irrelevant, most frequently citing "those google boxes that pop up for sites in search results" just like this article does despite the fact they're wafer-thin compared to the Semantic Web promises and barely use any "Semantic Web" tech at all) or C: a simple reiteration of the top-level promises, almost as if the person making this response simply doesn't fundamentally grasp that the ideals need to manifest in real code and real data to work. This article does nothing to dispel my beliefs about it. The second sentence says it all. For the rest, while just zooming in to the reality may be momentarily impressive, compared to the promises made it is nothing. The whole thing was structured backwards anyhow. I'd analogize the "semantic web" effort to creating a programming language syntax definition, but failing to create the compiler, the runtime, the standard library, or the community. Sure, it's non-trivial forward progress, but it wasn't really the hard part. The real problem for semantic web and their community is the shared ontology; solve that and the rest would mostly fall into place. The problem is... that's an unsolvable problem. Unsurprisingly, a community and tech all centered around an unsolvable problem haven't been that productive. A fun exercise (which I seriously recommend if you think this is solvable, let alone easy) is to just consider how to label a work with its author. Or its primary author and secondary authors... or the author, and the subsequent author of the second edition... or, what exactly is an authored work anyhow? And how exactly do we identify an author... consider two people with identical names/titles, for instance. If we have a "primary author" field, do we always have to declare a primary author? If it's optional, how often can you expect a non-expert bulk adding author information in to get it correct? (How would such a person necessarily even know how to pick the "primary author" out of four alphabetically-ordered citations on a paper?) (I am aware of the fact there are various official solutions to these problems in various domains... the fact that there are various solutions is exactly my point. Even this simple issue is not agreed upon, context-dependent, it's AI-complete to translate between the various schema, and if you speak to an expert using any of them you could get an earful about their deficiencies.)

olliemath 6y ago
Yes. I had pretty much this conversation a while back with some non-technically minded people who had been convinced that by creating an ontology and set of "semantic business rules" - a lot of the writing of actual code could be automated away, leaving the business team to just create rules in a language almost like English and have the machine execute those English-like rules. I had to explain that they were basically on track to re-implementing COBOL.
namedgraph 6y ago
It's not what you have to do, or how, it's that for the first time we have a common model for data interchange (RDF) with which you can model concepts and things in your domain, or more-importantly across domains, and simply merge the datasets. Try that with the relational model or JSON. Integration is the main value proposal of RDF today, nobody sane is trying to build a single global ontology of the world . You can despise the fringe academic research, but how do you explain Knowledge Graph use by FAANG (including powering Alexa and Siri) as well as a number of Fortune 500 companies? Here are the companies looking for SPARQL (RDF query language) developers: http://sparql.club http://sparql.club
- saltcured 6y ago
  Many of us who have been in these battles over the decades have decided that the interchange format is almost irrelevant to the real challenge which is the modeling and semantic alignment. It's a useless parlour trick to merge graphs and call them integrated, approximately as it is to put several CSV files into an archive or simply loading unrelated tables into one RDBMS. Yes, you can run a processing engine on the amalgamation, but all the work remains to do in establishing a federating model within your query or processing instructions. Over and over, we see that the real world problem is gated on human effort to negotiate about the models and to do data cleaning and transformation. And, the best results almost always require that modeling, cleaning, and transformation be done with an eye towards a specific downstream consumer or analysis. We get tired of having to steer leadership back to reality after they buy into the snake oil suggestion that integration costs can be avoided and unknown applications solved. The claim that RDF solves federation more than any other serialization format for structured data and models is about the same as fixating on JSON versus XML or YAML or Lisp s-expressions.

by jerf 6y ago

olliemath 6y ago

Yes. I had pretty much this conversation a while back with some non-technically minded people who had been convinced that by creating an ontology and set of "semantic business rules" - a lot of the writing of actual code could be automated away, leaving the business team to just create rules in a language almost like English and have the machine execute those English-like rules. I had to explain that they were basically on track to re-implementing COBOL.

namedgraph 6y ago

It's not what you have to do, or how, it's that for the first time we have a common model for data interchange (RDF) with which you can model concepts and things in your domain, or more-importantly across domains, and simply merge the datasets. Try that with the relational model or JSON. Integration is the main value proposal of RDF today, nobody sane is trying to build a single global ontology of the world . You can despise the fringe academic research, but how do you explain Knowledge Graph use by FAANG (including powering Alexa and Siri) as well as a number of Fortune 500 companies? Here are the companies looking for SPARQL (RDF query language) developers: http://sparql.club http://sparql.club

saltcured 6y ago
Many of us who have been in these battles over the decades have decided that the interchange format is almost irrelevant to the real challenge which is the modeling and semantic alignment. It's a useless parlour trick to merge graphs and call them integrated, approximately as it is to put several CSV files into an archive or simply loading unrelated tables into one RDBMS. Yes, you can run a processing engine on the amalgamation, but all the work remains to do in establishing a federating model within your query or processing instructions. Over and over, we see that the real world problem is gated on human effort to negotiate about the models and to do data cleaning and transformation. And, the best results almost always require that modeling, cleaning, and transformation be done with an eye towards a specific downstream consumer or analysis. We get tired of having to steer leadership back to reality after they buy into the snake oil suggestion that integration costs can be avoided and unknown applications solved. The claim that RDF solves federation more than any other serialization format for structured data and models is about the same as fixating on JSON versus XML or YAML or Lisp s-expressions.