Cory Doctorow

A bit of background, I've been working in environments next to, and sometimes with, large scale Semantic Graph projects for much of my career -- I usually try to avoid working near a semantic graph program due to my long histories of poor outcomes with them.

I've seen uncountably large chunks of money put into KM projects that go absolutely nowhere and I've come to understand and appreciate many of the foundational problems the field continues to suffer from. Despite a long period of time, progress in solving these fundamental problems seem hopelessly delayed.

The semantic web as originally proposed (Berners-Lee, Hendler, Lassila) is as dead as last year's roadkill, though there are plenty out there that pretend that's not the case. There's still plenty of groups trying to revive the original idea, or like most things in the KM field, they've simply changed the definition to encompass something else that looks like it might work instead.

The reasons are complex but it basically boils down to: going through all the effort of putting semantic markup with no guarantee of a payoff for yourself was a stupid idea.

You can find all kinds of sub-reasons why this was stupid: monetization, most people are poor semantic modelers, technologies built for semantic system generally suck and are horrible (there's pitifully few reasoners built on any kind of semantic data, turns out that's hard), etc.

For years the Semantic Web was like Nuclear fusion, always just a few years away. The…

I got about halfway down, and it suddenly started sounding like the Semantic Web reincarnated as an API service. This idea crops up about once every 10 years (in some form or another), and it runs into fairly predictable problems. There are two good essays that I recommend that people read before getting too excited about how well machines can interoperate without humans in the loop.

Shirky's "The Semantic Web, Syllogism, and Worldview" http://www.shirky.com/writings/herecomeseverybody/semantic_syllogism.html

Doctorow's "Metacrap: Putting the torch to seven straw-men of the meta-utopia" http://www.well.com/~doctorow/metacrap.htm

Doctorow talks about problems with metadata, but these problems might apply equally to APIs and the API vocabulary discussed in the article. Specifically:

2.1 People lie
2.2 People are lazy
2.3 People are stupid
2.4 Mission: Impossible -- know thyself
2.5 Schemas aren't neutral
2.6 Metrics influence results
2.7 There's more than one way to describe something

The fundamental problems are that (1) getting people to agree on things is a surprisingly difficult and political problem that can never be solved once and for all, and (2) people have incentives to lie. If you invent a generalized way to look up any weather forcasting API, somebody is going to realize that they can make money gaming the system somehow. PayPal is really in the business of fraud detection, and Google is in the business of fighting against blackhat SEO (and click fraud).

So…

Various bits of the lowercase semantic web (and its related uppercase Semantic Web cousin) factors show through on Google results - mostly Google Rich Snippets, so reviews metadata. These mostly require human intervention to enable on a site-by-site basis (sometimes by the site owner, sometimes by humans in Google itself).

The deeper problem of the semantic web is that it's meta data, which tends not to be visible to visitors. And because of that, it's easy to forget / overlook / incomplete, and nefariously allows SEO over-optimisation invisibly that non-whitehat SEOers do in full view of the human audience.

I wish it wasn't true, but Cory Doctorow's portmanteau of metacrap is unfortunately still accurate ( http://www.well.com/~doctorow/metacrap.htm ). We have made several small metadata improvements over the years, but not much progress in substantially overturning Doctorow's original concerns.

Human beings are not great sources of accurate and up-to-date metadata. So we rely on scripts and services to fill in the blanks that we don't. (publish times being recorded in WordPress, for example.)

Converting human content into metadata ends up being an automated human-hands-off affair which means that those automative tools need to be able to parse and extract information / meaning from human prose. Very much what Google has been doing since inception.

It's flawed because it relies on automated interpretation of prose. But there isn't a viable non-flawed method of getting…

As always should look at metacrap (http://www.well.com/~doctorow/metacrap.htm) when discussing the semantic web

- Certain kinds of implicit metadata is awfully useful, in fact. Google exploits metadata about the structure of the World Wide Web: by examining the number of links pointing at a page (and the number of links pointing at each linker), Google can derive statistics about the number of Web-authors who believe that that page is important enough to link to, and hence make extremely reliable guesses about how reputable the information on that page is.

This sort of observational metadata is far more reliable than the stuff that human beings create for the purposes of having their documents found. It cuts through the marketing bullshit, the self-delusion, and the vocabulary collisions.

in short, engineering triumphs over data entry.

I shall copy and paste for your enlightenment

#schemaorg spits in the eyes of every person and company that worked on open vocabularies like vCard, iCalendar, etc

#schemaorg much worse than just a Google+MS duopoly reinvention of open vocabularies, they're actually forking #HTML5.

#schemaorg #HTML5 fork smoke: http://schema.org/EventVenue openingHours extends <time> datetime with durations.

#schemaorg problem not about #HTML5 #microformats #RDFa. It's about open standards communities and subversion thereof.

A link to cory doctorow from 2001:
Metacrap: Putting the torch to seven straw-men of the meta-utopia
http://www.well.com/~doctorow/metacrap.htm#2.1

quite a decent essay from @manusporny that debunks a lot about #schemaorg: http://manu.sporny.org/2011/false-choice/

It seems...redundant? The goal of HTML5 is not to include every conceivable tag in its specification, but to provide a common platform that rendering clients can all agree that "yeah, this describes the content, so render This Semantic Content in This Uniform Way."

If you want a disclaimer, put it in a paragraph tag with the text "disclaimer" enclosed within an emphasis tag. I don't understand how enclosing a disclaimer inside of a special tag makes any difference to a search engine (which is really what "the semantic web" is intended for).

Cory Doctorow's short essay entitled Metacrap (http://www.well.com/~doctorow/metacrap.htm) cuts right to the heart of this idea, as he talks about the problems with semantic markup.