I sent the following message to IMS because I am really unhappy with IMS use of the JSON-LD in our JSON-based specifications. Apologies in advance to the fans of RDF. We all hoped that JSON-LD would give us the best of both worlds – but it seems like it is the worst of all worlds. I don’t expect to win this argument – because the people making the decisions are not the people writing the code and feeling the unneeded pain caused by JSON-LD.

Hi all,

I would like to formally propose that we no longer use JSON-LD in any IMS specification going forward. I would like to also propose that we formally standardize prefixes for all specifications we have issued that use JSON-LD so implementations can legitimately parse our data models using JSON reliably.

Furthermore we would alter certifications for JSON-LD specs to generate and accept JSON instead of JSON-LD.

My reasoning is that we are far outside the norm of the modern-day REST web services world – and while there are fans of JSON-LD – they are the same folks that loved RDF and just found a new place to push their ideas.

Our standards are one domain of interest and our use of JSON-LD actually tends to create silos of data models. If we compare the JSON-LD for LTI 2.0 and the JSON-LD for ContentItem – they are completely distinct namespaces and things like the “contact” structure – which *should be the same* are actually completely different – and our dysfunctional use of JSON-LD *discourages* the sharing of data model elements between different specifications.

And if you take a look at CASA using JSON Schema – it is even worse. Simple things like contact information again are given completely different data models.

And as I am starting to write code that crosses these spec boundaries boundaries, I am finding that it is far less important to have globally unique identifiers for the notion of a contact data structure – but instead a way to have a contact data structure that we can share and reuse across many specifications.

I think that the right approach is to go straight to a namespaced OO approach to model our underlying data objects and then when we build a new spec and want to pull in the org.imsglobal.shared.Contact object – we just pull in the object and then the JSON serialization is obvious.

As we move away from document-styled specs to API-styled specs – it would seem like we just should move towards defining our interoperable data formats in a way that makes the development of APIs very simple and straightforward instead of wasting so much effort to achieve some dream of future RDF nirvana.

I now have samples of how I model these JSON documents across services – and I can tell you that (a) we are woefully inconsistent across our specs and JSON-LD is partially *causing* the problem and (b) anything that has to do with properly parsing JSON-LD is really poor given the lack of real toolset support and (c) it is frustrating the increasing way that the certification suites are making slightly harder by randomly throwing in JSON-LD just to break those who just want to parse JSON – the solution is to reverse engineer the certification patterns and build lame JSON parsers instead of really using JSON-LD tool chains.

It is high time to walk away from JSON-LD going forward.

Looking forward to your comments.

/Chuck

I was recently asked to come up with an outline of how I think about building a MOOC. In particular I have been slowly building a Web Applications MOOC based on www.php-intro.com – starting from my classroom and moving through a MOOC, back to the classroom and then to an innovative on-campus curriculum. This in a sense is my master plan for improving education though MOOCs. They are abstract talking points. Perhaps if you want to hear more, your campus could retain me as a consultant or this might be a good abstract for a keynote or workshop :)

Before the MOOC

Organize/clean your content – understand the topic sequence
Build auto-gradable LTI assignments – test test test
Use residential students as QA – rapid feedback

From the Classroom to the MOOC

Expand time scale – roughly 2x
Eliminate rigor for rigor sake
All assessment is low-stakes and leads to learning
Assessments as puzzles rather than precise measures
Automate automate automate
Recall that LTI tools can be reused outside MOOC platforms
Use CloudFlare to scale static content cheaply
The magic of 5-week classes and 3-week cohorts

From the MOOC to the classroom

Use recordings as assets not lecture replacements
Increase the pace – teach more – make students responsible
Use auto-graded assignments but add manual grading aspects
Do old-school things impossible in a MOOC – like paper exams
Improve MOOC assessments – use F2F students as QA

Impacting other teachers and students broadly

Open Educational Resources – free E-Resources
Low-cost printed textbooks – Amazon CreateSpace
Use CloudFlare to scale static content cheaply
Package materials (including auto-graders) as self-service web site
Get materials on github – allow others to fork and track

Impacting your institution and higher education

Apply the 5-week / 3-week magic on campus for skill-like education
Take advantage of on-campus environment and give better student support