Companies that don't have pressing revenue issues and a large petty cash allowance use it. A LOT. As a result, most BigCo and BigGovts use a lot of Semantic Web. There are full time employees at these places where all they do, full time, is write pages of documents about applying the Semantic Web to solving a problem. For example, thousands of man hours are spent by the U.S. Military on the Semantic Web every year.

The reality for the rest of us: It does not make financial sense to build the Semantic Web.

It's a chicken and egg problem.

No one has been able to find a way to monetize the Semantic Web when playing the role of the data/ontology provider.

You cant slap on an ad. You hand off the data and someone else renders it and slaps on an ad raking in all the money.

If you are a data provider, it's much more practical going the traditional way: using relational databases and importing/exporting/feeding data using relational formats than turtle/RDF files. The majority of your clients will want your data in that format anyways.

Designing, Building, Maintaining, Querying an Ontology takes a huge amount of expertise/resources.

Even if you had all the money in the world to obtain the data: there currently exist, in single digits, with none of them being open source/free, capable/scalable triple stores that can store an Ontology/Graph that's dense enough to be meaningful while providing any level of practical turnaround time for queries.

Individuals like you and I or small businesses just don't have this expertise/resources.

We would be spending too much time writing our own graph database, carrying out alignments between entities from various datasets, looking at and correct bad data etc before we even get to what we originally set out to do.

Instead, most of us scrape the data from HTML/REST+JSON; use taxonimies at best and custom code to do what we need to get done and call it a day.

12 years ago when I started learning about the Semantic Web, I envisioned we will be, in 2018, using software agents to make our lives simpler:

1. My software bot looks at my calendar to figure out my day's trip and queries the traffic data from the endpoints relevant to my route

2. It also tries to estimate when I will have time to eat and generate a list of nearby restaurants or fastfood locations depending on my available time

3. It would be able to query endpoints from gas stations relevant to my route to figure out whether and if I should fill up gas

4. If portions of my route has toll roads on it, to find out if I already have a pass and remind me to put it in my car
...

A critical component of this happening would be support for federation: la SPARQL Federated Query.

While SPARQL does support Federated Queries, no one has an incentive to support the feature because of the above mentioned monetization challenge.

So is my vision in shambles?

No. I still things done but now through an assorted, custom collection of python scripts, scrapy and PhantomJS (slowly porting over to puppeteer) programs talking to Postgres.

There is not a single line of SPARQL involved in the whole pipeline and it does what I want it to do.

... just like everybody else, we are getting along just fine with our hacky solutions.