Unotal Compared to S-Expressions

This is based on a preliminary draft of Unotal, which is still subject to change. For this reason, Unotal -properties and terms might not always be used consistently here.

Attributes

When using S-expressions, there is no standard notation for attributes. In fact, one can express attributes with S-expressions, but how to do this is not regulated uniformly.

Several notations for a list with the assignment "name=value" and the assignment "name1=value1" follow, which all have been found in several sources.

Several Notations of an Assignment with S-expressions

(example (name "value") (name1 "value1"))
(example (name -> "value") (name1 -> "value1"))
(example ((name "value") (name1 "value1")))
(example '((name "value")(name1 "value1")))
(example '((name . "value")(name1 . "value1")))
(example name: "value" name1: "value1" )
(example :name "value" :name1 "value1" )
(example 'name "value" 'name1 "value1")

In Unotal one would always write this as follows.

Notation of an Assignment with Unotal

< &example name=value name1=value1 >

Specification

The lack of uniformity of the notation of attributes with S-expressions is a consequence of the lack of a specification for S-expressions that is generally accepted. There are only several variants. In other words: If one is speaking of “S-expression”, it is not obvious which formal language exactly one refers to, as long as this is not specified in addition.

Unotal has a formal specification, but this specification is young and so still might contain errors.

Types

The first element of an S-expression sometimes is called its “tag”. In Unotal, the first entry of a room has no special meaning or rôle.

In Unotal, the type of a room is marked explicitly with an ampersand "&". Rooms might have a type; the following room has the type "href".

Unotal -room with the type "href"

< &href a=[http://yahoo.com] Yahoo >

It is also possible that a room has two types.

Unotal -room with the type "emph" and the type "bold"

< &emph &bold [Important!] >

It is not obvious, how a list with two tags should be written using S-expression. Possibly the following S-expression is an approximation, but the author is forced to write a nesting, that might not necessarily be intended.

S-expression, assigning two tags to a text

( emph ( bold "Important!" ))

A room might also have no type at all.

Rooms without a type in Unotal

< &bookmarks &UnoDB
  < [the catalogue Yahoo]      [http://www.yahoo.de]  >
  < [the search-engine Google] [http://www.google.de] >>

Here, the meaning of the entries (“columns”) within the inner rooms (in the last two lines) already is given by the type "&bookmarks" of the outer room. The inner rooms themselves are typeless.

Using S-expressions something similar might be written. If the specification used specifies, that the first element of a list always is a “tag”, then one might use "NIL" there. If the specification does not make any assertions about, what is supposed to be the “tag” of a list, then this detail of the notation might be specified somehow for an application, but this means that this aspect will be handled less uniformly across different applications of S-expressions.

Quotations Marks

Quotation marks in string literals of Unotal might be written using quotations marks while pairs of characters have to be used in S-expressions.

String Literal in Unotal

< &lesson [In C, "a[0]" is an expression.] >

String Literal in an S-expression

( lesson  "In C, \"a[0]\" is an expression." )

Paired brackets can be represented by themselves within Unotal string literals. Only single brackets and backslashes have to be represented by sequences of characters.

Symbols

In Unotal, there are no symbols, only string literals. (Notations building on Unotal, however, might interpret certain strings as “symbols”.)

Within the room literal "< alpha & beta gamma=delta >", the text "alpha", the text "beta", the text "gamma", and the text "delta" at first are all string literals. Thus, this room might also be written with bracketed string literals using the room literal "< [alpha] & [beta] [gamma] = [delta] >".

The string literal "[beta]" is interpret as a type of the room because of the ampersand "&" preceding it and the string literal "[gamma]" is interpret as the name of a name-value-assignment because of the equals-symbol "=" following it. Therefore, such names might contain all printable characters of the Unicode, not just certain “name characters”.

Character Set and Encoding

For Unotal, the character set Unicode is explicitly fixed, and all tools must support the encoding UTF-8.

Dotted pairs

In Unotal, there are no dotted pairs.

Sets

In Unotal, there exists a special fixed room type for sets, which is the type ":unotal:spray". (Types beginning with the text ":unotal" are reserved.)

Set-valued property in Unotal

< name = [Peter Miller] nationality =< &:unotal:spray DE US >>

By definition, the room "< &:unotal:spray DE US >" is equal to the room "< &:unotal:spray US DE >", or the room "< &:unotal:spray DE US US >", when it appears as the value (i.e., the right-hand side) of an assignment.

This is also intended to have the same meaning as assigning both elements to the same name.

Assignment of two values to a name

< name = [Peter Miller] 
  nationality = DE 
  nationality = US >

The order of assignments does not matter and repeating an assignment already given, does not change the room. Therefore, the next room is the same as the previous room.

Assignment of two values to a name, 1

< nationality = US 
  nationality = DE 
  nationality = US 
  name = [Peter Miller] >

Meaning of Properties

Unotal defines a standard interpretation for properties.

Room with a property in Unotal

< gamma = delta >

The standard interpretation says that the room is describing a descriptand, and that the relation named "gamma" is holding between the descriptand and the object "delta".

Interpretation of a property in Unotal

                  gamma >
descriptand --------------------- delta

Since the same relation can hold between a descriptand and several entities, Unotal allows multiple assignments with the same name within a room, as shown in the examples above.

Because of similar reasons a room might have multiple types. So an article of a department store might be a sound storage medium as well.

A room with multiple types

< &article                [article number]=[93728] price=< 12 &USD >
  &[sound storage medium] performer=[Jethro Tull] duration=< 2520 &seconds >>

The rooms also shows a type written at the end, as in "< 2520 &seconds >".

Some variants of S-expression indeed have means to write sets, e.g., as "(* set alpha beta gamma )".

Terminology

Regarding S-expressions, one speaks of a “list” containing “elements” (lists or atoms) and sometimes “slots”.

A list with an atom as its element and a slot named "beta"

( alpha beta: gamma )

Regarding Unotal, one speaks of a “room” containing “entries”, which are “rooms”, “strings”, “assignments”, and “specifications” (like type specifications).

A room with two entries: a string and an assignment

< alpha beta=gamma >

In Unotal, the notion “element” is used only for the elements of a set.

Credibility

Here “credibility” refers to questioning, to what extend the proponents of a notation are using this notation themselves.

It turns out that documentation for LISP, Scheme or S-expressions is rarely written using S-expressions themselves, but often with, e.g., LaTeX. This is not self-evident, when someone is suggesting to use S-expression for text markup, e.g., instead of XML.

The Specification of Unotal is written in Unotal :

Specification of the Unotal -Syntax written in Unotal :: http://www.purl.org/stefan_ram/unotal/unotal.uno
Translation of the above to other notations:: http://www.purl.org/stefan_ram/html/unotal.html; http://www.purl.org/stefan_ram/ascii/unotal.txt