OWFgraph is a graph database for the off-shore wind farm domain. It is an open-ended project that has currently sufficiently been developed to present it to the public for exploration and feedback purposes.

OWFgraph describes both physical objects and their attributes, as well as mathematical models, including computational tools, and their variables. Moreover, also procedures can be described. (Furthermore, phenomena are also allowed for, but this is currently not used.)

The above concepts, instances of which are represented as nodes in the database, can be described using labels and properties and linked by relationships to describe their connections.

This document is meant to help people use OWFgraph's web interface to explore the database. It is not meant to elaborate on the contents or uses of the database. I will revise and update this tutorial based on user feedback, so please let me know what would make this tutorial more useful to you.

Accessing the Database

OWFgraph's web interface can be found at


You will arrive at the interface after giving the correct username and password. (Contact me in case you do not know the username or password.)

What you see will look more-or-less like the image below.

The OWFgraph web interface.

The OWFgraph web interface.

You can see that we are using Neo4j as our graph database software. At the time of writing, we are running version 3.0; we may upgrade as upgrades become available, but this should not impact this tutorial.

This is a read-only version of the database, so it will not be possible to add, update, or delete content. This means you should not worry about doing something ‘wrong’ while exploring.

Getting Familiar with Neo4j

The starting screen presents you with a link ‘Start Learning’; please click it and go over the basic graph database concepts explained in the slides until you hit the ‘Next steps’ slide. There, click ‘Intro’ to get a high level overview of the web interface. Finally, click ‘Cypher’ to learn about the query language used to interact with Neo4j database instances, i.e., to create, read (view), update, and delete content.

Once you are familiar with the graph database concepts and the web interface, you can start exploring OWFgraph. Do not worry too much about familiarity with the query language Cypher: it can be learnt while doing, when you make an effort to understand the queries you come accross. For this purpose, a nice supporting reference to have open is the Cypher Refcard — http://neo4j.com/docs/cypher-refcard/3.0/.

In case you want to know more about Neo4j, or are looking for answers, then the following on-line resources provide good starting points:

OWFgraph's Foundational Ontology

OWFgraph is not just an arbitrary collection of nodes, properties, and relationships. To provide structure that can be relied on when looking for information and doing queries, we have designed a foundational ontology. Namely, we have imposed a basic framework that people adding information need to follow. When exploring the database, it is essential to be aware of this framework, so we discuss it in the remainder of this tutorial.

The foundational ontology

Node Types

There are six node types, each of which is implemented as a label. Any node in OWFgraph must have just one of these labels; they may have other labels from outside of this group.

There are four ‘physical’ types (labels). Let us start with the two more concrete ones:

The two more abstract ones are:

The two ‘mathematical’ types (labels) are:

Property Types

Every node can have the following properties:

The author, name, and description properties should in principle always be provided. However, for attributes and variables, description may be omitted if name provides enough information. (Currently also some models lack a name.)

Common properties

Common properties

Variables have some specific properties:

Relationship Types

The relationship types allowed between nodes are specific to the node types.

There are two relationship types that are allowed between nodes of the same type:

Most other relationships are more node-type specific. The first we consider forms the main bridge between the physical and mathematical node types:

Attributes that describe objects or procedures directly—so not via a PART_OF-relationship—must be either ‘structure’, ‘state’, or ‘cost’. Also, in principle, the ‘cost’-type attributes only describe procedures, but if the assembly or construction procedure of an object is left implicit, it may be connected directly to that object.

The next set of relationships represent the possible connections between variables and models:

The latter two relationship types are usually encountered for models that represent computational tools, rather than for, e.g., models corresponding to systems of equations. We actually use a Boolean property output on APPEARS_IN relationships to indicate the typical role of the connected variable in the context of that model (an output when it is true and an input when it is false).

Any procedure always INSTRUCTS an Object, which is typically a crew. We consider three subtypes of procedures that each have their signature relationships:

Finally, although we do not have any phenomena in OWFgraph, we do have specifications for how they should be related to two other node types. Namely, for attributes:

and for models:

Given these phenomenon-specific specifications are not tried and tested, they are still prone to change.

Closing Remarks