JSON LD vs RDF/JSON (Alternative serialization)

I’d like to say that I am rarely opinionated about technology but that would be a barefaced lie. It is true, however, that I am rarely so opinionated that I motivate myself to write about it. This, unfortunately, is one of those occasions.

On January the 16th the JSON-LD specification became a W3C recommendation. There was an “Alternative Serialization” of RDF into JSON, referred to as RDF/JSON. This format is not to become a recommendation:

The RDF Working Group has decided not to push this document through the W3C Recommendation Track. [from http://www.w3.org/TR/rdf-json/]

I think that decision was a mistake; particularly from the perspective of an RDF user. I have no real right to complain as I was not involved with the working group or a member of the mailing list; I can whine now, though.

Differences

In a nutshell:

RDF/JSON (the Alternative Syntax) is very simple. It maps obviously to Notation 3 and the RDF core concept.

JSON-LD is not specific to RDF and it has lots of features to make it more readable to a human, which makes it more verbose.

Using the syntaxes

I am making an assumption that, in choosing JSON as a format, the user of one of the two syntaxes would likely be a JavaScript developer. So, I put together a minimal example of processing RDF written in both syntaxes. In both cases I have mapped the following Turtle into JSON in the tersest way I could – specifically, I did not use the JSON-LD “@context” attribute, in order to give JSON-LD the fairest chance. Then, for each JSON object I wrote a simple JavaScript program to convert the RDF back into Turtle. Here are the two programs for comparison:

Using the “Alternative Syntax”:

``````function printLiteralTriple(subject, predicate, value, language) {
document.write("&amp;lt;" + subject + "&amp;gt; &amp;lt;" + predicate + "&amp;gt; "" + value + ""@" + language + " .");
document.write("&lt;br/&gt;");
}

var jsonAlt = {
"http://purl.org/dc/terms/title" : [ { "value" : "Anna's Homepage",
"type" : "literal",
"lang" : "en" } ]
}
}

for (var subject in jsonAlt) {
for (var predicate in jsonAlt[subject]) {
for (var objectIndex in jsonAlt[subject][predicate]) {
var object = jsonAlt[subject][predicate][objectIndex];
printLiteralTriple(subject, predicate, object.value, object.lang);
}
}
}``````

See the Pen zoFHC by chrismichaelscott (@chrismichaelscott) on CodePen.

Note that the iteration is east to understand as the keys hold useful content – a common construct in JavaScript – and are homogeneous (i.e. the top level keys are always subjects).

Using JSON-LD:

``````function printLiteralTriple(subject, predicate, value, language) {
document.write("&amp;lt;" + subject + "&amp;gt; &amp;lt;" + predicate + "&amp;gt; "" + value + ""@" + language + " .");
document.write("&lt;br/&gt;");
}

var jsonLD = {
"http://purl.org/dc/terms/title": {
"@value": "Anna's Homepage",
"@type": "literal",
"@language" : "en"
}
}

for (var key in jsonLD) {
var subject;

if (key == "@id") {
subject = jsonLD[key];
} else { // NOTE: there are other cases to check for here, such as @context
var predicate = key;
var object = jsonLD[key];

if (object instanceof Array) {
for (var objectIndex in object) {
printLiteralTriple(subject, predicate, object[objectIndex]["@value"], object[objectIndex]["@language"]);
}
} else {
printLiteralTriple(subject, predicate, object["@value"], object["@language"]);
}
}
}``````

See the Pen JaeIG by chrismichaelscott (@chrismichaelscott) on CodePen.

Because the keys in JSON-LD are not homogeneous (i.e. they may be keywords, like “@id”, or they may be predicates) the developer cannot simply iterate over the object.

A fully featured JSON-LD document may be more complex than the example above. One can use the “@context” key to provide typing information and prefixes (as they would be in Turtle). That feature can arguably make the document easier for a human to read but is that really the objective? Look what happens to the JavaScript parser when we include a “@context” – and consider that this is a minimal parser that doesn’t support any case other than a literal valued triple.

``````var jsonLD = {
"@context": {
"title": {
"@id": "http://purl.org/dc/terms/title",
"@type": "@value",
"@language": "en"
}
},
"title": "Anna's Homepage"
}

function printLiteralTriple(subject, predicate, value, language) {
document.write("&amp;lt;" + subject + "&amp;gt; &amp;lt;" + predicate + "&amp;gt; "" + value + ""@" + language + " .");
document.write("&lt;br/&gt;");
}

var contexts = {};

// first resolve contexts
for (var key in jsonLD) {
if (key == "@context") {
if (jsonLD["@context"] instanceof Array) {
for (var contextIndex in jsonLD["@context"]) {
for (var context in jsonLD["@context"][contextIndex]) {
contexts[context] = jsonLD["@context"][contextIndex][context];
}
}
} else {
for (var context in jsonLD["@context"]) {
contexts[context] = jsonLD["@context"][context];
}
}
}
}

for (var key in jsonLD) {
var subject;

if (key == "@id") {
subject = jsonLD[key];
} else if (key != "@context") {
var predicate = key;
var object = jsonLD[key];
var objectLanguage;

if (typeof(contexts[predicate]) !== "undefined") {
if (typeof(contexts[predicate]["@language"]) !== "undefined") {
objectLanguage = contexts[predicate]["@language"];
}
predicate = contexts[predicate]["@id"];
}

if (object instanceof Array) {
for (var objectIndex in object) {
var objectValue;
if (typeof(object[objectIndex]) == "string") {
objectValue = object[objectIndex];
} else {
if (typeof(objectLanguage) == "undefined") {
objectLanguage = object[objectIndex]["@language"];
}
objectValue = object[objectIndex]["@value"];
}
printLiteralTriple(subject, predicate, objectValue, objectLanguage);
}
} else {
var objectValue;
if (typeof(object) == "string") {
objectValue = object;
} else {
if (typeof(objectLanguage) == "undefined") {
objectLanguage = object["@language"];
}
objectValue = object["@value"];
}
printLiteralTriple(subject, predicate, objectValue, objectLanguage);
}
}
}``````

See the Pen jiarn by chrismichaelscott (@chrismichaelscott) on CodePen.

Not great, is it? I really hope the working group reconsider. For human readable RDF use Turtle: it’s great at that. For RDF to be consumed by object oriented languages, use RDF/JSON, the “Alternative Serialization”. :(

3D Rendering to SVG

I was on holiday last week, in the Sierra Nevada mountains in Andalusia, Spain. Some people like to read books on holiday, I undertake projects. So, as I was sitting by the pool, I developed a 3D rendering engine in Javascript. Each to their own, hey?

I’d been thinking about this for a little while. A rendering engine was an enticing project and I anticipated some interesting complexities. I had decided that I would use SVG as the medium. As with 2D drawings, HTML5 Canvas seems to get all the attention for 3D drawings (WebGL) but, in both cases, there are pros and cons of each technology. Notable reasons for choosing SVG may be:

• As SVG is vector based it will be very fast for simple drawings that are animated (as, from a Javascript point of view, you only need move points, not redraw the canvas)
• If you need to interact with the components, SVG elements natively support mouse events (like `mouseover`)

So, first off, here’s the result. I’ll explain how it works afterwards.

Use cases

As mentioned above, there are a number of good reasons to use a vector drawing. A use case which immediately springs to mind is architectural drawings. The drawings need not be vastly complex, certainly in terms of fairly regular shapes and textures. Also, a developer could add interactive elements to an application so that hovering over a wall or joist would show you the materials, etc. That would be much more difficult with WebGL or similar as the hover events aren’t there to help.

How it works

The maths behind the engine is fairly simple but quite fun. First, a camera is created, which consists of a point in space and a rectangular plane at some point in front of it. The plane is, in effect, the lens of the camera and I refer to the point as the origin. Then, to plot a point the following algorithm is ran:

1. A vector is constructed from the point being plotted to the camera’s origin
2. The point that the vector intercepts the lens is calculated
3. The intercept point is converted into a 2D co-ordinate, relative to the lens
4. That co-ordinate is scaled up to the screen and a point is plotted there

So, to draw a plane one merely needs to convert four points in space to be four co-ordinates on screen, then an SVG path can be used to join the dots.

A bit more detail

The interesting part of this project is projecting the point to be plotted onto the lens. I had an idea of how this would work: I wanted to exploit the fact that the dot-product of two vectors at a right angle is always 0. Moreover, a decrease in the dot product implies that the angle is closer to a right angle.

So, take any two points on the lens, La and Lb, which could be corners and a second vector, v, from the camera origin to the point being plotted; then, there exists some λ which minimizes α:

$\left(\mathbf{L{}_{}},-,\mathbf{L{}_{}}\right)\cdot \left(\mathbf{L{}_{}},-,\mathrm{\lambda \mathbf{v}}\right)=\alpha$

Pictorially, that is:

Therefore, λ minimizes α as λ v approaches the intersect between v and the lens plane. To find the value of λ I simply implemented a “split the difference” algorithm. That is, try λ equal to 0.5; is that better than λ equal to 1? Then try 0.25 and 0.75, which is best? Ect, ect.

Once you have the vector λ v it is quite easy to map the point onto the screen using a bit of trig’ and some vector maths. Then you’re there. If you want more details, best check out the code on my Github page.

The future of the project

This was never meant to be a production library, just a proof of concept. I think that a robust SVG-based rendering engine could have a number of sound use cases but it would take a lot more time than I have available to get to the point where this could be used in production. A number of challenges, just off the top of my head, include:

• textures – difficult to transform in 3D if you’re using SVG
• lighting – this could be implemented using dot products between the normal of the plane and a vector from the plane’s centre to a point of light
• z-index of polygons – i.e. if the example above were opaque, the closest planes should be visible above the farthest ones.

I’d love to know what other people think and if there is any work in this direction already…

Filter Effects for Raphael

I’ve been working lately on an extension to Raphael.js which lets you quickly add Filter Effects – something which I’ve wanted to see in Raphael for a long time. I’m not going to do a big write up just yet but here’s an example of what’s on offer:

You can find out about the project on it’s homepage.

Understanding the prototype property in a Javascript object

The prototypal nature of Javascript is both a common cause of confusion and a well documented topic. I’m not going to look at the basic theory here because it’s been done many times; if you are interested in the basics there is a very good document on MDN. Instead, I would like to outline a few simple experiments which illustrate the properties of a prototype chain and why you might want to take advantage of them.

For the basis of this post, I’m going to use the Constructor pattern and look at the following simple example:

If you were to look at the `football` object in your browser’s debugger you would see that it has a property called `prototype` which is a reference to its prototype chain. The chain would go:

Sphere → Object → null

Now, that code can be rewritten using the `prototype` property of `Sphere`, like so:

As you can see, the result is the same. But, if one were to compare the two version of the `football` object they would see a difference. In the first incarnation “pi” and the “volume” function are both own properties of `football`; in the second version those two properties are no longer part of `football` but instead are properties of its prototype, `Sphere`.

You can prove that by changing the value of “pi” in the prototype:

So, without changing `football` at all, its reference to “pi” has updated. As “pi” was not an own property the prototype chain was consulted and value found in `Sphere`. That has a very important implication: for any instances of `Sphere` there is only one object which is the prototype. That is, if we created a second `Sphere`, called `tennisBall`, it would not just have the same properties in its prototype as `football`, it would have a reference to exactly the same object as its prototype. So if “pi” is updated in the prototype it is updated for every instance of `Sphere`.

That can be a useful property in of itself but it has huge implications for application performance. Suppose we create a large number of `Sphere`s. In the original example (without using the prototype property) there would be a property “pi” and a function “volume” created once for each instance of `Sphere`; when those properties are part of the prototype they will only be created once. So for a million `Sphere`s there would either be 3 million properties (a radius, pi and volume for each) or 1 million and 2 properties (a radius for each and a pi and volume in the prototype). That makes a huge difference to performance:

Using properties of the prototype:

Using own properties:

On my laptop, the version with the properties stored in the prototype ran in 0.563 seconds, verses 1.349 without. That’s more than three times the speed!

So, it’s not just about coding style: the `prototype` property is very important, particularly when your code creates many instances, and needs to be understood. If a property is likely to be unique to the instance then it should be ab own property, otherwise it’s often worth moving it into the prototype.

An odd page layout (using CSS first-of-kind, last-of-kind, and nth-of-kind selectors)

Consider the following layout for a page with a collection of articles:

It’s a fairly common structure and really good for emphorsizing the lead story. I set about trying to create that layout as a theme for a FactMint infographic. As it was a theme, I couldn’t add any additional classes to the HTML (and would rather not anyway). I started from this criteria:

The first article must be full width and all others half width.

That can be accomplished using the CSS selector

`section article:first-of-kind`

or similarly using the `:first-child` pseudo class.

Although the criteria is fulfilled, there is problem. Take the case where there are two articles:

Looks a little unbalanced, at best. So, what’s the solution? Well, one could make the last article full width, too. That is accomplished using a selector like:

`section article:list-of-kind`.

The issue with that approach is fairly clear, it just moves the problem onto the cases where there are an odd number of articles; the penultimate article will, then, be solitary and half-width:

Logically, the general solution is easy to describe: make the last article full width only in the cases where there are an even number of blocks. The question is, how would one accompish that?

I’ve seen this problem resolved in the past by adding conditionally adding a class (say, `.full-width`) to the last article, subject to there being an even number of articles. That could be implemented using a templating engine or just code. The solution has its merits – it’s pretty easy to understand, for one thing, which is a big pro. It is, however, not a semantic class; even if you were to call the class `last-component`, while it would be semantic, the fact that it is conditional would nullify its sentiment.

Here’s the solution I came up with. It is dependent upon the precedence of four CSS rules, implemented by their order in the stylesheet. Namely:

1. All articles are half width
2. The last article is full width
3. All odd articles are half width
4. The first article is full width

So, the first article is always full width, as it’s the last (highest precedence) rule and the last article is full width unless it is odd (as the odd rule overrides the last rule).

Here’s a jsfiddle to illustrate. Play around with the number of `article`s in the `section`.

Force distribution bubble chart

For my company, FactMint, a big part of our software is building data visualizations automatically. One of the staple diagram types for visualization designers has always been bubble charts. They always seamed a little complex to build programatically, however, with one needing to to account for a non-overlapping, evenly distributed layout.

Anyway, I finally took the plunge and build a proof of concept in JSFiddle. I think it’s rather neat, so I thought I’d share it:

Rationale for developing the Iugo one-way binding library

Recently I built a new Javascript library for binding objects to the DOM. It’s called Iugo and you can find it here: http://iugojs.com. Now, clearly, there are other binding libraries out there, so I wanted to produce a quick post to summarize my thought process going into this project…

I first started to think about this kind of project around two years ago when I first started using Angular.js. If you are not familiar with Angular , it’s a Javascript framework which includes two-way data binding (i.e. objects are bound to the DOM and changes to those values in the DOM are bound back to the object) and a bunch of other features. It’s a great framework and my initial reaction was very positive; I quickly became a fan.

After getting a little deeper into a fairly complicated Web application, however, I frequently found myself frustrated with the framework’s complexity. In order to understand why I believe there is a place for a new data binding library I need to give a quick review of Angular:

Things I like in Angular

Two way data binding

For me, the data binding feature is the core of Angular (I expect its developers would agree). Without data binding developers often use Javascript to inject HTML segments into a document. There are numerous problems with this approach. In the same way that decoupling style and content is a good idea, decoupling markup and data should be considered a very high priority best practice.

Imaging a designer who is employed to improve the UI of your app is looking at a div elements in their browser’s inspector and they really want to change them to be an unordered list (ul/li elements). The designer also notices inline CSS is applied when a user clicks on one of the divs and they want to change that into a semantic class. The designer looks in the HTML but there that section is just missing. The actual HTML for the divs is injected in a loop in a Javascript file and the click handler which adds the inline CSS is somewhere else in the file. Would you want a designer who doesn’t know the code to make those kind of changes? Would they even find where to make them? The whole situation is a mess.

Using templating or other data binding techniques makes your code much more accessible. Designers work on HTML and CSS and can see everything. Logic can  deal purely with data and just update the model behind the UI.

That said, two way binding is an interesting thing. In one direction data binding is an easy thing to achieve. If a user updated an HTML form input it is easy for a piece of Javascript to update a model – it can just listen for the change event to be fired from the input. The difficult part is binding the model to the HTML – there is no event that fires when an object is changed. That became the functional core of Iugo – it’s a library which fires events when objects are changed.

Scopes

The idea behind Angular scopes sounded fairly simple when I first read about them – basically a scope is a model and it is bound to a part of the DOM. In simple Angular applications there is often only one scope, bound to the whole HTML document. When my application became more complex than that I continually found myself confused and wasting hours debugging my code to work out how to get two scopes to interact. Sure, you should design your scopes to be independent (that’s what a scope is!) but  a couple of times I realized further down the development process that I had some unforeseen need to access two scopes; at that point my options were to redesign my application from a fairly fundamental standpoint or to deal with mounting difficulties and hacks used to get around the scope system.

One mandatory feature for Iugo was the ability to access namespaced models at any point in the DOM. Not to mension a lighter touch so objects don’t need to be treated in a special way if you are using them as a model.

Being a framework

If you need a framework then check out Angular. If you have a requirement for data binding and templating then you may want to consider your options (including Iugo). Angular includes ajax helpers, scenario testing, localization, URL management, dependency injection, event listeners, test helpers (such as angular.isArray()) and a host of other features. Those features may well be useful to you but they add up to 80k minimized – about the same as jQuery; if you already use a framework like jQuery do you really want duplicate HTTP helpers, &c? Personally, I prefer smaller, modular, libraries. Iugo is 5.8k minified, less than a tenth of the size.

Not being HTML5 complient.

For the record, I think Angular may have fixed this with some kind of compatibility mode but their website is littered with examples of non-compliant code. Take the example on the homepage. They use the “html” doctype but have an attribute called “ng-app” in the document’s html tag. That’s not allowed; try it in the W3C’s validator.

Introducing Iugo

So, this those points in mind, I set about creating a simple data binding library. Iugo is:

• Small, less than 2k minified and gzipped
• light touch – it will complement other frameworks like jQuery
• standards compliant, no namespaces or invalid attributes
• modular, as it is based upon an event system for objects

I’d love any feedback anyone has, so please check out the site.

Conway’s Game of Life

I’ve been fascinated by Conway’s Game of Life for a while now. I was reminded about it when I read Stephen Hawking’s Grand Design, last summer; which uses the game’s universe as an argument both backing Descartes’s Evil Demon concept (although I don’t think Hawking was suggesting that to be true – just an interesting thought experiment) and to show the surprising likelihood of life in a universe governed by simple rules. If you don’t believe the latter point have a look at Gemini, the first self replicating entity discovered in the Game of Life; when you consider the scale of our universe it seams less surprising that complex life could arise.

Some patterns from a Game of Life

Anyway, I’ve intended to write a Game of Life model for some time and got round to it the other day. You can have a play here: http://chrisscott.org/gol. Click randomize then start to get going – you can also click individual cells to toggle their state, while the program is stopped.

The source code is available on Github, it might be a nice widget to include on a Web site.

CSS for code tags

Recently I was looking at ways to improve the aesthetics of code I was putting up onto a site. I didn’t want to go down the route of a full on Javascript code highlighter but as I was looking at Syntax Highlighter I thought I must be able to replicate the look and feel (without the highlighting) just using CSS.

The basic premise is to repeat background stripes using `em` measures, to keep them inline with the text.

Here’s the result:

Favorite stars

Quick idea for CSS stars – useful for marking something as a favorite…

```.star.starred:before { content: "\2605"; }```

``` .star:before { content: "\2606"; } .star { font-size: 2em; cursor: pointer; } .star:hover { text-shadow: 0px 0px 3px yellow; } ```

```.star.starred:hover { text-shadow: 0px 0px 3px red; }```

Add a little bit of Javascript to toggle the “starred” class:

```\$('.star').on('click', function() { \$(this).toggleClass('starred'); if (\$(this).is('.starred')) { // Do something to record that this is favourited } });```

Here’s the results.