An example of Hypernotation

Let’s publish some data using Hypernotation. I am going to use the same (Chuck Norris) RDF example I have used on the blog so far. You can see the published data on and the prefix mappings on The domain is different for obvious reasons – I used my domain instead of, but the structure is the same as in the below diagram.


Every circle represents one web page. The contents of a circle is (rendered) HTML that you see when you visit that page in the browser. If you click on a circle, the web page it represents will open up, so you can see what it looks like in the wild.

As you can see from the image, the web pages are organized hierarchically, with the homepage as the root of the tree. Hypernotation allows you to browse data in a similar way you navigate through folders on a hard disk.

The arrows connecting the nodes (circles) are links between the web pages, pointing from a parent web page to its (immediate) child in a hierarchy. For each node in the tree there is a unique path leading to it, that can be seen by placing the mouse over it. Therefore, the URLs are paths comprised of a number of segments, i.e. the labels of all the links connecting the intermediate nodes between the root and that particular web page.

The labels next to the links are relative paths from the parent to the child page. Therefore, the web address can be figured out by adding that label to its parent’s address. For instance, the relative path from to is data_, which is also the last segment of the child’s URL (

From web pages to hyperNodes

So far, I used the word “web page” for what the circles represent. However, although written using HTML tags, these web resources are not ordinary web pages. Hypernotation is expressed using just a tiny subset of HTML—it needs a way to say “link” and “list”, and (semantic) HTML tags <a>, <ul> mean just that, so there is no need to invent a new syntax.

If using HTML in such a way confuses you, you can think of it as of XML that happens to have tags with the same names as in HTML (and is shown in a browser in a friendly and interactive way).

In the Web of documents, a web page, i.e. an HTML document, is a tree of (nested) HTML tags. In Hypernotation, the whole website is seen as a tree, in which the “web pages” are closer to the idea of a single HTML tag. In Hypernotation, data is realized at the most granular level possible, meaning that each node, i.e. a web resource represents a single, indivisible, atomic piece of data.


The image above shows the comparison of an HTML document and a Hypernotation tree. While a HTML document is serialized in a “flat” file using HTML syntax, Hypernotation has a “real” structure, thanks to using HTTP URLs as the names for its elements. Another difference is that in HTML document a HTML tag can contain more elements of the same name (like the two <script> tags in <head>), while in Hypernotation all nodes with a common parent must have unique name (like in a file system).

Another essential difference is that Hypernotation is based on the RDF model. All web addresses follow the “RDF graph” URI pattern that turns URIs into fully transparent paths encoding the relations between resources in the URI itself. In other words, they encode a set of chained RDF triples where the subjects and objects are nodes in the hierarchy. Therefore, the paths can be decomposed into triples that describe the meaning of the resources.

Take for instance /data_/chuck/foaf_based_near. What does this resource represent? What’s its meaning? You can find out either by a direct answer, or figure it out indirectly, from the context in which the resource exists.

Hypernotation’s way to ask a direct question is to look up its (rdf:)type property. In this case, it explicitely states that the resource is a geo:Point, i.e., as described by its rdfs:comment property, “a point, typically described using a coordinate system relative to Earth, such as WGS84″.

What about /data_/chuck? Here we don’t have the rdf:type property, but there are others that can help. For instance, foaf:knows has the rdfs:domain foaf:Person, so we can indirectly figure out the nature of /data_/chuck.

What about /data_/chuck/foaf_knows/steven? From its address you can read that it’s something with a local name steven that has the relation foaf_knows with /data_/chuck. Here, the rdfs:range of the foaf:knows property tells us that we’re dealing again with a foaf:Person.

As you can see, web resources in the Hypernotation context have some special features. Their addresses use the HTTP scheme and follow the URL pattern which makes the URLs (URIs) and links machine-readable. Finally, these resources are interconnected nodes in a graph. To emphasize these features (constraints) on one side, and to highlight the relation to similar concepts (that often have the word “hyper” in their names), I will refer to them as “hyperNodes”.

From hyperNodes to hyperObjects, hyperArrays and hyperLiterals

HyperNodes (circles) and links (arrows) are the basic elements of Hypernotation. However, as you can see from the first diagram, not all circles are the same. Some return a list of links, and some show a plain text or a single link in the rectangle.

Also, if you look at the links carefully, you’ll notice that some has prefixed labels denoting properties, while others look more like some kind of identifiers. Finally, there are links without a label altogether.

In the previous two posts, I discussed different types of links and hyperNodes in detail. Hopefully the following image will clarify those ideas and show that Hypernotation is mostly based on well-known, existing concepts combined in a new way.

The above diagram is the same as the first one, except for the added colors distinguishing different types of elements.

The red hyperNodes represent objects described with properties, while the pink colored ones are arrays pointing to their elements. Such objects and arrays are in the Hypernotation context called hyperObjects and hyperArrays.

The links directed from both hyperObjects and hyperArrays are called tree links, meaning that they always connect parent nodes with their direct children in a hierarchy. However, there is an important difference between them. The red links are typed links with labels (prefixed names, i.e. CURIEs) that are mapped to URIs. Typed links are always pointed from hyperObjects, so they share the same red color together representing a logical unit.

The pink links, on the other side, are always pointed from hyperArrays; their role is to provide unique keys (IDs) for the hyperArray’s elements. These keys are not globally unique URIs like typed links, but only unique in the local context (namespace) of a hyperArray. These key links are always pointed from hyperArrays, so they share the same pink color.


The image above should help you better understand the relation between hyperObjects and hyperArrays. Here, togehter they build up what can be considered a table, in which the hyperArray provides unique keys for the “rows” (objects), while the object’s properties are in the “columns”. Of course Hypernotation enables a greater flexibility, where not all objects in the same “table” (i.e. belonging to the same class) must share the same set of proprites.

The black circles, called hyperAttributes, are hyperObjects that can be represented by a single value. In other words, a hyperAttribute is a hyperObject with the rdf:value property. Instead of returning the list with the single property, it directly returns the value (in rectangle). Just like you don’t say “the value of its name is Carlos” in English, but rather “His name is Carlos”, equalizing the name with its value for practical reasons. But, “Carlos” != the name, it’s the value of the name, and the value is just one of the name’s possible properties.

The blue arrows in the diagram are hyperlinks. On the Web, hyperlinks don’t have any particular meaning, but in Hypernotation they connect two different hyperNodes that represent the same thing. That is, they represent the owl:sameAs relation. If a hyperObject has just one owl:sameAs property, it becomes a hyperReference. Instead of showing the list with a single property, a hyperReference directly returns the value of owl:sameAs, i.e. the URL of the target hyperNode. Therefore, like hyperAttributes, hyperReferences are a “syntax sugar” enabling a shorter notation.


So far, we have dealt with the two types of hyperNodes—hyperObjects and hyperArrays. Besides the two “primitive” subtypes of hyperObject (hyperAttributes and hyperReferences), the image above shows another type of hyperNode—a hyperLiteral. Simply put, it’s a hyperNode representing a literal value. This value can be in the form of a plain text (black circle on the top right) or a hyperlink (blue circle on the bottom right).

A hyperLiteral is the only type of a hyperNode that actually holds data. HyperObjects and hyperArrays return the list of links to their direct children, i.e. hyperNodes they are directly connected to. This list is not “their data”—they don’t hold any data by definition. The list is just a representation of a structure that exists around a particular hyperNode, telling a client about the available links to follow to go on with traversal. A hyperLiteral, on the other hand, doesn’t have any children by definition and returns the data it holds.


As the above image suggests, all the types of hyperNodes can be divided into the three categories: structural, peripheral and terminal. The classification is based on the place a node holds in a tree structure. The structural hyperNodes build up the structure of the tree, while the terminal are the end nodes holding data. Peripheral are, simply put, hyperObjects directly connected to a terminal hyperNode.

Alternative methods of publishing hyperObjects

What if a hyperObject described with rdf:value has additional properties? If the other properties are as important as rdf:value, it can be realized as an ordinary hyperObject. But if rdf:value is dominant, the hyperObject can still directly return that value, and provide the list of all properties on the hyperObjectURI/_ path. The image below shows the both situations.

The left diagram shows a hyperObject that has two properties—rdf:value and ex:units. The two properties are shown in the list as equally important. The example on the right shows the exact same hyperObject published in the different way. It returns the value of rdf:value, like a hyperAttribute, but offers an alternative “hidden” link “_” to a hyperNode that is realized as a hyperObject (in the left example), but with links to the parent’s properties (../rdf_value and ../ex_units).

The homepage hyperNode (the first diagram) is another example of the second approach. Here, the rdf:value of the homepage is a HTML document that is returned after look up. The list of the properties (data_ and prefix_) could be obtained on the path (although it shouldn’t be mandatory in this case, because the two properties are so common).

In fact, every web page can be regarded as a hyperObject, realized as a hyperAttribute, whose content is the value of the rdf:value property. Put in this perspective, the Web of documents is just a special case of the Web of data.

What about hyperReferences? As explained above, a hyperReference is a hyperObject described with the owl:sameAs property, which tells that it has the same meaning as some other hyperObject. But they can also have other properties besides owl:sameAs.

For instance, we can add the property foaf:name to the /data_/chuck/foaf_knows/bruce hyperReference (from the first diagram). In that case, owl:sameAs is treated equally to other properties and returned in the <ul> list (as shown in the image on the right).


In this post I discussed an example of data published according to Hypernotation principles. Although the example covers many important aspects of Hypernotation, many questions are left open. For instance, how to quickly get the complete descriptions of hyperObjects? Sending HTTP requests to every hyperNode is obviously not an efficient solution, so a way to “export” serialized parts of RDF graph must be provided. In addition, what is the relation of Hypernotation and other RDF technologies and concepts, like SPARQL, named graphs, reification, data provenance, RDF notations? Is it possible to navigate through and filter large amounts of data easily (without using SPARQL)? Finally, is Hypernotation read-only or does it allow modifying data as well?

These are some of the topics that will be covered in the next posts. This post’s example shows what a backbone of Hypernotation looks like. The backbone contains all the information required for a “machine” to understand the data. It can be enriched and facilitated for a client, depending on the needs of publishers and consumers, the size of data and its purpose. Hypernotation is flexible in this regard, enabling many levels of sophistication. What’s even more important, it provides a consistent framework in which more “advanced” features can (often surprisingly) be realized elegantly using the same fundamental principles. Image Map