RDF and HTTPS

HTTPS is becoming the new norm on the Internet, but in most places, HTTP is still the "default". One of them is RDF ‒ being stuck with a particular URI to identify vocabulary terms means that even a minor change of one "s" in the URI scheme makes it identify a completely distinct resource. For this reason, RDF URIs (and similar things like XML namespaces) will never change to https. However, this is not such a big deal, for at least two reasons:

• URIs in RDF are not "meant" to load data from. They should be dereferenceable, to make it possible to find out more information about the resource from the URI itself, but there is no obligation. Especially when talking about vocabulary terms, there are not that many automatic and security critical processes that would request descriptions of every encountered vocabulary term, and arguably there shouldn't be ‒ if it is so important to load the vocabulary from a trustworthy source, you should not download it from the URI in the first place, since it should have already been on your disk and verified manually. HTTPS is not going to save you from network outages, random errors, or hacked webservers, and the worst thing a potential attacker could cause through HTTP anyway is to break your inference.
• Browsers have already started treating http in URIs as not as binding, instead they may switch to HTTPS under various conditions, and they send the Upgrade-Insecure-Requests header for the server to direct you to HTTPS as quickly as possible. With HSTS (HTTP Strict Transport Security), you request the browser to never use HTTP only for the given domain, and even if entered manually, the browser will switch to HTTPS (with no bypassing). It is also possible to preload a given domain to be stored in a list that is used by all modern browsers, so that first HTTP-only request never ever has to take place.
  

In case you actually are making an automated RDF vocabulary loader, it is a somewhat important question how to interpret http in URIs. There are a few possibilities:

• Do nothing special. If there are no particular requirements, I don't think there is anything wrong with upholding the protocol indicated by the URI.
  
• Many web servers always auto-redirect to HTTPS, disregarding Upgrade-Insecure-Requests. Arguably, if security is so important for these servers to ignore user's preference, they should also send Content-Security-Policy to make this redirect automatic. If you cache this information, you can feel safe if you treat http as https next time you make a request (but only for the connection, don't rewrite it in RDF!).
• Due to the forced redirect most websites do, it may be a worthy optimization to use HTTPS automatically and revert to HTTP only in case of issues (can't connect or no actual RDF description found).
  
• The HSTS preload list is available to download, and you can use this to skip the first round of HTTPS redirecting altogether. There are a few nuisances though ‒ the list is very huge but stored as JSON (and the download is base64-encoded), which is not such a great streaming format, and there are also comments. Its location has also been needlessly changed at least once, so better be on guard for surprises.

I decided to explore the last point and assess how exactly would this help the vocabularies found on the web. The results were not great...

Having no standard is better than having some standard

"You can't mean that!"

JSON-LD is the new XML

It's been a pastime of mine to compare XML and JSON, as a mature, expressive and self-descriptive format against one that is ambiguous and unextensible. As many of you should realize by now, this comparison is actually quite meaningless ‒ these two formats have a vastly different focus and primary area of use ‒ XML is focused on documents (apparent for example in situations where formatting may be relevant), while JSON is focused on representing commonly-used structures in programming languages (well, only those in JavaScript) and nothing more and nothing less. There are however usage areas where these two formats overlap, and that is when describing entities or objects of various kinds, linked together using properties. In other words, linked data.

Converting between XML and JSON

There are hundreds of things I could be doing now, so... let's think of a way to convert from JSON to XML and vice-versa!

Why? Because why not? JSON seems to be becoming quite a prevalent format for storing and transmitting data, despite its lack of mature tooling, visualization, comments or extension mechanisms, so it might be advantageous to work with XML which, despite being constructed from JSON, would be reasonably "natural". Let's get started!

Mapping .NET exceptions to XPath Errors

Because why not?

The namespace http://www.w3.org/2005/xqt-errors# (shortened to err:, also described here and here) hosts a number of error codes relevant in the context of XPath functions, XSLT or XQuery. While these errors are usually useful only to XML processors, there is really no reason not to use them when describing errors in general. Imagine you are trying to use RDF to describe the result of a process, or perhaps monitoring a single programming function. The function may fail, end in an exception or otherwise not produce a desired effect, in which case it is useful to be able to use a standardized identification for the cause of the error. Of course the original exception would be more useful to people actually fixing the error, but this should be "language-agnostic", potentially translatable to any different language which uses similar concept of exceptions or errors.

I decided to browse the error codes listed in the namespace, and tried to match them with exception types in .NET. There are not that many of them that align, but the useful ones are still representable. Coupled with properties like err:code, err:description, err:value and err:line-number, these may be useful when describing arbitrary program errors in RDF.

Thought on the Future of Computers

I am going to make a prediction about the future of computing, not in a distant future but more likely what might be in a few decades. It's also not a particularly creative prediction, because the process that might eventually lead to it has already started. Yet it's interesting to imagine, so here it is:

RDF-star and prototypes

Updating the RDF specification to create a new version is not an easy task. While getting new features added in is (relatively) not that hard, the cloud of related specifications, such as SPARQL, SHACL or OWL, is pretty large, and the whole ecosystem of applications and databases made to work with it is even larger. As such, getting new features actually out in the field is definitely not trivial, and some of the issues that may arise as part of that are still apparent today ‒ RDF 1.1 came out in 2014, while the latest version of SPARQL is still from 2013, and as a result, plain literals in SPARQL are still not quite exactly the same as string literals, even though RDF 1.1 doesn't make the distinction anymore.

A different approach is to develop a new version sideways, i.e. create a variant of RDF just with your own favourite new feature. This is similar to how XML is defined, as a set of specifications whereby the core XML specification, to the surprise of many, doesn't actually define anything related to namespaces, xml:lang or datatypes. The folks at RDF did a similar thing and created RDF-star, which is why this flew under my radar for so long.

The Glory of Semi-Structured Data

A not-so-recent trend in information storage has been an increase of use of an interesting blend of structured and unstructured data. Such a style of expressing information is convenient for users, and with the advent of neural networks and prompt-based programming, also manageable for automatic processing.

Delphi form data (TPF0) binary format

Delphi uses a Pascal-like syntax for .dfm files which are meant to store data about forms and various controls, but also other resources and miscellaneous data. These files are compiled to a special binary format and then used to construct and initialize the forms when the application starts.

I wanted to parse these files to retrieve some of the more useful data therefrom, but I wasn't able to find any documentation about the format, so I analyzed it myself and that means you don't have to. What follows is therefore a description of the format and the data model is stores. Some basic knowledge of principles of data storage is expected.

The Models of CONCURrent SGML

Nowadays, the old glory of SGML is almost forgotten as it got replaced by XML in all but a handful locations, but the language itself still has some very impressive capabilities that, I dare say, might yet make it a viable option for some very specific cases in the future. One of those features is "CONCUR", a.k.a. the original namespaces. This comparison is inaccurate of course, so I will first take a few paragraphs to describe what this feature is, and how it relates to the whole SGML ecosystem.

Identifiers for some file formats

I managed to find a gold mine when it comes to URIs and identifiers: the DocBook notations module. DocBook is an older SGML/XML-based standard developed by OASIS used for writing documentations, and with its DTD comes a module that “imports” several then-common notations for use with unparsed entities.

What Flavour is Your Function?

One programming article worth reading is definitely What Color is Your Function? by Bob Nystrom. A good old rant about the design of several programming languages, one that separates them into two groups of good languages and bad languages, depending on a presence of a certain feature.

The gist of the article is describing a feature called “colored functions” and then analyzing languages depending on whether there is some mechanism akin to this. The presence of a callback mechanism for asynchronous programming is basically the only application of these colored functions, but I believe pointing out other similar mechanisms is worth doing.

XML Lite (definitely not XML 2.0)

Years after the conception of XML, it had been customary for programmers to point out its perceived flaws and suggest fixes to the language. This trend has somewhat declined in recent years, as developers have either learnt to live with XML, or discovered that they can use something else.

I do not share these feelings towards XML. In many cases, I find it suitable for various purposes, and I think many cases of criticism stemmed from misunderstanding. Yet even I would like to add some features to the language, based on my experience. Let's take a look at them.

Finding the UUID for almost anything

Universally Unique Identifiers are a nifty way of obtaining identifiers for resources, objects, or concepts, without the need for a central assigning authority. Arguably the largest public use of UUIDs is from Microsoft's products, where they (known as GUIDs) identify classes or interfaces within COM, for example 450d8fba-ad25-11d0-98a8-0800361b1103 identifies the My Documents folder, accessible via shell.

What's less known is the fact that UUIDs have a specific structure and are not necessarily composed of random numbers. The earliest generated UUIDs used time as one guarantee of uniqueness (the UUID in the example above was created in 1997); these are version 1 UUIDs. Nowadays, you can still use them if you want to preserve the creation time in the identifier, but the most common are version 4 UUIDs that consist almost entirely of (pseudo-)random bytes.

Usually, one associates the generation of UUIDs with some random process that produces different identifiers each time it is invoked. A less known version of UUIDs, however, makes it possible to produce identifiers for certain resources deterministically, that is based solely on some input data and producing the same result each time.

HTTPS redirection in Apache HTTP Server, properly

HTTP is the standard text-based protocol for retrieving documents from web servers, but, like most net protocols, has the unfortunate issue of using a transport method that is insecure. The packets that correspond to an HTTP message may be observed by routers before they reach their destination, and the whole message may be reassembled and inspected by malicious devices. Thus plain HTTP is commonly wrapped in TLS, resulting in HTTPS wherein messages are encrypted and can be decrypted only by the actual endpoints.

HTTPS is not absolutely necessary, however. As a user, you don't need it when browsing static content, unless you care about anyone in the way not knowing what browser you use and what content you view, or you want to verify the identity of the server. HTTPS is good to have as there will always be users that need it, but in these cases, it shouldn't however be forced upon other users, as it does bring some inconveniences. You have to present a valid certificate, it has to be signed, it cannot be expired, and it is always possible the version of TLS you use becomes obsolete. In any of these cases, all web clients start warning the user or stop the website from being accessed at all.

This is where Upgrade-Insecure-Requests steps in. It is a header sent by all modern browsers, informing the server that the client wishes to use HTTPS whenever possible. It can be turned off however, and most other tools (command line-based or in programming languages) do not send it by default, so you can specify the protocol by yourself freely.

Why you should never unescape a URI

The street address of the Internet, the URI, is an interesting piece of syntax. Its specification is longer than those of some data languages, and together with all the existing schemes, it would take a couple of books to describe it all. The simplified form of an (absolute) URI is this:

scheme://host/path?query#fragment

Virtually all portions except the scheme can be omitted including their surrounding syntax, making the format very flexible and usable for a multitude of cases. Yet there are some cases where some of the design decisions cause troubles.

URI scheme for identifying linked data entities by their identifier

It is a good practice in RDF to identify entities with a URI scheme that may allow one to eventually arrive at a description of the identified entity. However, the individual URI patterns aren't semantical, and there isn't a uniform standard that would allow identifying an entity within a particular dataset. This is an attempt to devise one. The resulting URI should behave like a "link" that connects to the dataset and finds the actual URIs used for the entity. In theory, it could even be used directly to identify the entity itself.

Identifying resources works by traversing inverse functional properties. This kind of a property (an instance of owl:InverseFunctionalProperty) behaves like a function from its range to its domain. Thus a particular value assigned to the property serves as its primary key which, when used with the property, uniquely identifies the resource.

More about datatypes in RDF

Datatypes in RDF are arguably the most confusing and also underutilized tool in RDF. To understand datatypes, we first need to understand literals.

Literals

While RDF and XML are very different in many aspects, they share some core concepts. XML at its core doesn't really have standard datatypes like you'd find in many programming languages and other data languages like JSON. Instead, you have text (or character data if you will) which might get a specific meaning via other facilities, but to an external observer, everything is only text (or whitespace if you want to go into details).

RDF is very similar to XML in that a literal is simply a piece of (character) data. Unlike XML however, it is also possible to assign a datatype to the literal. The notion of a plain (untyped) literal was changed somewhat in RDF 1.1, making xsd:string the implicit datatype (more on that later). Specific serialization formats may define syntax for other common typed literals, such as numbers or booleans, but all of them are still backed by text. Thus a literal is simply a piece of text, optionally with something that identifies its datatype (we forget language-tagged literals for now).

Recommendations for producing linked data

While working with RDF and linked data, I have tried to come up with some tips that, in my opinion, make publishing RDF data better in a wide range of qualities. I shall call them IS4 Recommendations and list them in this article (which will be updated in case of new ones):

Dynamic Self-contained Infinite XML

Imagine a window showing some sort of a feed. There are multiple panels displaying various messages as they arrive, plus some boxes that show statuses of other things, or the time, for example. This is a complex system usually thought of as calls to different APIs, various types of messages, presentation layer etc. What if I told you however that such a feat could be done even with only standardized formats, no client-side scripting and a single XML document and HTTP request?