In the previous post I presented the simplest functionality of loading remote form contents by having SHACL property shape reference a Hydra Core collection.

In the second part I will extend that example to create a form with multiple connected dropdowns, where each one is only populated when other(s) have been selected, which is a common scenario seen in (web) applications.

Hydra Core is a community-driven specification for describing hypermedia APIs in a machine readable form so that client applications can discover the resources at runtime. On its own, however, it is not expressible enough to describe any arbitrary resource representation. SHACL, or Shapes Constraint Language, on the other hand is a beautifully extensible schema-like language which offers great power and flexibility in describing graph data structures. Combined, they provide a complete solution for building hypermedia applications driven by RDF.

In 2012 I started my .NET implementation of R2RML and RDB to RDF Direct mapping which I called r2rml4net. It never reached the maturity it should have but now, 8 years later, I have little choice but to polish it and use it for converting my database to triples. A task I had originally intended but never really completed.

Why is it significant? Because all those years later the environment around R2RML as a standard is almost as broken, incomplete and sad as it was when I started. Let’s explore that as an example of what is wrong with RDF in general.

One would expect the task of (REST) API testing to be a well-researched subject. After all, REST has been formulated over a decade ago and the number of APIs being built keeps growing exponentially. Yet, it seems that the art of testing APIs hasn’t changed much from the approaches used in testing RPC-style APIs or non-API code.

In this post I’d like to propose a different approach to defining and executing tests of a truly RESTful, hypermedia-driven API.

What good are stories if you’re not actually telling them? Storybook is a fantastic and versatile tool to create runnable showrooms of elements written in a number of javascript libraries. It presents live examples of components but lack in plain old storytelling - the prose. There are addons but they are not presentable enough (addon-notes) or do not support all targets (addon-info).

Here I present a different approach, using lit-html and a markdown custom element. It works well with my web components but hopefully could be adapted to handle any supported framework.

I’ve long been aware of GitBook.com as a way to easily author documentation pages. What I did not know before was that it also comes with a robust tooling for building the book locally and building as a static website. Works great with GitHub Pages, albeit needing some specific setup to run from the /docs folder. In itself though it may just be a good-looking alternative to other static page generators or documentation builders. The difference however is the abundance of plugins, and one plugin in particular useful for documenting JS code.

SQL Server LocalDB is not something new to me. The ability quickly to run, and destroy a database without much hassle has been great aid in running test code which was meant to target a live SQL database. That said, it wasn’t always without any hassle at all. I tried various tools which make it a bit easier than the command line tool but nothing was perfect. Until recently, when I’ve discovered the humbly named NuGet package which is as simple as it gets.

I’d like to share a few tips which might help you set up @storybook/polymer with a JS-only elements. The core issue was importing a base mixin class from Polymer 3, which causes the default babel configuration to transpile into an unusable bundle.

I’ve been using the Open Command Line by Mads Kristensen for several months now. Recently I’ve finally figured out how to have it open Babun and decided to share.

Some time ago I experimented and wrote about building composable UI using Polymer and <template> was my main building block. I used it to declare building blocks for my pages which I would dynamically interchange depending on the displayed content. Unfortunately I’ve hit a number of roadblocks but I think I’ve just recently found a solution.