Sometimes, in describing the syntax, EBNF-like notation is used, with the following meaning:

To keep this chapter as readable as possible, we have chosen to omit some details that are irrelevant for practically all Ampersand modelers. In the very rare case that these technicalities are of interest, the reader could have a look in the sourcecode of the parser, where all EBNF statements are fully detailed in comments.

Purpose:

A concept statement defines a concept in natural language. A concept is a name for similar things. For example: Peter, John, and Barack are things you might want to call Person, whereas 45-NP-88 and KD-686-D could be instances of the concept LicensePlate.

Syntax:

CONCEPT <Uppercase identifier>
MEANING  {+ <Text> +}

Semantics

This statement means that there exists a concept called <upper case identifier> in the current context.

• <upper case identifier> specifies the name of the concept. It starts with an upper case character and may subsequently have any combination of upper case (ABCDEFGHIJKLMNOPQRSTUVWXYZ), lower case (abcdefghijklmnopqrstuvwxyz), digits (0123456789) and underscore (_).

• <String> defines the concept. Please describe in natural language the conditions that make an atom belong to this concept. Your definition is used by the documentation generator, which expects it to be a grammatically correct and complete sentence.

Examples

CONCEPT Person MEANING {+ A person is a human creature. +}

CONCEPT Organization MEANING
{+ An organization is a collection of persons that work together
   to achieve specific objectives.
+}

CONCEPT Criterion
MEANING
{+ A criterion is a standard on which a judgment or decision may be based.
   [Merriam-Webster]
+}

Miscellaneous

• The name of a concept starts with an uppercase character.

• A concept should be used for immutable concepts. E.g. use a concept Person to express that a person will always be a person and will not change in, let us say, a table. However, don't use Employee, because termination of an employee's contract causes a person to be an employee no longer. So employees are not immutable. To be an employee is a dynamic property, so model it as a relation.

• The description will be printed in the functional specification, so please check that your definition is a complete sentence.

• Concepts need not be defined. If you use a concept without a definition, Ampersand makes it for you.

Markup

For the purpose of documentation, you may state the language in which the meaning is written. You may also state in which markup you have written your meaning. Examples:

CONCEPT Person MEANING IN ENGLISH {+ A person is a human creature. +}

If you specify the language, Ampersand can restrict the documentation for the language you choose. Currently, you can only choose DUTCH or ENGLISH. The default language is English

CONCEPT Organization MEANING MARKDOWN
{+ An organization is a **collection of persons** that work together
   to achieve specific objectives.
+}

By specifying a markup language, Ampersand interprets the text as specified. If you do not specify the markup language, your text is interpreted as restructured text. The available markup languages are LATEX, MARKDOWN, HTML, and REST. The default markup language is REStructured Text (REST).

CONCEPT Criterion
MEANING IN ENGLISH LATEX
{+ A criterion is a standard on which a judgment or decision may be based.
   \cite{Merriam-Webster}
+}

Let us introduce some language to talk about truth. Consider a fact "Joe Smith lives in New York." from an Ampersand perspective. In Ampersand, we can analyse this as follows:

• Let Person and City be ****

• Let "Joe Smith" be an of the concept Person and "New York" an atom of the concept City.

• Let us use the livesIn[Person*City] to contain our fact.

• livesIn is the relation name and [Person*City] is the signature of this relation.

• Person is the source of this relation and City is the target.

• If the pair ("Joe Smith","New York") is an element of this relation, Ampersand considers the statement "Joe Smith" livesIn "New York" to be true. So all pairs in a relation represent facts, i.e. true statements.

Language that makes sense to the business

Ampersand takes a pragmatic stance on truth: You model only things that make sense to the business. This illustrates the distinction between sensible and senseless statements. A sensible statement (we say: "It makes sense.") is a statement that can be true or false. Sentences that are not sensible (we can say: it is non-sense) are to be avoided. The Ampersand type system helps you to make sensible statements only.

Truth in context

Truth always has context. If we say "Jack was married to Jackie", this statement is true in a where "Jack" refers to the 35th president of the United States, John F. Kennedy. However, this statement is not true in a context where there is no Jack. And in a context where marriage doesn't exist, this statement makes no sense.

Watch to learn how we use the words atom, concept, and relation. Below is a list of other words with a specific meaning in Ampersand.

Syntactic definitions are given where the underlying notions (e.g. rule, relation, pattern, etc.) are discussed. The metasyntax is singled out . Because are defined in relation algebra, their semantics are explained in various ways to suit the background of each individual reader. Terms are the only algebraically defined things.

This section is organized by discussing each notion in isolation. Hyperlinks are added in the text to let the reader navigate on her own. The text is suitable for reference purposes, so there is no preferred order in reading.

Semantics

Most things in your model are in it for a reason. To document these, you should use the PURPOSE statement.

Syntax

PURPOSE <type of thing> <name> <language>? <markup>?

{+ <anything> +}

Where <type of thing> and <name> are the type and name of the thing that is refered to. This could be one of: CONCEPT, RELATION, RULE, IDENT, VIEW, PATTERN, INTERFACE, CONTEXT

The optional and can be used to override the settings for language and markup. If omitted, these are inherited from the pattern of context where the PURPOSE statement is specified in.

Examples:

PURPOSE CONCEPT Person {+The concept Person keeps all personal data together.+}

PURPOSE RELATION accountOwner
{+ The system shall register all accounts to an owner,
   so accounts with the same owner are linked in this way.
+}

When defining the purpose of a relation, make sure that Ampersand can identify the relation unambiguously. If you have multiple relations accountOwner, add the signature to disambiguate it. For instance:

PURPOSE RELATION accountOwner[Account*Owner]
{+ The system shall register all accounts to an owner,
   so accounts with the same owner are linked in this way.
+}

Markup

For the purpose of documentation, you may state the language in which you write a purpose. You may also state in which markup language you use. Examples:

PURPOSE CONCEPT Person IN ENGLISH {+ The concept PERSON keeps all personal data together, which we need to comply with the GDPR.  +}

If you specify the language, Ampersand can restrict the documentation for the language you choose. Currently, you can only choose DUTCH or ENGLISH. The default language is English.

PURPOSE RELATION accountOwner LATEX
{+ The system {\em shall} register all accounts to an owner, so accounts with the same owner are linked in this way.
+}

By specifying a markup language, Ampersand interprets the text as specified. If you do not specify the markup language, your text is interpreted as REStructured Text (REST). The available markup languages are LATEX, MARKDOWN, HTML, and REST.

PURPOSE RULE "Check Digit Character"
IN ENGLISH MARKDOWN
{+ This rule enforces the use of a check digit character
   as described in [ISO 7064](en.wikipedia.org/wiki/ISO/IEC_7064).
   This is applicatble to IBAN bank account numbers.
+}

A meaning is optional and is characterized by the reserved word MEANING. It specifies the meaning of a concept, a relation, or a rule in natural language. The meaning is used to generate documentation and is printed in the functional specification. A <meaning> can be any text, starting with {+ and ending with +} e.g.

MEANING
{+ This is an example that is
   spread over multiple lines. 
+}

The optional <language> is specified as

• IN ENGLISH or

• IN DUTCH.

Example :

MEANING IN DUTCH {+ Dit is een voorbeeld in een (1) regel.+}

This is a way to override the default language (which is English).

Sometimes you need formatting in the meaning, such as dotted lists, italics, or mathematical symbols. For this purpose you have a choice in which syntax you specify the meaning. The optional <markup> is one of :

• REST (Restructured text. This is the default)

• HTML

• LATEX

• MARKDOWN

Example :

MEANING LATEX {+This is a {\em mathematical} formula $\frac{3}{x+7}$.+}

Ampersand uses Pandoc to offer a choice for your markup. See pandoc.org for details.

Purpose

To represent a real-world thing in an information system context, you use atoms.

Description

An atom refers to an individual object in the real world, such as the student called "Caroline". But what if there are three different Carolines? What does it mean to say: "Caroline has passed the exam for Spanish Medieval Literature."? This sentence might be true for one Caroline, but false for the others. Clearly, to avoid ambiguous sentences, an atom must identify exactly one real-world object, no more, no less. Or rather, it suffices that the atom identifies one object within the context in which we are working: if the context is a group with only one Caroline, there will be no ambiguity. Similarly, ABBA is unique among all pop groups in the world; there ought to be only one building permit with number 5678; etcetera.

Examples

"Caroline", 5, 1917-11-07 48, 10.34, 2., .001, -125, +5.33333, 2.5E2, 5E-3

Syntax and meaning

The syntax of atoms is largely taken from ISO8601 and corresponds to the syntax of SQL and Excel. (Acknowledgement: the following text was adapted from Wikipedia)

• Date and time values are ordered from the largest to smallest unit of time: year, month (or week), day, hour, minute, second, and fraction of second. The lexicographical order of the representation thus corresponds to chronological order, except for date representations involving negative years. This allows dates to be naturally sorting|sorted by, for example, file systems.

• Each date and time value has a fixed number of digits that must be padded with leading zeros.

• Representations can be done in one of two formats - a basic format with a minimal number of separators or an extended format with separators added to enhance human readability. The separator used between date values (year, month, week, and day) is the hyphen, while the colon is used as the separator between time values (hours, minutes, and seconds).

• For reduced accuracy, any number of values may be dropped from any of the date and time representations, but in the order from the least to the most significant. For example, "2004-05" is a valid ISO 8601 date, which indicates May (the fifth month) 2004. This format will never represent the 5th day of an unspecified month in 2004, nor will it represent a time-span extending from 2004 into 2005.

• If necessary for a particular application, the standard supports the addition of a decimal fraction to the smallest time value in the representation.

Atomic types

Atoms are represented in an SQL database. For this purpose, every atom has a type (sometimes called the technical type). The representation in SQL is given in the following table.

The last column, eq, tells whether Ampersand implements equality on these types. If equality is not defined, the operators \/, /\, -, \, /, ;, and <> cannot be used.

The distinction between closed and open types is relevant in the following situations:

• The complement of a relation, -r[A*B], is defined only if both A and B are closed.

• The full relation, V[A*B] is defined only if both A and B are closed.

• A service INTERFACE X : e requires that the target of e is closed.

Violations are currently signaled at runtime, but future versions of Ampersand will signal these violations at compile time.

Miscellaneous

• Every atom whose atomic type is marked "yes" in the column "eq" can be compared for equality. For all other atoms, equality is not defined.

• The following Ampersand statement declares the atomic type of a concept:

  Copy

  REPRESENT <Concepts> TYPE <Atomic type>

  e.g.

  Copy

  REPRESENT LegalEntity TYPE ALPHANUMERIC

  If Person and Company are both LegalEntity, then both of them will be implicitly declared as ALPHANUMERIC too.

Purpose

A relation statement says that a relation exists. It introduces (defines, declares) the relation in the context that uses the relation statement.

A population statement specifies which pairs (of atoms) are in a relation.

Description

A relation is a set that contains pairs of atoms. Over time, pairs can be inserted into or deleted from a relation, for example by a user typing data into an Ampersand application. So the content of a relation is changing over time.

When discussing relations, an arbitrary relation is referred to as $r$, $s$, or $t$. To say that a pair $(a,b)$ belongs to a relation $r$, we write $a\ r\ b$ or alternatively $(a,b)\in r$.

Examples

RELATION soldBy[Order*Person]

RELATION contract[Order*ContractID] [UNI,TOT]
PRAGMA "Order " " has contract " " as its legal basis."
MEANING
{+ Every Order has a unique ContractID which specifies the legal basis
   for that particular order.
+}

In this example:

• contract is the name of the relation,

• Order is the source concept of the relation,

• ContractID is the target concept of this relation, and

• UNI and TOT are constraints of this relation.

Syntax and meaning

Each relation used in Ampersand has to be declared. This means that the developer tells the system that this particular relation exists. A relation declaration can have one of the following formats:

RELATION <lower case identifier>
         '[' <upper case identifier> '*' <upper case identifier> ']'
         <properties>? <pragma>? <meaning>?

In the declaration RELATION owner[Person*Building], owner is the name and [Person*Building] is the type of the relation. Relation names start with a lower case character, to avoid confusion with concept names. The signature of this relation is owner[Person*Building]. The signature identifies the relation within its context. The left hand concept, Person, is called the source of the relation and the right concept, Building, is called the target.

All three formats define a relation by its name, its source concept and its target concept. By convention, the name of a relation is a single word that starts with a lower case letter. The source and target concepts start with an upper case letter. This convention avoids confusion between concepts and relations.

A relation statement means that there exists a relation in the current context with the specified name, source concept and target concept.

A relation statement may occur anywhere inside a context, both inside and outside a pattern.

The optional <properties> and <pragma>-parts are discussed in the sequel. The <meaning>-part is discussed here.

The name, source concept and target concept together identify a relation uniquely within its context. As a consequence, the name of a relation does not have to be unique. E.g. name[Book*Name] can be specified in the same context as name[Person*Name]. Because they have different source concepts, these are different relations.

Properties

The <properties>-part is meant for writing multiplicity constraints in a comma separated list between square brackets '[' and ']'. E.g. [UNI,TOT] . The following properties can be specified on any relation r[A*B]

There are additional relations that can be specified on endo relations. An endo relation is a relation where the source and target concepts are equal. r[A*A].

Let's assume that we want to express that any person can live in one city only. So under this constraint "Joe Smith lives in New York" and "Joe Smith lives in Denver" cannot both be true at the same time.

In relation algebra, we say that the relation is univalent, which means that every atom in the source concept can only be paired with a single atom in the target concept. This is modeled as

RELATION lives[Person*City][UNI]
MEANING "A person can live in one city only."

PRAGMA

A pragma is optional and is characterized by the reserved word PRAGMA. The PRAGMA is followed by two or three strings. It is used to construct sentences in natural language, using pairs from the actual population of a relation. A pragma specifies how we speak (in natural language) about any pair in the relation. Ampersand also uses pragmas to generate examples in the functional specification. Example of a pragma with three strings:

PRAGMA "Student " " flies the flag of " " in top."

To use this pragma on the pair (John,Amsterdam) results in the sentence "Student John flies the flag of Amsterdam in top.". The two atoms are fitted in between the three strings. A pragma with two strings is identical to a pragma in which the third string is empty.

(The PRAGMA keyword will become obsolete in a future version of Ampersand. It will be replaced by the VIEW-statement which offers more flexibility in composing sentences.)

Example:

RELATION accepted[Provider * Order] [INJ] PRAGMA "Provider " " has accepted order "

The PRAGMA tells us that it makes sense to utter the phrase "Provider Mario's Pizza's has accepted order 12345."

MEANING

For a full discussion of meaning, we refer to this page.

Miscellaneous

Purpose

A classify statement is also called a specialization. It specifies that atoms of one concept are atoms of another concept as well. You can use it to buils classifications like Linnaeus did.

Syntax and meaning

CLASSIFY <upper case identifier> ISA <upper case identifier>

In a specialization, e.g. CLASSIFY Sedan ISA Car, we call the first concept (Sedan) the specific concept and the second (Car) the generic concept. The meaning of a specialization is that every atom from the specific concept is an atom from the generic concept as well. So every (atom that is a) Sedan is a Car as well.

So in general: CLASSIFY $A$ ISA $B$ means: $\forall a: a\in A\Rightarrow a\in B$.

Examples

CLASSIFY Monkey ISA Mammal

CLASSIFY Sedan ISA Car

To save some writing, you may specify

CLASSIFY Monkey, Cow, Human ISA Mammal

This means exactly the same as

CLASSIFY Monkey ISA Mammal
CLASSIFY Cow ISA Mammal
CLASSIFY Human ISA Mammal

Best practice

A specialization is a static relationship. If you want to say that a student is a person, please consider whether you want this to be static. If a person can enroll to become a student, or graduate or drop out to become non-student again, the dynamics of that cannot be captured in a specialization. Use a relationship instead to model the state of being a student. E.g. RELATION student[Person*Enrollment]

By adding and removing pairs to that relation, it continuously reflects which persons are a student.

Purpose

The purpose of a rule is to constrain data. Refer to the in the tutorial for examples and a practice-oriented explanation.

A rule statement defines something that should be true. It does not define the enforcement.

Syntax of rules

A <rule> has the following syntax:

Terms and operators are discussed in :

Syntax of labels

A <label> is optional. It can be a single word or a string (enclosed by double brackets) followed by a colon (:).

MEANING*

The meaning of a rule can be written in natural language in the Meaning part of the RULE statement. It is a good habit to specify the meaning! The meaning will be printed in the functional specification. The meaning is optional.

Syntax

The <text> part is where the the meaning is written down. It is enclosed by {+ and +} and may be spread across multiple lines. If you need specific markup, turn to for a full explanation.

MESSAGE*

Messages may be defined to give feedback whenever the rule is violated. The message is a string. When you run your prototype this is printed in a red box when the rule is violated. You will see the violations by clicking on that message.

VIOLATION

A violation message can be constructed so that it gives specific information about the violating atoms:

Every segment must be of one of the following forms:

• TXT String

• SRC Expression

• TGT Expression

A rule is violated by a pair of atoms (source, target). The source atom is the root of the violation message. In the message, the target atoms are printed. With the Identity relation, the root atom itself can be printed. You can use an expression to print other atoms. Below two examples reporting a violation of the rule that each project must have a project leader. The first prints the project's ID, the second the project's name using the relation projectName:

VIOLATION ( TXT "Project ", SRC I, TXT " does not have a projectleader")

VIOLATION ( TXT "Project ", SRC projectName, TXT " does not have a projectleader")

ROLE MAINTAINS

By default, rules are invariant rules. By preceding the rule statement with a role specification for this rule, the rule becomes a process rule.

tbd

Relations

When a relation is used in a term, it stands for all pairs it contains at the moment it is evaluated. Those pairs (also referred to as the contents or population of the relation) can change over time as users add or delete pairs from it.

When a relation is used in a term, we can just use its name if that is unambiguous. For instance the name owner refers to RELATION owner[Person*Building] if that is the only relation the ampersand-compiler can link it to. In some cases, however the name alone is ambiguous. For example if there are two relations with the same name and different signatures. In such cases Ampersand will try to infer the type from the context. That however does not always succeed. In such cases, Ampersand generates an error message that asks you to remove the ambiguity by adding the correct type.

If a pair $(a,b)$ is an element of a relation $r$, we write $a\ r\ b$. Alternatively we may write $(a,b)\in r$ , since we know that $r$ is a set.

Identity

For every concept $C$, the term $I_{[C]}$ exists. It refers to the identity relation. It means that for every $a\in C$ and $b\in C$ we have:

The type of $I_{[C]}$ is $[C*C]$. In Ampersand code you write I[C].

Complete relation

For every pair of concepts $A$ and $B$ the term $V_{[A*B]}$ refers to the complete relation. For every $a\in A$ and $b\in B$ we have:

The type of $V_{[A*B]}$ is $[A*B]$. In Ampersand code you write V[A*B].

Other explanation

Would you like a different explanation of the primitive terms? This page explains the primitive terms in terms of set theory. Click here for the explanation of primitive terms in natural language.

The notation $a\ r\ b$ means that the pair (a,b) is in relation $r$. This page defines when pair (a,b) is in relation $r ∩ s$ (the intersection of $r$ and $s$), $r ∪ s$ (the union of $r$ and $s$), $r-s$ (the difference of $r$ and $s$).

• intersection : $a\ (r ∩ s)\ b\ \Leftrightarrow\ a\ r\ b\ ∧\ a\ s\ b$ . In other words: if the pair $(a,b)$ is both in relation $r$ and $s$, then it is in the intersection of $r$ and $s$.

• union : $a\ (r ∪ s)\ b\ \Leftrightarrow\ a\ r\ b\ \vee\ a\ s\ b$ . In words: if the pair $(a,b)$ is in the relation $r$ or in $s$, then it is in the union of $r$ and $s$.

• difference : $a\ (r-s)\ b\ \Leftrightarrow\ a\ r\ b\ ∧\ \neg(a\ s\ b)$. In other words, the term $r-s$ contains all pairs from $r$ that are not in $s$.

The complement (or negation) of a relation $r_{[A x B]}$ is defined by means of the difference operator:

• complement : If $r$ is defined as $r_{A\times B}$, then $\overline{r}$ is the set of all tuples in $A\times B$ (the Cartesian product) that are not contained in $r$. So $\overline{r} = V_{[A\times B]} - r$

Note that the complement is defined in terms of $A$ and $B$. So, two relations with an identical population yet a different type may have different complements.

How to type boolean operators in your script

This page shows how you can type boolean (and other) operators in your Ampersand script.

Other explanation

Would you like a different explanation of the boolean operators? This page explains the boolean operators in terms of set theory.

Purpose

The purpose of a term is to compute pairs that constitute a relation. We use operators to assemble terms from smaller terms, to express in formal language precisely what is meant in the natural language of the business. The smallest term is a single relation.

We noticed that our readers have different backgrounds. They have different preferences about the way we explain the operators in Ampersand. Some prefer an explanation in logic, others in algebra, and still others in set theory. So we decided to explain the operators in many different ways simultaneously, hoping that one of them suits your preference.

Description

A term is a combination of operators and relations. Its meaning is a set of pairs, which is in fact a newly created relation. The word "expression" may be used as a synonym for "term" in the context of Ampersand.

Examples

owner

r;s~

I /\ goalkeeper;goalkeeper~

destination;"Algarve" |- spoken;"Portugese"

Syntax

Every term is built out of relations, which are combined by operators. An term has one of the following 8 syntactic structures

<Term> <BinaryOperator> <Term>
<UnaryOpPre> <Term>
<Term> <UnaryOpPost>
<RelationRef> <type>?
I <type>?
V <type>?
<atom>
( <Term> )

Operators

The operators come in families. We advise novices to study only the rule operators, boolean operators and relational operators. There is a wealth of things you can express with just these operators. The residual operators seem harder to learn and the Kleene operators are not fully implemented yet. You can click the hyperlink to navigate to the semantics of each family.

Brackets

Operators with different binding power may be used in the same term without brackets, because the binding power tells how it is interpreted. For example, $r\cap s;t$ means $r\cap(s;t)$ because $;$ has a higher binding power than $\cap$.

Operators with the same binding power must be used unambiguously. For example: $r\cap(s-t)$ means something different than $(r\cap s)-t$. In such cases Ampersand insists on the use of brackets, so readers without knowledge of the binding powers of the operators can read a term unambiguously.

Repeated uses of an associative operator does not require brackets. So $r\cap s \cap t$ is allowed because $\cap$ is associative.

Notation on the keyboard

When coding in Ampersand, these operators are typed with characters on the keyboard. The following table shows the operators in math and their equivalent in code:

Purpose of relational operators

To say things such as "the name of the owner", we want to string together multiple relations (viz. name and owner). Relational operators allow us to make such statements.

Converse

A relation can be altered by swapping the elements of every pair in the relation. Mathematically, $(a, b)$ is a different from $(b,a)$. This operation is called the converse operator. It produces a new relation from an existing one. It is denoted by writing \smallsmile\ (pronounced 'wok' or ’flip’) after the relation name. This is how converse is defined:

If $r$ has type$[A\times B]$, then r\smallsmile\ has type $[B\times A]$.

Composition

The composition operator is denoted by a semicolon $;$ between two terms. It is pronounced as 'composed with'. Let us take a look at $r$ composed with $s$. Let $r_{[A\times B]}$ and $s_{[B\times C]}$ be two relations, with the target of r being the same as the source of s. Then the composition of $r$ and $s$ is defined by:

If $r$ has type$[A\times B]$and $s$has type$[B\times C]$, then $r;s$ has type $[A\times C]$.

How to type boolean operators in your script

This page shows how you can type boolean (and other) operators in your Ampersand script.

Other explanation

Would you like a different explanation of the relational operators? This page explains the relational operators in terms of set theory. This page explains them in natural language. Click here for some algebraic rules about relational operators.

We present the semantics of terms in 5 different (but equivalent) ways: one explanation in terms of logic, one in set theory, one in terms of axioms (algebraically), one in natural language, and one visual explanation. These ways are equivalent, so you can interpret a term in any of the presented ways. Any way will do; take your pick!

(the pages without hyperlinks are yet to be made).

Purpose of relational operators

To say things such as "the name of the owner", we want to string together multiple relations (viz. name and owner). Relational operators allow us to make such statements.

Meaning

The meaning of relational operators and is best explained by means of examples.

Assume we have a relation, label[Contract*Colour], which contains the colour of labels on contracts. A fact "1834" label "blue" means that contract 1834 has a blue label.

Also assume another relation stored[Contract*Location], which gives the location where a contract is stored. Fact "1834" store "cabinet 42" means that contract 1834 is stored in cabinet 42.

Converse

A relation can be altered by swapping the elements of every pair in the relation. Mathematically, is a different from . In natural language, however, the meaning does not change. So if"1834" label "blue" means that contract 1834 has a blue label, "blue" label~ "1834" also means that contract 1834 has a blue label.

• The sentence: "All contracts with a blue label are stored in cabinet 42." is represented as "blue" (label\stored) "cabinet 42". Literally it says: For every contract, if it has a blue label, then it is stored in cabinet 42.

Composition

The sentence "A contract with a blue label is stored in cabinet 42." can be represented as "blue" (label~;stored) "cabinet 42". Literally it says: There is a contract that has a blue label and is stored in cabinet 42.

Natural language templates

The natural language translation for b r~ ais the same as language translation for a r b.

Other explanation

Relations

When a is used in a term, it stands for a set of facts that are assumed true on the current time in the current context. Those facts (also referred to as the contents or the population of the relation) can change over time as users add or delete facts from it.

When a relation is used in a term, we can simply use its name if that is unambiguous. For instance the name owner refers to RELATION owner[Person*Building] if that is the only relation the ampersand-compiler can link it to. In some cases, however the name alone is ambiguous. For example if there are two relations with the same name and different signatures. In such cases Ampersand will try to infer the type from the context. That however does not always succeed. In such cases, Ampersand generates an error message that asks you to remove the ambiguity by adding the correct type.

If a pair is an element of a relation , we write to denote the fact. It means that we consider to be true (within the current context).

Identity

Every atom in a concept identifies itself. If for example concept "Person" contains atoms {"Ann", "Bob", "Cecil"}, "Ann" identifies "Ann", "Bob" identifies "Bob", and "Cecil" identifies "Cecil". This makes "Ann" and "Bob" different atoms (unequal).

Other explanation

Would you like a different explanation of the primitive terms? explains the primitive terms in logic. for the explanation in set theory.

are used when "" is involved.

• right residual : . In other words: is in the right residual of and means that for every , pair is in relation implies that pair is in .

• left residual : . In words: is in the left residual of and

  means that for every pair is in relation implies that pair is in .

• diamond: . In words: For every , both and are true or both are false.

How to type boolean operators in your script

shows how you can type boolean (and other) operators in your Ampersand script.

Other explanation

Would you like a different explanation of the residual operators? explains them in natural language. for visualized examples about residual operators.

Purpose of boolean operators

To say things such as pair ("peter","macbook") is either in relation ownsa or wantsa, requires us to use boolean operators , , and .

Meaning

Let us explain the meaning of relational operators , , and by means of examples.

Assume we have a relation, ownsa[Person*LaptopType], which contains the persons who own a particular type of laptop. A fact "peter" ownsa "macbook" means that Peter owns a MacBook.

Also assume another relation wantsa[Person*LaptopType], which contains the persons who want a particular type of laptop. A fact "peter" wantsa "macbook" means that Peter wants a MacBook.

Union

The sentence: "Peter owns a MacBook or Peter wants a MacBook." is represented as "peter" (ownsa wantsa) "macbook".

Intersection

The sentence: "Peter owns a MacBook and Peter wants a MacBook." is represented as "peter" (label colour) "macbook".

Difference

The sentence: "Peter owns a MacBook and Peter does not want a MacBook." is represented as "peter" (label colour) "macbook".

Natural language templates

Other explanation

This chapter discusses the and the in the following sections.

The meaning of residual operators , , and is best explained by means of examples.

Assume we have a relation, label[Contract*Colour], which contains the colour of labels on contracts. A fact "1834" label "blue" means that contract 1834 has a blue label.

Also assume another relation stored[Contract*Location], which gives the location where a contract is stored. Fact "1834" store "cabinet 42" means that contract 1834 is stored in cabinet 42.

• The sentence: "All contracts with a blue label are stored in cabinet 42." is represented as "blue" (label\stored) "cabinet 42". Literally it says: For every contract, if it has a blue label, then it is stored in cabinet 42.

• The sentence: "All contracts that are stored in cabinet 42 have a blue label." is represented as "blue" (label~/stored~) "cabinet 42". Literally it says: For every contract, if it is stored in cabinet 42, then it has a blue label.

• The sentence: "All blue labeled contracts and no others are stored in cabinet 42." is represented as "blue" (label~<>stored) "cabinet 42". Literally it says: For every contract, if it has a blue label, then it is stored in cabinet 42 and if it is stored in cabinet 42, then it has a blue label.

Natural language templates

There is a pattern to this. A computer can generate a literal translation from the formula to natural language. However, that translation looks clumsy, verbose and elaborate. It is up to you to turn that in normal language. For examples . The systematic translation is given in the following table:

Other explanation

Would you like a different explanation of the residual operators? explains them in logic. for visualized examples about residual operators.

A relation is by definition a subset of the Cartesian Product of the source and target sets. So, if two different relations r and s are defined on the same source A and target B, then the ordinary set operators can be applied to produce a new relation.

• intersection : is the set that contains the elements that are contained in relation as well as in , or

• union : is the set that contains all elements that are contained either in relation or in , or

• difference : is the set that contains the elements of relation that are not contained in , or

The complement (or negation) of a relation is defined by means of the difference operator:

• complement : If is defined as , then is the set of all tuples in (the Cartesian product) that are not contained in . So

Note that the complement is defined in terms of and . So, two relations with the identical population yet a different type may have different complements.

How to type boolean operators in your script

shows how you can write these things in your Ampersand script.

Other explanation

Would you like a different explanation of the boolean operators? explains the boolean operators in logic.

Relations

When a is used in a term, it stands for the set of pairs it contains at the moment it is evaluated. That set (also referred to as the contents of the relation) can change over time as users add or delete pairs from it.

When a relation is used in a term, we can simply use its name if that is unambiguous. For instance the name owner refers to RELATION owner[Person*Building] if that is the only relation the ampersand-compiler can link it to. In some cases, however the name alone is ambiguous. For example if there are two relations with the same name and different signatures. In such cases Ampersand will try to infer the type from the context. That however does not always succeed. In such cases, Ampersand generates an error message that asks you to remove the ambiguity by adding the correct type.

If a pair is an element of a relation , we write . Alternatively we may write .

Identity

For every concept , the term represents the identity relation. It is defined by:

The type of is . In Ampersand code you write I[C].

Complete relation

For every pair of concepts and the term represents the complete relation. It is defined by:

Other explanation

Purpose of relational operators

To say things such as "the name of the owner", we want to string together multiple relations (viz. name and owner). Relational operators allow us to make such statements.

Converse

A relation that contains pairs of the form can be altered by swapping the elements of every pair in the relation. Mathematically, is a different from . This operation is called the converse operator. It produces a new relation from an existing one. It is denoted by writing (pronounced 'wok' or ’flip’) after the relation name. This is how converse is defined:

If has type , then has type .

Composition

The composition operator is denoted by a semicolon ; between two terms. It is pronounced as 'composed with', in this case: composed with .

The composition operation is defined as follows: Let and be two relations, with the target of r being the same as the source of s. Then the composition of and , is a relation with signature

Other explanation

Would you like a different explanation of the relational operators? explains the relational operators in logic. explains them in natural language. for some algebraic rules about relational operators.

For a visual presentation of the semantics of terms, we use Venn-diagrams.

The boolean operators of Ampersand behave as one would expect in any boolean algebra. Union ($\cup$) and intersection ($\cap$) are both idempotent, commutative, and associative operators. In Ampersand we use a binary difference operator over with the usual semantics: $(r-s)\cup(r\cap s) = r$. The (more customary) complement operator is a partial function, because Ampersand supports heterogeneous relation algebra.

Union

The operator $\cup$ (union) satisfies the following axioms:

1. (commutativity of $\cup$) $r\cup s\ =\ s\cup r$

2. (associativity of $\cup$) $r\cup (s\cup t)\ =\ (r\cup s)\cup t$

3. (idempotence of $\cup$) $r\cup r\ =\ r$

Difference

The difference $r-s$ is the smallest relation $t$ that satisfies $r\ \subseteq\ s\cup t$. Smallest means: If there is a $t'$ for which $s\cup t'=r$, this implies that $t\cup t'=t'$.

Intersection

The intersection $\cap$ is defined as: $r \cap s = r-(r-s)$

Complement

The complement operator is defined as $\overline{t} = V_{[A\times B]} - t$. The type $[A\times B]$ comes from the term(s) in which $t$ is embedded. If that type does not exist or if it is ambiguous, Ampersand will refuse to compile with an appropriate error message.

How to type boolean operators in your script

This page shows how you can write these things in your Ampersand script.

Other explanation

Purpose of relational operators

To say things such as "the name of the owner", we want to string together multiple relations (viz. name and owner). Relational operators allow us to make such statements.

There are two relational operators: the converse ($\smallsmile$) and the composition (semicolon $;$ ). This page discusses the most important laws about these operators.

Converse

There are two things you should know about the converse operator. The first is that the converse of the converse gives you the relation itself, whatever that relation may be:

The second thing you should know is that arguments switch places if the converse is brought outside (or inside) brackets

Composition

The composition operator is denoted by a semicolon (;) between two terms. It is pronounced as 'composed with', in this case: $r$ composed with $s$.

Composition is associative, which means:

The meaning stays the same, no matter how you place the brackets. So Ampersand lets you omit brackets entirely. You may write $r;s;t$ instead of $r;(s;t)$ or $(r;s);t$.

Composition has a left and a right identity. Let $r_{[A\times B]}$ be a relation, then

How to type relational operators in your script

This page shows how you can write these things in your Ampersand script.

Other explanation

Would you like a different explanation of the semantics of the relational operators? Click here for an explanation in sets. This page explains them in natural language. This page explains the relational operators in logic.

Consider two relations: traveler[Trip*Person] and dest[Trip*Destination]. The first relation tells which persons have traveled on which trip. The diagram shows this as red dashed lines. The second relation links trips to destinations. It is depicted by dotted blue lines in the diagram.

Each pair (fact) in the diagram can be written as a fact in two ways, using the converse operator:

From the diagram, we assume that each pair represents a true statement (i.e. a fact). The statements are given both formally and in natural language. The elaborate version is a literate translation of the semantics in logic. The ordinary version tells the same in a more human sounding manner.

Consider two relations: traveler[Trip*Person] and dest[Trip*Destination]. The first relation tells which persons have traveled on which trip. The diagram shows this as red dashed lines. The second relation links trips to destinations. It is depicted by dotted blue lines in the diagram.

From this diagram, we can tell which statements are true (i.e. facts). The statements are given both formally and in natural language. The elaborate version is a literate translation of the semantics in logic. The ordinary version tells the same in a more human sounding manner.

The following statements do NOT follow from the population shown in the diagram:

Other explanation

Would you like a different explanation of the residual operators? This page explains them in natural language. Click here for the explanation of residual operators in logic.

Consider two relations: authorized[Account*Person] and beneficiary[Account*Person]. The first relation tells which persons are authorized to which accounts. The diagram shows this as red dashed lines. The second relation tells which persons stand to benefit from which accounts.. It is depicted by dotted blue lines in the diagram.

This diagram gives an example population of the relations authorized[Account*Person] and beneficiary[Account*Person]. Bob is authorized for account DE9382991 and Ann is authorized for account RS746620. Carl stands to benefit from account NL19RABO03992844 and Ann stands to benefit from account RS746620. Formally, we say:

By combining the relations authorized and beneficiary, we can derive the following true statements.

A different way to state the same is:

Other explanations

Would you like a different explanation of the boolean operators? This page explains them in set theory. Click here for the semantics of the boolean operators in algebra. Here you get their definitions in logic.