Hypernotation: Classification of hyperNodes

In the previous post I discussed how RDF and Object-oriented model can happily live together. In this post, I am going to talk about various types of nodes in the Web of data graph and different ways to classify them.

In the OO model, variables can be assigned objects, arrays, primitive data types (numbers, string, boolean…) and so on. In order to make things simple, let’s (again) use a JavaScript (literal) object representation of our chuck object.

var chuck = {
        foaf_name : "Carlos Ray Norris",
        foaf_based_near : {
                rdf_type : geo_Point,
                geo_lat : 45.45385,
                geo_long : 10.19273
        },
        foaf_knows : [steven, bruce]
};

Now let’s observe the various types of variables that describe the chuck object. There are primitive data types, like foaf_name, geo_lat, geo_long that have string and float value types respectively. There is the nested object that is assigned to the property foaf_based_near of the main chuck object. rdf_type is a reference to another object, geo_Point. Finally, we have the array foaf_knows whose elements point to the objects steven and bruce.

An object in the OO model can be represented as a graph, where each variable becomes a node. In the Web of data graph published using Hypernotation, this node is called a hyperNode. It is identified by HTTP URI and may or may not hold data. A hyperNode is the most general concept representing a parent class from which all other node types inherit.

All kind of different types used to describe the object chuck exist in Hypernotation, keeping the same names plus the added prefix „hyper“. Therefore, we have hyperObjects, hyperArrays, hyperReferences and „primitive“ hyperNodes corresponding to primitive data types. Here, the prefix „hyper“ is added to make a distinction from „classical“ concepts and to emphasize the new context in which they exist, together with the fact that they are, without exception, identified by an HTTP URI.

So far, the parallel between the OO model and Hypernotation should be pretty clear. What can be potentially confusing is that in Hypernotation the value itself is a distinct node, called hyperLiteral. For instance, „Carlos Ray Norris“ is a value of foaf_name, meaning that the two are distinct concepts (the former is the value of the latter), and thus represented as separate nodes in a graph.

Of course, literals as separate „nodes“ in RDF are well known, but what is new here is that they are explicitly described as values (using the rdf:value property). In addition, they are, like all the other types of nodes, identified by a URI. Hypernotation is consistent in this regard – a hyperLiteral is just an instance of the hyperNode “class”, thus inheriting its properties. Using a URI as an identifier is one of the defining properties of a hyperNode.

One can make a comparison with another model based on a tree structure – the Document Object Model (DOM). In DOM, there is a top class (constructor) Node and all the more specific node types inherit from it. There are conceptual differences between elements, attributes, text nodes, but everything, even a text, is a node. The result is that each text node, as any other node, has common Node properties like e.g. nodeName, nodeType and nodeValue.

Compared to the classical RDF model that is a labeled, directed graph, Hypernotation is based on a predominantly tree model. Therefore, if you have trouble understanding why literals in Hypernotation have URIs, blame the simplicity and consistency of a tree as a data structure. In a tree, everything is a node, and every node has a unique name (in the form of a path, i.e. a URI).

Classification

There are several ways to classify nodes of the Web of data graph.

1. Based on the place a node holds in the tree structure, hyperNodes can be divided into two basic types of hyperNodes – the ones that participate in forming the structure of a tree (structural), and those placed on the end of branches, holding some data (terminal). HyperLiterals are terminal nodes, while all the other types of hyperNodes are structural.

Structural nodes don’t have a value, unless they are directly connected to terminal nodes. In that case, they act like a primitive data types that can be represented by single values. These „primitive“ hyperNodes connect structural and terminal nodes and can be regarded as the third class of nodes (peripheral). They can have a literal value, like a primitive data type, or can be a reference to another hyperObject, in both cases using a terminal node to express themselves.

2. When projecting an (adjusted) RDF onto the Web, additional nodes that are not originally contained in the RDF graph are added. In that sense, another criteria of classification is by whether a node is part of the original RDF graph. HyperObjects and hyperLiterals represent nodes of the original RDF graph (URI references and literals, respectively) and can be called basic hyperNodes, while the other hyperNodes (hyperArrays, hyperReferences) that make the projection possible could be called auxiliary hyperNodes. What happened to blank nodes? Nodes without names don’t exist in Hypernotation, but there are nested hyperObjects that vaguely reflect the idea of chaining blank nodes.

3. Another way to classify hyperNodes is by data types, and corresponding HTML tags used to represent them. There are four possibilities: objects, arrays, references and plain text. They are realized using semantic HTML tags <ul> (and <li>), <a> and no tag at all. HyperObjects and hyperArrays are encoded as lists, while the value of a hyperReference is a single hyperlink. A hyperLiteral is realized as a plain text (or a hyperlink).

The first method of classification seems like the most natural one, so it will be used for the purpose of this post. By this criteria, nodes can be:

Structural hyperNodes

HyperObject

A hyperObject is basically a URI reference realized on the Web of data. It can be regarded as an object (in the object-oriented model sense) realized using fundamental Web standards.

After being looked up, a hyperObject returns a collection of typed links that it establishes with adjacent hyperNodes. This list is written using a <ul> HTML tag, while typed links are realized with <a> tags. A hyperObject can be connected to all other types of hyperNodes (including other hyperObjects), but these must reside on the same website as the hyperObject, and be its child nodes in the website tree.

Such a realization of a hyperNode resembles the view of a folder in a file system, which shows its “inner structure”, containing a list of its subfolders that enables further navigation through the directory tree.

A hyperObject is a property of its parent object in a tree. If a  property is multi-valued, it will be implemented as an element of a hyperArray. The standard „root“ hyperArray is website.com/data_, so the root hyperObjects have the URIs in the form of website.com/data_/keySegment. You can think of hyperObjects as of REST item resources, while keySegments are their IDs.

HyperArray

A hyperArray is a structural hyperNode that is used when a hyperObject is described with a multi-valued property, i.e. when there are several RDF triples with the same subject and predicate. In that case, there is a need for an “internode” which is a kind of a local “namespace” connecting the parent hyperObject with different values ​​of the same property. Here, the equivalent REST concept would be a collection (or a list) resource.

A hyperArray returns a list of key segments, tree links to the child hyperNodes realized using HTML <ul> and <a> tags. While a hyperObject acts as the subject of an RDF triple containing the list of predicates, a hyperArray gets the role of the „predicate“ connecting the subject to a list of objects (objects in the RDF sense).

A hyperArray represents a class that is a subclass of the range of the property used as a predicate, while its elements are instances of these classes. For example, the hyperArray http://chucknorris.com/data_/chuck/foaf_knows represents the class with the meaning “a person Chuck Norris knows” that reduces the class of all people (foaf:Person), which is the range of foaf:knows, to the set of people known by Chuck. Compared to a hyperObject that returns a list of typed links, a hyperArray is a list of untyped tree links (key segments) that have an implicit meaning of “has an instance”, being the inverse properties of rdf:type.

Peripheral hyperNodes

Primitive hyperNode

If a hyperObject is described by the rdf:value property (i.e. connected to a terminal node representing its main value), the hyperObject’s nature changes. The fact that it can be represented by a single value turns this hyperObject into what can be considered a primitive data type rather than an object.

In different object-oriented languages ​​primitive types and their relationship to objects are implemented in different ways. In Java, there are eight primitive data types implemented as special data types built into the language. However, Java provides a class for each to enable them the object’s functionality.

Similarly, in JavaScript objects can be instantiated behind the scenes what allows treating primitives as objects. For example, "foo".length will instantiate temporary String object and return the value its length property (3). On the other hand, every object has the method valueOf() which returns a single-value representation of the object. For example, new String("foo").valueOf() will return "foo".

Hypernotation is designed with a similar kind of flexibility in mind. That is, a hyperObject that has a value can be realized in two ways: as a primitive data type or an object, depending on the situation. If there are several equally important properties where rdf:value is one of them, the hyperObject can be realized as a regular (structural) hyperObject. That is, it will return the list of its child nodes with rdf:value realized as a separate node on the hyperObjectURI/rdf_value path.

HyperAttribute

On the other hand, if rdf:value is dominant (or, what’s often the case, the only one) property, the hyperObject can directly return that value instead of the list. This way, the value can be obtained by sending an HTTP request directly to the hyperObject URI, which is often more intuitive and practical.

If realized this way, a "primitive" hyperObject can be called hyperAttribute.  Here, the downside is that the list of other potential properties is hidden. The solution is to provide an alternative standard path for showing hyperObject's properties - "hyperObjectURI/_" (which will be discussed in more detail in future posts).

If a hyperObject has no properties whatsoever, one should distinguish this kind of  hyperObject from one with the value "" (an empty string) realized as a hyperAttribute. A hyperObject without any branches should return an empty list, i.e. "<ul />", which is in Hypernotation equivalent to the "null" value.

HyperReference

If a hyperObject has just one property „owl:sameAs“, it becomes a hyperReference. As in the case of „primitive“ hyperObjects, instead of returning a list with just one property (a hyperLiteral hyperObjectURI/owl_sameAs), it can return the value of owl:sameAs. It’s realized with HTML <a> element, a hyperlink that can point to any resource on the Web. Therefore, a hyperReference can be considered the special case of a hyperObject that has just a single owl:sameAs property.

However, a hyperNode that starts as a hyperReference can eventually evolve into an hyperObject, described by many additional properties besides the initial owl:sameAs. Or the reason of creating a hyperReference can be describing an external resource in the first place (which is the only way to do that in Hypernotation), than owl:sameAs has a role of telling that the described hyperObject is the same as the target hyperObject. In this situation, all properties are important and the list of properties (with owl:sameAs as one of them) should be returned the same way as with an ordinary hyperObject.

Terminal hyperNodes

A hyperLiteral is a plain literal realized in the Hypernotation context. It’s a node that represents raw data itself and is used when a hyperObject has a single-value representation that is expressed with rdf:value property. The URI of a hyperLiteral, therefore, always has the form of hyperObjectURI/rdf_value and it doesn’t branch further. Using its own URI is one way of publishing a hyperLiteral. The other way is to implement it as a value of hyperAttribute, what was discussed earlier in this post. This type of literal returns a plain unformatted text (atomic data), and can be called „raw data“ literal. Dealing with different data types is discussed in the post Getting rid of typed literals.

A hyperlink literal, on the other hand, is another type of a terminal hyperNode. Simply put, it’s the value of a hyperReference. A link from a hyperReference to its target object is another property, so it must exist as a separate hyperNode as well. Its URI has a form of hyperReferenceURI/owl_sameAs, and returns <a> tag with a referred resource's URI in the href attribute. Similarly as with the „raw data“ literal, it can be published in two ways, using its own URI or returning the value via its parent hyperReference.

Classification of hyperNodes

The above image shows the three basic types of hyperNodes and their mutual relationships. Hypernodes that strictly participate in forming a structure and are not connected to terminal nodes are in yellow column. P1, P2, etc. are different properties (typed links). A hyperObject that is described with rdf:value or owl:sameAs is considered peripheral hyperNode (green column). The two ways in which can be realized are shown on the image: one in which it returns the value of the hyperLiteral, and the other where it's realized as a regular hyperObject and the only way to get to the hyperLiteral is using its own URI (blue column). The additional hyperNodes it is connected to can be both structural and peripheral, so they are placed on the border between the yellow and green columns.


  • http://milicicvuk.com/blog/2012/01/23/an-example-of-hypernotation/ An example of Hypernotation

    [...] 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 [...]

  • http://milicicvuk.com/blog/2012/03/17/hypernotation-conventions-and-default-data-locations-rdf-%e2%80%9emethods%e2%80%9c-and-curie-magic/ Hypernotation: default data locations, „RDF methods“ and CURIE magic

    [...] addthis_options = "twitter,facebook,delicious,google_plusone,digg,hackernews,favorites,email,print";HyperObjects (you can think of them as URI references in an RDF graph) play a central role in Hypernotation. [...]