A Review of the Semantic Web Field

You omit the transitive hull that the n-quads standard drags along, as if implementing a deserializer somehow only involved a parser for the most top-level EBNF.

Also, you're still tip-toeing around the wider ecosystem of OWL, SHACL, SPIN, SAIL and friends. The fact that RDF alone even allows for that much discussion is indicative of it's complexity. It's like a discussion about SVG and HTML that never goes beyond SGML.

And you can't have your cake and eat it too. You either HAVE to implement XML-Syntax or you won't be able to load half of the worlds datasets, nor will you even be able to start working with OWL, because they do EVERYTHING with XML.

You're still coming from a user perspective. RDF will go nowhere unless it finds a balance between usability and implementability. Currently I'd argue, it focuses on neither.

JS is a bigger ecosystem than just the browser, if you want to import any real-world dataset (or persistence) you need disk backing. So anything that just goes poof on a power failure doesn't cut it.

Sorry but "works pretty well", and 6 examples combined with an unannotated automatically extracted API, does not reach my bar for "production quality".

It's that "works pretty well" state of the entire RDF ecosystem that I bemoan. It's enough to write a paper about it, it's not enough to trust the future of your company on. Or you know. Your life. Because the ONLY real world example of an OWL ontology ACTUALLY doing anything is ALWAYS Snowmed. Snowmed. Snowmed. Snowmed.

[A joke we always told about theoreticians finding a new lower bound and inference engines winning competitions: "Can snowmed be used to diagnose a patient?" "Well it depends. It might not be able to tell you what you have, but it can tell you that your 'toe bone is connected to the foot bone' 5 million times a second!"]

Imagine making the same argument for SQL, it'd be trivial to just point to a different library/db.

And so far we've only talked about complexity inherent in the technology, and not about the complex and hostile tooling (a.k.a. protege) or even the absolut unmaintainable rats nests that big ontologies devolve to.

Having a couple different competing standards would actually improve things quite a bit, because it would force them to remain simple enough that they can still somehow interoperate.

It's a bit like YAGNI. If you have two simple standards it's trivial to make them compatible by writing a tool that translates one to the other, or even speaks both. If you have one humongous one, it's nigh impossible to have two compatible implementations, because they will diverge in some minute thing. See rich hickeys talk "simplicity matters", for an in-depth explanation on the difference between simple (few parts with potentially high overall complexity through intertwinement and parts taking multiple roles), and decomplected (consisting of independent parts with low overall system complexity).

And regarding JSON Schema: I never advocated for JSON schema and the fact that you have to compare RDFs maturity to something that hasn't been released yet...

You would expect a standard that work began on 25 YEARS ago to be a bit more mature in it's implementations. If it hasn't reached that after all this time, we have to ask the question, why is that? And my guess is that implementors see the standards _and_ their transitive hull and go TL;DR, and even if they try, they get overwhelmed by the sheer amount of stuff.

However, I failed to convince people that we need to implement the 2001 SciAm use case (https://www-sop.inria.fr/acacia/cours/essi2006/Scientific%20..., see the intro before the first section) using 2021 technologies (smartphones are here, assistants are here, shared calendars are easy, companies have APIs, the only thing missing is a proper glue using semantic web tech). This goes to the core thesis of this paper that semantic web is awesome as the set of ideas and approaches but the Semantic Web as the result of all this work may look underwhelming or irrelevant today. I like to point everyone who disagrees with me to the 1994 TimBL presentation at CERN (https://videos.cern.ch/record/2671957) where he talks about the early vision of semantic web (https://imgur.com/aS2dbf6 or around 05:00 in the video), which looks awfully like IoT (many years before the term even existed). We simply cannot fault someone who envisioned communication technologies for IoT in 1994 for getting the technology a bit wrong.

Today's technologies simply cannot handle the use-cases for which SemWeb was designed for properly:

1) The web is still not suitable for machines. Yes, we have IoT devices that use APIs but nobody will say it's truly M2M communication at its best. When APIs go down devices get bricked, there is no way to get those devices to talk to any other APIs. There is no way for two devices in a house to talk to each other unless they were explicitly programmed to do so.

2) We don't have common definitions for the simplest of terms. Schema.org made a progress but it's very limited because it serves search engine interest, not the IoT community. There is no reason something like XML NS or RDF NS should not be used across every microservice in a company. Using a key (we call them predicates, but not important here) "email:mbox" (defined in https://www.w3.org/2000/10/swap/ very long time ago) you can globally denote the value is an email.

3) Correctness of data and endpoint definition still matters. We threw away XML and WSDL but came back to develop JSON Schema and Swagger.

We are trying to get there. JSON Schema, Swagger etc. all make efforts in the direction of the problems SemWeb tried to address. One of the most "semantic" efforts I see done recently is GraphQL federation, which has been a semantic web dream for a long while: being able to get the information you need by querying more than one API. This only indicates the problems that semantic web tried to address are still viable.

If anyone has attempted an OSS reimplementation of the 2001 "Pete and Lucy" semantic web use case (ie as an Android app and a bunch of microservices), please point me in the right direction. Otherwise, if anyone is interested in doing it, I am all ears (https://gitter.im/linkeddata/chat is an active place for the LOD/EKG/SW discussion).

I had to explain that they were basically on track to re-implementing COBOL.

thank you for the really cool post! I am trying to understand some key concepts here, so please forgive the simple questions:

> 16byte subject/entity | 16 byte predicate/attribute | 32 byte object/value

What would be a difference between subject and entity? Do you include a timestamp of your entries next to your trible?

> Having a fixed size binary representation makes this compatible with most existing databases (...)

Are you using a external look up table to identify the human language definition of the entry, and keep using the 2^128 possible entries for internal use?

> (...) if you want to upgrade your schema (...)

> We stole the context from jsonLD (...)

What were the reasons you did not use jsonLD as a base for your software?

Could you point perhaps point me to a case study of your system, or, if this is not possible, a similar case published in literature/www etc? I would love to learn more what you are doing (my contact is in the my profile).

Wish I could upvote you a couple of times. Thank you.

That can mean anything from "we have some conventional (e.g. plain old RDBMS) CWA systems but describe their schemas in an OWA DL to ease integration across independent systems" (in particular this means no CWA implications outside those built into the conventional systems with or without a semweb layer on top) to "we do a big bucket of RDF and run it all through a set of rules formulated in OWL syntax but applied in an entirely different way" (CWA everywhere). The former would be semweb as intended, or at least a subset thereof, but the latter could easily end up somewhere between simple brand abuse and almost comical cargo culting.

Well, at least that's how I feel as someone who never had to face the realities of the vast unmapped territories between plain old database applications and fascinating yet entirely impractical academic mind games of DL (old school symbolic AI ivory tower that suddenly happened to find itself in the center of the hottest w3c spec right before w3c specs kind of stopped being a thing, with WHATWG usurping html and Crockford almost accidentally killing XML)

(also, when has "assumption" turned into "interpretation"? Guess I missed a lot)