In my last blog entry I discussed various ways that different RDF datasets assign human-readable labels to resources, with the rdfs:label property being at the center of them all. I mentioned how schema.org doesn’t use rdfs:label but its own equivalent of that, schema:name, which its schema declares as a subproperty of rdfs:label. Since I wrote that, Fan Li pointed out that Facebook’s Open Graph protocol also has their own equivalent: og:title, which you can see used in the HTML…
First, reviewing some basics before I discuss the edge cases: resources in RDF are represented by URIs, and the spelling of a given URI often provides no clues about what the URI represents. For example, you wouldn’t know from looking at http://www.wikidata.org/entity/Q144 that it represents “dog” as a Wikipedia topic. (We’ll see below that this is a for a good reason.)
During the first pandemic summer I asked my wife for a cheap tenor banjo for my birthday. These are tuned like a viola and smaller than the traditional five-string banjos used for bluegrass. Instead of fingerpicking patterns with the right hand like bluegrass banjos are famous for, tenor banjo players strum chords with a pick for volume as a rhythm instrument. When you hear a banjo in old-timey jazz, that’s a tenor. (Around the time the ground was being laid for bebop, Charlie Christian…
SPARQL 1.1 has been with us for about ten years. Work on SPARQL 1.2 is currently underway, and one nice set of improvements will let us do much more with date and time values.
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…
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.
I was catching up with my old friend Paul Prescod the other day. We have not only known each other since the early days of XML, but actually before that: “since XML was a four-letter word”, to quote Paul.
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.
