I’ve had a decent understand of what the VALUES keyword can do for a while (see SPARQL 1.1’s new VALUES keyword and “Creating Tables of Values in your Queries” in my book Learning SPARQL) but lately I’ve gained a greater appreciation of ways to use it. For example, last month I used it to map codes assigned by an entity recognition tool to schema.org classes. This month I found a nice way to use it to control one of Wikidata’s many cool data visualization…

Entity recognition from within a SPARQL query

Using my new employer's excellent free product.

I recently announced that I have joined Ontotext as a full-time Senior Tech Writer. I have admired their free GraphDB triplestore for a long time (for example, I wrote about how well it supports the GeoSPARQL geospatial extension in October of 2020) and I am now learning about all the great capabilities of their commercial products, such as the scalability of GraphDB Enterprise.

More advice about software documentation

Especially documenting APIs.

Early last year, in the blog entry Doing a podcast interview about technical writing, I described an interview I did for the IEEE Software Engineering Radio podcast. Listening to it again this week I saw that I covered a lot of good ground. Since then I have thought of a few other points I wish I’d mentioned, so here they are in another bulleted list. Because of some recent experience I had enough thoughts about documenting APIs that I gave that discussion its own section below.

Using the AWS Graph Explorer with Fuseki and local datasets

An open source visual graph navigator.

When I first heard about the AWS Graph Explorer I assumed that it was a cloud-based tool for use with Neptune, the AWS cloud-based triplestore. After I read Fan Li’s First Impressions of the AWS Graph Explorer I realized that you can install this open source tool locally and point it at any SPARQL endpoint you want, so I cranked up Jena Fuseki on my laptop, loaded some data into it, and installed the Graph Explorer.