Hydra For Semantic Web APIs

+Markus Lanthaler does a great job of first pointing out the problems with current web APIs, and then explaining how JSON-LD (using vocabularies like Schema.org and Hydra) can solve this problem.
I guess if you're not a developer, this may be quite hard to understand. But I'm here to help :)

Believe me, less than 15 months ago, I would not have even dreamed of clicking on this video, talk less of watching it to the end.
But what amazes me is that I actually understand it.
Well, most of it. :)
And I think you can too......if only you can open up to it, and open up to the Semantic Web in general. 

Being a natural social scientist, who once hated math and computer science with all my heart, it is incredible that I no longer find these things cryptic and terribly boring. So much so that I feel a strange responsibility to explain these things to marketers, business people and.....well.....anyone who likes opportunities for the future. 

https://www.youtube.com/watch?v=91wSt3fHWLE&index=6&list=PLnrk9ITBDMcXKfrf1O7T7-FWSTQlyUJ1U


#SemanticWeb   #Hydra   #JSONLD  

A JSON-LD love letter

When I saw this summary box (bottom left) at the bottom of a recent +Bill Slawski post (http://bit.ly/1tBZ9VS) I was reminded immediately of a similar box found at the bottom of posts by +Mike Bergman on AI3 (http://bit.ly/1vR2HSP).

"A-ha!" says I, "must be a schema.org container!"  And 'tis so.

While I titled this "a JSON-LD love letter" it's really more of a plea to the search engines to figure out a way of formally accommodating - that is, officially giving the thumbs-up to - JSON-LD.

It's a nice testament to the utility of schema.org that people like Bill and Mike are going out their way to feed the beast(s) with structured data - and ironic that they're now forced to go through such contortions to do so in a way the search engines will respect when an absolutely perfect mechanism exists for the expression of linked data without requiring all these gymnastics.  Because ... inline markup.

Ironic too that the far less expressive Open Graph protocol is so much easier to employ (and so has phenomenal adoption) because its free of the inline markup requirement the search engines have bestowed on schema.org.

For most types.  But on websites, not for email.  Or Islands.  Or app indexing.

I don't know about the rest of you, but I'm rapidly facing a conundrum as a result of this the inline markup requirement.  As per the prior post on the analytics work being done by +Mike Arnesen I'm ready to start adding even more structured data to my web pages for reasons other than search engine benefits, and the easiest way for me to do this is with JSON-LD.  But if declare a heap o' data with JSON-LD, do I repeat select declarations inline with microdata or RDFa for on-page elements?  Or will that be seen as spammily doubling up on the entities I'm expressing?  Or will Google et al. only parse the inline markup, leaving me free to do what I want to with JSON-LD?

I know the day will come, but it just ain't comin' soon enough for this marketer!

#jsonld   #schemaorg  

When we publicly launched Freebase back in 2007, we thought of it as a "Wikipedia for structured data." So it shouldn't be surprising that we've been closely watching the Wikimedia Foundation's project Wikidata[1] since it launched about two years ago. We believe strongly in a robust community-driven effort to collect and curate structured knowledge about the world, but we now think we can serve that goal best by supporting Wikidata -- they’re growing fast, have an active community, and are better-suited to lead an open collaborative knowledge base.

So we've decided to help transfer the data in Freebase to Wikidata, and in mid-2015 we’ll wind down the Freebase service as a standalone project. Freebase has also supported developer access to the data, so before we retire it, we’ll launch a new API for entity search powered by Google's Knowledge Graph.

Loading Freebase into Wikidata as-is wouldn't meet the Wikidata community's guidelines for citation and sourcing of facts -- while a significant portion of the facts in Freebase came from Wikipedia itself, those facts were attributed to Wikipedia and not the actual original non-Wikipedia sources. So we’ll be launching a tool for Wikidata community members to match Freebase assertions to potential citations from either Google Search or our Knowledge Vault[2], so these individual facts can then be properly loaded to Wikidata. 

We believe this is the best first step we can take toward becoming a constructive participant in the Wikidata community, but we’ll look to continually evolve our role to support the goal of a comprehensive open database of common knowledge that anyone can use.

Here are the important dates to know:

Before the end of March 2015
- We’ll launch a Wikidata import review tool
- We’ll announce a transition plan for the Freebase Search API & Suggest Widget to a Knowledge Graph-based solution

March 31, 2015
- Freebase as a service will become read-only
- The website will no longer accept edits 
- We’ll retire the MQL write API

June 30, 2015
- We’ll retire the Freebase website and APIs[3]
- The last Freebase data dump will remain available, but developers should check out the Wikidata dump[4]

The Knowledge Graph team at Google

[1] http://wikidata.org
[2] http://www.cs.cmu.edu/~nlao/publication/2014.kdd.pdf
[3] https://developers.google.com/freebase/v1/
[4] http://dumps.wikimedia.org/wikidatawiki/