JSON-LD is an Unneeded Spec

Today I learned about a proposed spec called JSON-LD.
The “LD” is for linked data
(Linked Data™ in the Uppercase “S” Semantic Web sense).1

From the JSON-LD site:

Data is messy and disconnected. JSON-LD organizes and connects it, creating a better Web.

Linked Data empowers people that publish and use information on the Web.
It is a way to create a network of standards-based, machine-readable data across Web sites.
It allows an application to start at one piece of Linked Data, and follow embedded links to other pieces of Linked Data that are hosted on different sites across the Web.

JSON-LD is a lightweight Linked Data format. It is easy for humans to read and write.
It is based on the already successful JSON format and provides a way to help JSON data interoperate at Web-scale.
JSON-LD is an ideal data format for programming environments, REST Web services, and unstructured databases such as CouchDB and MongoDB.

Linked data. Web sites. Standards. Machine readable.

Cool. All of those sound good to me.
But they all sound familiar, like we’ve already done this before.
In fact, we have.

Linked data
That’s just the web, right? I mean, we’ve had the <a href> tag since literally the beginning of HTML / The Web. It’s for linking documents. Documents are a representation of data.
Web sites
If it’s not wrapped in HTML and viewable in a browser it, is it really a website? JSON isn’t very useful in the browser by itself. It’s not style-able. It’s not very human-readable. And worst of all, it’s not clickable.2
Standards based
To their credit, JSON-LD did license their website content
Creative Commons CC0 Public Domain.
But, the spec itself isn’t.
It’s using (what seems to be) a W3C boilerplate copyright / license.
Copyright © 2010-2013 W3C® (MIT, ERCIM, Keio, Beihang), All Rights Reserved. W3C liability, trademark and document use rules apply.
Machine readable
Ah… “machine readable”. Every couple of years the current trend of what machine readable data should look like changes (XML/JSON, RSS/Atom, xml-rpc/SOAP, rest/WS-*).
Every time, there are the same promises. This will solve our problems. It won’t change. It’ll be supported forever. Interoperability.
And every time, they break their promises.
Today’s empires, tomorrow’s ashes.3.

Instead of reinventing the everything (over and over again), let’s use what’s already there and what already works.
In the case of linked data on the web, that’s html web pages with clickable links between them.
For open standards, open license are a deal breaker. No license is more open than
Creative Commons CC0 Public Domain
+
OWFa.
(See also the Mozilla wiki about standards/license, for more.)
There’s a growing list of standards that are already using CC0+OWFa.

No process is more open
than a publicly editable wiki. (Mailing lists are toxic.)

Finally, for machine readable data, nothing has been more widely adopted by publishers and consumers than microformats.
As of June 2012, microformats represents about 70% of all of the structured data on the web.
And of that ~70%, the vast majority was h-card and xfn.
(All RDFa is about 25% and microdata is a distant third.)

Maybe it’s because of the ease of publishing microformats.
Maybe it’s the open process for developing the standards.
Maybe it’s because microformats don’t require any additions to HTML.
(Both RDFa and microdata required the use of additional attributes or XML namespaces.)
Whatever the reason, microformats has the most uptake.
So, why do people keep trying to reinvent what microformats is already doing well?

Back to JSON-LD.
The “Simple Example” listed on the homepage is a person object representing John Lennon.
His birthday and wife are also listed on the object.

{
  "@context": "http://json-ld.org/contexts/person.jsonld",
  "@id": "http://dbpedia.org/resource/John_Lennon",
  "name": "John Lennon",
  "born": "1940-10-09",
  "spouse": "http://dbpedia.org/resource/Cynthia_Lennon"
}

I look at this and see what should have been HTML with microformats (h-card and xfn).
This is actually a perfect use case for h-card and xfn:
a person and their relationship to another person.
Here’s how it could’ve been marked up instead.

<div class="h-card">
  <a href="http://dbpedia.org/resource/John_Lennon" class="u-url u-uid p-name">John Lennon</a>
  <time class="dt-bday" datetime="1940-10-09">October 9<sup>th</sup>, 1940</time>
  <a rel="spouse" href="http://dbpedia.org/resource/Cynthia_Lennon">Cynthia Lennon</a>.
</div>

You can throw in a little bit of decoration for improved human readability without comprising machine readability.

<div class="h-card">
  <a href="http://dbpedia.org/resource/John_Lennon" class="u-url u-uid p-name">John Lennon</a>
  was born on
  <time class="dt-bday" datetime="1940-10-09">October 9<sup>th</sup>, 1940</time>
  and was married to
  <a rel="spouse" href="http://dbpedia.org/resource/Cynthia_Lennon">Cynthia Lennon</a>.
</div>

This HTML can be easily understood by machine parsers and humans parsers.
Microformats 2 parsers already exists for:
JavaScript (in the browser),
Node.js,
PHP and
Ruby.
HTML + microformats2 means that machines can read your linked data from your website and so can humans.
It means that you don’t need an “API” that is something other than your website.

Please don’t waste time and energy reinventing all of the wheels.
Instead, please use what already works and what works the webby way.


1:
In its footer, the JSON-LD site mentions that it’s a “Part of the PaySwarm standardization initiative“.
Which in turns claims to be “The Universal Payment Standard”. An awfully big claim.
But, that’s another post for another time.
^

2:
Hell! You can’t even put comments in your JSON.
^

3:

  1. 2005-2009(?): StructuredBlogging
  2. 2005-2011: Google Base schema
  3. 2007-2011(?): Google Data API/Elements
  4. 2009-2009(?): Yahoo et al CommonTag.org
  5. 2009-2011(?): Google rdf.data-vocabulary.org
  6. 2010-present Facebook OGP meta tags
  7. 2011-present Google+MS(Y!) Schema.org
  8. 2012-present Twitter Cards meta tags
  9. 2012-present OpenMetadata.org

(source: tantek.com)
^

Originally published at: http://sbb.me/b4RR1

Wanted: Rails Developer for Activity Stream web app

I’m designing a web based Activity Stream aggregator and I need a Rails developer or two that wants to build it with me. I’m looking for partners not employees.

The idea is simple: Keep up with my friends’ activity on various sites from one web app.

Later I want to publish a unified activity feed for users of the site. On both ends I want to add a little bit of smarts that recognizes when a post is a duplicate (like, say when I post to Twitter and Facebook sucks it in) and show the post once.

I’ve built a static prototype currently at http://razzledazzleit.heroku.com.

This will be a bleeding edge technology site only supporting the latest greatest browsers, assuming that our users are smart or willing to learn and implementing technologies that matter (even if they don’t have the widest adoption yet). Things like:

  • Lots of keyboard shortcuts (j/k to page thru initially)
  • activity streams
  • atom
  • gravatar
  • hatom
  • hcard
  • oauth
  • open id
  • portable contacts
  • xfn

We’re not going to store or ask for any passwords. Ever. If we include a site in our aggregation without asking a user for her password, we won’t include that site. This is will be an app where things are done right. No compromise. No regret.

Out of the gates, I personally care most about:

  • twitter
  • flickr
  • facebook
  • vimeo

Next, I’d like to see

  • youtube
  • fireeagle
  • google latitude
  • foursquare
  • github
  • last.fm
  • delicious
  • pinboard.in
  • rss
  • tumblr

If you’re really into consumption of third party web services, open data, portable identity, aggressively minimalistic code and design, and a web of data (or you want to be), let’s talk. I need a partner or two.

Originally published at: http://sbb.me/b4361