Introduction
3 Years ago I wrote a blog post which was a submission to the ISWC 2014 Developers workshop. The idea has been implemented with the Enyo framework which at the time was still a viable ecosystem. The implementation has been used in production in various installations of our systems.
Time has passed on and the EnyoJS framework is no longer supported, its successor was very much tied to react so would be very framework specific. In order to come up with a simple solution to the encapsulation problem I decided to reimplement the whole idea using WebComponents
Design Principle
One of the major issues with using linked data nowadays is that people still conceive the whole tool chain rather complex, even though JSON-LD has dramatically improved the usability of Linked Data in various front-end application frameworks. The central problem described in my previous post still remains, there is no semantics on UI level, front-end frameworks are able to consume JSON-LD but only by ignoring the semantics and treating it just like any other data stream. On the other side of the spectrum are UI building tools who manifest themselves as classic Monoliths, “So you want a front-end framework, you’ll need to use our triple store as well” This whole position is even stranger if you come to realize that in the Linked Data world everything can be done according open standards.
RDF, SPARQL, SPARQL-Protocol, LDP and more recently SHACL are all open standards who brilliantly inter-operate with each other and provide the building blocks to just develop components to create applications.
In this article I’ll describe the ideas behind our new set of WebComponents which allow you to absorb linked data in your application front-end without installing a monolith
The end goal
With the introduction of WebComponents came a new way of extending HTML applications and extending the semantics while still being able to use any traditional UI toolkit. The second major element is the SHACL standard, now there is a standard to describe which elements ( triples ) you want to select and use for your application. Inspired by SHACL and web components I came up with the following desired structure
<html><body>
<node-shape target-class='foaf:Person'>
<section>
<property-shape path='foaf:name'></property-shape>
<property-shape path='foaf:img' bind-to='img[src]><img></img></property-shape>
<ul>
<property-shape path='foaf:knows'>
<li>
<property-shape path='foaf:name' bind-to='.name'>
<span class='name'></span>
</property-shape>
</li>
</property-shape>
</ul>
</section>
</node-shape>
As you can see we map SHACL terminology within a relative standard HTML layout, this allows you to do any standard markup and styling through CSS. It will not interfere with any other standards DOM interactions on the elements encapsulated within the WebComponents.
To load the Linked Data into a <node-shape> we use rdf-ext a set of javascript libraries which again is adhering to a open standard. The <node-shape> and <property-shapes> will coordinate the propagation of the data through the HTML automatically, even dereferencing is taken care of. When multiple values are found, the encapsulated component is automatically repeated.
SHACL
Although we use SHACL as guidance there is no validation in place yet, we only use the selection process of SHACL to select these parts of our Graph that we want to display in our front-end. This also means that we might display incomplete Graphs, that is a issue we need to work on.
Status
This whole idea is work in progress, the current implementation based on WebComponents is now being tested with a POC and the results look great! We are planning on publishing the components as opensource on our github repository.
Some more detailed articles on how this works internally will be published as well!