Gravital

A side-track of the research project is involved with the development of a graphic design language, based on the principle of semantic networks. In this language it would be possible to explain graphic design to a computer as if it were a five-year old.

Each problem in graphic design is unique. Each assignment requires that the graphic designer immerses himself or herself in the particular world of the client; be it building construction, health care, software design or grocery shopping.

Currently, whatever the problem is, we always fall back to the same set of tools, made with the graphic designer in mind. What if we set out to create a set of tools that were as unique as the problem? What if every assignment has its own toolbox?

This is what Gravital attempts. Gravital is an extensible language and platform that adapts to every problem domain. It is ideally suited for describing problems and solutions in their own language.

The principle of Gravital is based on Haskell and Lisp. It works as an environment in which a few basic language constructs are already available. You, as a designer, can begin inventing new concepts, relationships and entities that are needed for the problem at hand. You can even redefine existing language constructs: nothing is fixed.

The language focuses on the what, not on the how. You should never fall back to imperative programming logic: instead, you can build a language using a few basic mathematical rules, and a whole lot of compositions and aggregations. Language builds on language.

An example:

a is-a big centered circle
b is-a red square
b is above a

NodeBox generates a composition with a big circle of variable color at the center of the page, and a red square of variable size somewhere above it.

Of course, the current statements are open for interpretation: nowhere does it say what color the big circle should have, or what size a should have, or whether b should be directly above a. All those factors are things NodeBox will try out, to give you an idea of what is possible with the description you gave. The way he interprets the rules might result in some interesting ideas that you hadn't even thought of.


Shallow parsing language to Gravital

Even the mere theoretical existence of a Gravital poses a lot of paradoxal questions about language. Essentially, Gravital is nothing; it has no predefined set of tools to work with, tools are defined in Gravital itself; Gravital defines and expands Gravital.

An easy and valid example of this could be:

  • blue is-a color(0,0,255)
  • the right color is-a prism query

In both cases, we define new Gravital language constructs (blue and right color) to work with. They fall back on NodeBox commands like color() and the Prism colorfinder library which can be queried. Both things are known to NodeBox.

Now consider the following:

  • a circle with the right color is at the right of the center
  • a is a circle

What does right mean in this context? Is it a position or a justification (the question of what a justification is, is left in the middle (and left is used as in "leaving"))? What does a mean? a is a, or a is-a circle? The main problem here is the fuzziness in natural language... it is too complex for a solver algorithm to understand.

Most likely, Gravital should not be natural language at its core, but work with more concise and direct statements, like is-a instead of is a or could be. The latter two directives can then be handled by a shallow parser on top of Gravital, which would map it to is-a.

A shallow parser also solves the right problem(!). In observing the a circle with the right color is at the right of the center, the parser would know that a circle is an entity, that the right color is an entity with right being an adjective (justification), and that the right of the center is an entity with right being a noun (position).

It would map the statement to:

  • a is-a circle in right-color at-right


More mess and tautologies

The first step of creating a Gravital is getting rid of all the mess. We want to be able to define Gravital in Gravital. This leads to a number of complex problems at the core:

  • is-a is-a =

says and means nothing, but is beautiful and valid Gravital.

Another example. Consider the fact that all Gravital output is drawn in NodeBox. This would lead to something like:

  • visual output is nodebox
  • design is nodebox

as opening statement, which narrows down the entire field of graphic design to NodeBox! But, if NodeBox would really be able to understand such statements, we wouldn't need any other wieldy graphic application, we would be able to just talk to NodeBox, tell it what we want in plain English, and have it design for us. Ergo, design would really BE NodeBox! We only need Gravital to work... but since it is an empty thing that defines itself, it already works, so now I have proven design is already NodeBox (give or take a few logical fallacies in this paragraph :)

Another example. Consider a briefing in which you are telling the computer that "Tom and Frederik work together on this page layout, and they both like red and white". The first conclusion for Gravital would be that Tom and Frederik together make up the drawing canvas:

  • TomAndFrederik is-a page

which is utter bogus (and even grammatically incorrect)! A good lemmatiser or stemmer could help in transforming the statement to "TomAndFrederik are-a page" which is even more fun.

The very idea of a Gravital is already art in itself, but quickly leads to treacherous linguistical pitfalls that need attention.


Let's have some fun!

  • design is-a nodebox
  • tom and frederik is-a page
  • the right is always right
  • is a is a =
  • are-a is-a is-a
  • frederik is-a funny blue guy with-a white hat
  • beard is hairy grey
  • beard is-at top-of lucas
  • lucas is-a funny blue guy with-a red hat
Footer image