Chunks and Rules

This specification defines a cognitive database model based on graphs, rules that operate on them in conjunction with highly scalable graph algorithms, suitable for handling big data, and a format to serialize graphs. The model is designed with the aim of facilitating machine learning for vocabularies and rules, and inspired by advances in the cognitive sciences on the organisation of the mammalian brain.

Chunks and graphs

A chunk is a named typed collection of [=properties=]. A [=chunk=] is used to model both declarative knowledge and procedural knowledge as a collection of basic familiar units that have been grouped together and stored in memory.

A [=chunk=] has a [=type=] and an optional [=identifier=].

dog dog1 {
  name "Fido"
  age 4
}

This [=chunk=] describes a dog named "Fido" that is 4 years old. The chunk [=type=] is dog. Its [=identifier=] is dog1 and uniquely identifies this chunk within the graph it is defined in. The chunk has two [=properties=]:

name whose value is the [=string literal=] "Fido"
age whose value is the [=number=] 4

Chunk type

A chunk type is a [=name=] that documents the nature of a chunk. The [=type=] is used to group and index chunks. [=Rules=] typically apply to chunks of a given [=type=].

person Dave {
  knows Francois
}

As a special case, the [=type=] may be formed by a single asterisk (*), which is used to describe a [=condition=] or [=action=] that matches any chunk [=type=].

Chunk identifier

The chunk identifier is a [=name=] that uniquely identifies a chunk within the graph it is defined in.

The chunk [=identifier=] is optional.

Chunk properties

A chunk property is a [=name=]/[=value=] pair that describes a chunk across the particular dimension identified by the property name.

A value is either an [=atomic value=] or an ordered list of [=atomic values=] (values are comma-separated in serialized form).

An atomic value is either:

a [=name=], which can for instance be used to reference other chunks
a [=number=]
a [=boolean=] (true or false)
a [=date=]
a [=string literal=]

A property [=value=] |a| equals property [=value=] |b| when the following algorithm returns true:

If |a| is the [=wild card operator=] *, return true.
If |b| is the [=wild card operator=] *, return true.
If |a| is the [=negation operator=] !, return false.
If |b| is the [=negation operator=] !, return false.
If |a| is a [=name=] that starts with the [=negation operator=] !, return false if !|a| [=equals=] |b|, true otherwise.
If |b| is a [=name=] that starts with the [=negation operator=] !, return false if |a| [=equals=] !|b|, true otherwise.
If |a| is a [=variable=] that is not yet [=bound=] to a value, return true.
If |b| is a [=variable=] that is not yet [=bound=] to a value, return true.
If |a| is a [=variable=] [=bound=] to a value |v|, return true if |v| [=equals=] |b|, false otherwise.
If |b| is a [=variable=] [=bound=] to a value |v|, return true if |a| [=equals=] |v|, false otherwise.
If |a| and |b| are identical [=atomic values=], return true.
If |a] and |b| are lists of [=atomic values=], both lists have the same length, and [=atomic values=] at the same position in |a| and |b| are [=equal=], return true.
Otherwise, return false.

Chunk context

A [=chunk=] may be scoped to a context, which identifies the specific situation under which the [=chunk=] should be considered to be true. This mechanism allows [=chunks=] to describe things that are only true in hypothetical situations.

[=Contexts=] can be used to express situations that involve the use of statements about statements, including beliefs, stories, reported speech, examples in lessons, abductive reasoning and even search query patterns. They are also useful for episodic memory when one wants to describe facts that are true in a given situation, for instance an even when a peson visited a restaurant for lunch, sat by the window, and had soup for starters followed by mushroom risotto for the main course. A sequence of episodes can then be modelled as relationships between contexts.

A [=chunk=] gets associated with a specific [=context=] through an [=@context=] [=property=].

A [=chunk=] that is not explicitly associated with a [=context=] (i.e. in the absence of an [=@context=] property) belongs to the default context.

Here is an example from John Sowa's Architectures for Intelligent Systems:

Tom believes that Mary wants to marry a sailor.

This example involves talking about a statement Mary wants to marry a sailor that is only known to be true according to Tom's belief. When represented as [=chunks=], the statement needs to be associated with a [=context=] that identifies Tom's belief, so that we cannot directly assert that the statement is true in general.

Similarly, the statement to marry a sailor is only known to be true according to Mary's desire. When represented as [=chunks=], the statement also needs to be associated with a [=context=] that identifies Mary's desire.

Here is one possible way to represent the overall statement with [=chunks=]:

believes {
  @subject tom
  proposition tom-belief-1
}
wants {
  @context tom-belief-1
  @subject mary
  situation mary-desire-1
}
married-to {
  @context mary-desire-1
  @subject mary
  @object s1
}
a s1 {
  @context mary-desire-1
  profession sailor
}

As illustrated in the previous example, [=contexts=] can be chained, e.g. to describe the beliefs of someone in a fictional story or movie, and to indicate when a context is part of several other contexts, thus creating a tree of [=contexts=].

Practically speaking, [=contexts=] make it possible to filter out non relevant [=chunks=] in [=conditions=] and [=actions=]. Two [=chunks=] may only [=match=] when they belong to the same context. For instance, a [=chunk=] that belongs to the context tom-belief-1 can only [=match=] [=chunks=] that also belong to that context, and de facto cannot match [=chunks=] that belong to the [=default context=]. In particular, a [=chunk=] that belongs to the [=default context=] can only [=match=] [=chunks=] that also belong to the [=default context=].

Links between chunks

In this document, a link is a directed and labeled connection between two [=chunks=]. A [=link=] is automatically created whenever a chunk property [=value=] is a [=name=] that references an existing chunk [=identifier=].

The subject of the [=link=] identifies the [=chunk=] at the origin of the connection. The object of the [=link=] identifies the [=chunk=] targeted by the connection. The label of the [=link=] is the property [=name=].

friend f34 {
  name Joan
}
friend f35 {
  name Jenny
  likes f34
}

The above definition creates a link between f35 and f34 with the relationship likes.

When a [=chunk=] links to another [=chunk=], this implicitly creates a third [=chunk=] whose [=type=] is the name of the [=property=] that creates the [=link=], and that has two [=properties=]:

@subject: references the [=subject=] of a [=link=]
@object: references the [=object=] of a [=link=]

animal dog {
  kindof mammal
}

The previous definition implicitly creates the following [=chunk=]:

kindof {
  @subject dog
  @object mammal
}

The grammar allows to express [=links=] in a compact format in a [=chunks document=], e.g.:

dog kindof mammal
cat kindof mammal

This is equivalent to:

kindof {
  @subject dog
  @object mammal
}
kindof {
  @subject cat
  @object mammal
}

Graph of chunks

A graph of chunks is simply a collection of [=chunks=]. The vertices of the graph are the [=chunks=]. The edges of the graph are the [=links=] between the chunks.

Since [=links=] are directed, a [=graph of chunks=] is a directed graph.

Rules and modules

Rules

A rule is a [=chunk=] whose [=type=] is rule and that has:

an @condition [=property=], whose value is a chunk [=identifier=] or a list thereof, and which is used to reference the rule's [=conditions=].
an @action [=property=], whose value is a chunk [=identifier=] or a list thereof, and which is used to reference the rule's [=actions=].

A [=rule=] represents a unit of procedural knowledge. Rules consist of [=conditions=] and [=actions=].

The following [=rule=] has one [=condition=] (that holds true when the goal [=module buffer=] contains a [=chunk=] whose [=type=] is remember), and two [=actions=] that clears the goal [=module buffer=] and that loads a [=chunk=] whose type is memory in the facts [=module=]:

rule r1 {
  @condition c1
  @action a1, a2
}

remember c1 {}
next a1 { @do clear }
memory a2 { @module facts }

The grammar allows to express [=rules=] in a compact format in a [=chunks document=]. For instance, the previous example may be written as:

remember {}
  => next { @do clear },
     memory { @module facts }

This compact format makes the link between [=conditions=] and [=actions=] more explicit and avoids the need to provide chunk [=identifiers=].

Conditions

A condition is a [=chunk=] that describes the premises that must hold true for a [=rule=] to apply. A [=condition=] identifies which [=module=] it relates to through an [=@module=] property, defaulting to the goal module. A [=condition=] holds true when the [=chunk=] in the related [=module buffer=] is a [=matching chunk=] for the [=condition=].

Actions

An action is a [=chunk=] that can directly update [=module buffers=], or can do so indirectly, e.g. by sending messages to the [=module=] to invoke graph algorithms, such as graph queries and updates, or to carry out operations, e.g. instructing a robot to move its arm. When the algorithm or operation is complete, a response can be sent back to update the module's buffer. This in turn can trigger further rules as needed.

In many cases, the actual operation that an [=action=] will carry out will appear as an [=@do=] property. Built-in operations are always supported (see ). Additional actions may be supported.

Matching chunks

A [=chunk=] |A| matches [=chunk=] |B| if the conditions below are all met:

Context. One of the following conditions holds true:
- Neither |A| nor |B| have [=@context=] properties.
- Both |A| and |B| have [=@context=] properties and |A|'s [=@context=] property [=value=] [=equals=] |B|'s [=@context=] property [=value=].
Identifier. One of the following conditions holds true:
- |A| has an [=@id=] property whose [=value=] is an [=atomic value=] that [=equals=] |B|'s [=identifier=].
- |A| does not have an [=@id=] property.
Inheritance. One of the following conditions holds true:
- |A| has an [=@kindof=] property whose [=value=] |V| is an [=atomic value=], and |B|'s [=type=] is a subclass of |V|, meaning that |B|'s [=type=] is |V| or there exists a chain of kindof links between |V| and |B|'s [=type=].
- |A| does not have an [=@kindof=] property.
Properties. For each [=property=] |p| in |A| whose [=name=] does not start with @, either of the following holds true:
- |p|'s [=value=] is ! and there is no [=property=] in |B| with |p|'s [=name=].
- |p|'s [=value=] is not ! and there exits a [=property=] in |B| with the same [=name=] and [=equal=] [=value=] as |p|.
Type. One of the following conditions holds true:
- |A| has an [=@type=] property whose [=value=] is an [=atomic value=] that [=equals=] |B|'s [=type=].
- |A| does not have an [=@type=] property, and |A|'s [=type=] is *.
- |A| does not have an [=@type=] property, and |A|'s [=type=] and |B|'s [=type=] are identical.

@-properties for conditions and actions

The [=reserved names=] defined in this section may be used as [=property=] names in [=conditions=] and [=actions=] to control their behavior.

The `@context` property

When used in a regular [=chunk=], identifies a chunk's [=context=]. When used in a [=condition=] or in an [=action=], [=matches=] a [=chunk=]'s [=context=].

recall { lunch ?restaurant }
     => lookup { @module facts; @do get; @type lunch; @context ?restaurant }

The above [=rule=] defines an [=action=] that looks for a [=chunk=] in the facts [=module=] whose [=type=] is lunch and whose [=context=] is the identifier of the lunch matched by the recall [=condition=].

The `@do` property

Specifies the graph algorithm or operation to execute. See for a list of common operations that are supported across modules.

The `@for` property

Iterates over a set of items in a comma separated list. The [=@from=] and [=@to=] properties may be used to restrict the iteration range.

The `@from` property

Specifies the zero-based starting index of an [=@for=] iteration. Value must be an integer.

The `@id` property

[=Matches=] a [=chunk=]'s [=identifier=], or binds a variable to the [=chunk=]'s [=identifier=].

The `@kindof` property

[=Matches=] a [=chunk=]'s [=type=] when that [=type=] is linked to the value of the [=@kindof=] property through a chain of kindof links. The property should be used in conjunction with a * type to match subclasses of a given class in a taxonomy.

Given the following facts in a facts [=module=]:

penguin kindof bird
eagle kindof bird
penguin p6 { name Pingou }

The following [=condition=] would match the [=chunk=] p6 if it was in the [=module buffer=] of the facts [=module=]:

* cond1 {
  @module facts
  @kindof bird
}

The `@module` property

References the [=module=] a [=condition=] or [=action=] relates to. Value must be the [=module name=] of the targeted [=module=]. In the absence of an [=@module=] property, [=conditions=] and [=actions=] apply to the goal module.

The `@more` property

Queries the [=boolean=] flag set to true by the [=rule engine=] on the current [=chunk=] in [=@for=] and [=@do properties=] iterations when there are remaining [=chunks=] to iterate over.

The `@pop` property

An [=action=] property that removes the last [=atomic value=] from a [=value=]. If the [=value=] to process is already an [=atomic value=], the underlying property is removed.

If a [=@to=] property is also present, the removed [=atomic value=] is assigned to the [=property=] identified by the [=@to=] property. In the absence of a [=@to=] property, the removed [=atomic value=] is discarded.

Given the following [=chunk=] and [=action=]:

digits { list 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 }
digits { @pop list, @to item }

The [=action=] will update the [=chunk=] to:

digits {
  list 0, 1, 2, 3, 4, 5, 6, 7, 8
  item 9
}

The `@push` property

An [=action=] property that pushes an [=atomic value=] to the end of the [=value=] of the property identified by a companion [=@to=] property. If the targeted property does not exist yet, it is created.

In the absence of a [=@to=] property, this operation has no effect.

Given the following [=chunk=] and [=action=]:

digits { list 0, 1, 2, 3, 4, 5, 6, 7, 8 }
digits { @push 9, @to list }

The [=action=] will update the [=chunk=] to:

digits { list 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 }

The `@shift` property

An [=action=] property that removes the first [=atomic value=] from a [=value=]. If the [=value=] to process is already an [=atomic value=], the underlying property is removed.

Given the following [=chunk=] and [=action=]:

digits { list 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 }
digits { @shift list, @to item }

The [=action=] will update the [=chunk=] to:

digits {
  list 1, 2, 3, 4, 5, 6, 7, 8, 9
  item 0
}

The `@status` property

Queries the [=module buffer/status=] of a [=module buffer=]. The [=rule engine=] sets the status of a [=module buffer=] with the outcome of the [=rule=]'s execution. Most operations are asynchronous, except [=@do clear=], [=@do update=] and [=@do queue=].

The `@to` property

Companion [=action=] property used in [=@do properties=], [=@for=], [=@pop=], [=@push=], [=@shift=], [=@unshift=] operations.

Meaning and value constraints depend on the operation. See individual operations for details. For instance, when used in a [=@for=] operation, the property specifies the zero-based ending index of the iteration. Value must be an integer. When used in a [=@do properties=] operation, the property specifies the name of the [=module buffer=] onto which to write the current [=chunk=].

The `@type` property

[=Matches=] a [=chunk=]'s [=type=], or binds a variable to the [=chunk=]'s [=type=].

The `@unshift` property

An [=action=] property that pushes an [=atomic value=] to the beginning of the [=value=] of the property identified by a companion [=@to=] property. If the targeted property does not exist yet, it is created.

In the absence of a [=@to=] property, this operation has no effect.

Given the following [=chunk=] and [=action=]:

digits { list 1, 2, 3, 4, 5, 6, 7, 8 }
digits { @shift 0, @to list }

The [=action=] will update the [=chunk=] to:

digits { list 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 }

TODO: Complete list with additional reserved names: @undefined, @unique, @compile, @index, @map, @priority, @source, @tag, @uncompile, @undefine.

Modules

A module is a [=graph of chunks=] associated with one and only one [=module buffer=]. A [=module=] has a module name that follows the [=name=] data type, and that is typically used to target the [=module=] in [=@module=] properties.

A [=module=] supports [=built-in operations=], and may support additional operations defined by the application when the [=module=] is initialized.

A [=module=] represents a cognitive database on which the [=rule engine=] may operate. It may be viewed as a region in the cerebral cortex, where the [=module buffer=] corresponds to the bundle of nerve fibres connecting to that region.

The [=rule engine=] automatically creates a module named goal, which will therefore always exist in a rule execution context.

The [=@module=] property allows [=conditions=] and [=actions=] to reference the [=module name=] of the [=module=] they relate to. In the absence of an [=@module=] property, [=conditions=] and [=actions=] apply to the goal module.

Module buffers

A module buffer is a container for at most one [=chunk=]. The mammalian brain is richly connected locally, and weakly remotely. A [=module buffer=] mimics the constrained communication capacity of the mammalian brains for such long range communication.

The [=rule engine=] operates on a module's [=graph of chunks=] through its [=module buffer=].

A [=module buffer=] has a status, whose value is initially [=status/okay=], and which reflects the outcome of the last [=action=] held and performed by the [=module buffer=]. Values can be:

pending: The operation is still pending.
okay: The operation completed successfully.; Switch to ok? This seems more common in technologies (e.g. HTTP) than okay.
forbidden: The operation was not allowed.
nomatch: The operation failed because there was no [=matching chunk=] for the [=action=] in the targeted [=module=].
failed: The operation failed.

A [=module buffer=] has a queue, which is a set of [=chunks=], initially empty. Each chunk in the [=queue=] has a priority, represented by an integer from 1 to 10, with 10 the highest priority. The default [=priority=] is 5. [=Chunks=] are ordered by descending [=priority=] in a [=queue=]. When [=priorities=] match, [=chunks=] are ordered by insertion order (first in, first out).

The @priority property lets [=actions=] set the [=priority=] of a [=chunk=] when they add it to a [=queue=].

A [=module buffer=] is automatically cleared when the [=actions=] associated with the [=rule=] it contained did not update the contents of targeted [=module buffers=]. This pops the [=queue=] if it is not already empty.

Built-in operations

The [=@do=] property lets an [=action=] specify the graph algorithm or operation to execute. The default operation is to update the [=module buffer=], similar to calling [=@do update=].

All [=modules=] support the built-in operations defined in this section.

All [=modules=] also support the [=@for=] property to iterate over a set of items in a comma separated list. This has the effect of loading the [=module buffer=] with the first item in the list. The index range can optionally be specified with [=@from=] and [=@to=], where the first item in the list has index 0.

The `@do clear` operation

Clears the [=module buffer=] and pops the [=queue=].

The `@do delete` operation

Forgets [=matching chunks=] in the [=graph of chunks=].

The `@do get` operation

Looks for a [=matching chunk=] in the module's [=graph of chunks=] and puts a copy of it in the [=module buffer=] if found. Modifying the [=properties=] of a [=chunk=] copied from a [=graph of chunks=] (e.g. through a [=@do update=] operation) will not alter the underlying [=graph of chunks=]. To save an updated [=chunk=], a [=@do put=] or [=@do patch=] command needs to be issued.

The `@do next` operation

Loads the next [=matching chunk=] to the targeted [=module buffer=] in an implementation dependent order.

The `@do patch` operation

If the [=chunk=] in the targeted [=module buffer=] has the same [=identifier=] as a [=chunk=] in the underlying [=graph of chunks=], patches the [=chunk=] in the [=graph of chunks=] with the [=properties=] that appear in the [=module buffer=], excluding [=properties=] prefixed with an @ character.

What is the expected behavior when the action has an @id property?

The `@do properties` operation

Initiates an iteration over the [=properties=] of the [=matching chunk=] that do not begin with @. Each [=property=] is mapped to a new [=chunk=] with the same [=type=] as the [=action=]. The action's properties are copied over, and name and value properties are used to pass the [=property=] name and value respectively. The [=@more=] property is given the value true unless this is the final [=chunk=] in the iteration, in which case [=@more=] is given the value false. By default, the iteration is written to the same [=module buffer=] as designated by the [=action=] that initiated it. However, you can designate a different [=module buffer=] with the [=@to=] property. By setting additional properties in the initiating action, you can ensure that the rules used to process the property name and value are distinct from other such iterations.

The following example first sets the facts [=module buffer=] to a [=chunk=] of [=type=] foo, and then initiates an iteration over all of the [=chunk=]'s properties:

run {}
  =>
    foo {@module facts; a 1; c 2}, # set facts buffer to foo {a 1; c 2}
    bar {@module facts; @do properties; loop prop18; @to goal} # launch iteration

# this rule is invoked with the name and value for each property
# note that 'loop prop18' is copied over from the initiating chunk
# (also note that "@do log" is an hypothetical operation to log a message)
bar {loop prop18; name ?name; value ?value}
  =>
    console {@do log; message ?name, is, ?value},
    bar {@do next}  # to load the next instance from the iteration

The `@do put` operation

Saves the contents of the [=module buffer=] as a [=chunk=] to the module's [=graph of chunks=]. If the [=action=] has an [=@id=] property, this operation will overwrite the [=chunk=] with the same [=identifier=] or will create a new [=chunk=] with the given [=identifier=] if it does not exist already. This operation will also create a new [=chunk=] in the absence of an [=@id=] property.

If a chunk was loaded with @do get, then updated with @do update, would a call to @do patch create a new chunk if @id is not set? Or would it rather update the chunk in the graph?

The `@do queue` operation

Pushes a [=chunk=] to the [=queue=] for the [=module buffer=]. If a [=@priority=] property is set to an integer value between 1 and 10, the [=priority=] of the [=chunk=] in the [=queue=] is set to that value.

The `@do update` operation

Directly updates the [=module buffer=] if the chunk [=type=] for the [=action=] is the same as the [=chunk=] currently held in the [=module buffer=]. The operation updates the properties given in the [=action=], leaving aside properties prefixed with an @ character, and leaving other existing properties unchanged. If the chunk [=type=] for the action is not the same as the [=chunk=] currently held in the [=module buffer=], a new [=chunk=] is created with the properties given in the [=action=], excluding properties prefixed with an @ character. This is the default action when an [=action=] has neither an [=@do=] property nor an [=@for=] property.

How can one update the properties prefixed with an @ character in a [=chunk=] such as [=@context=], [=@subject=] or [=@object=]?

Name operators

Operators defined in this section may be used on their own as [=names=] or in front of [=names=] to alter their meaning.

The variable operator `?`

The variable operator ? may be prepended to a [=name=] when used as a [=property=] value to turn the [=name=] into a variable which represents a symbolic name to a [=value=]. A [=variable=] gets bound to a [=value=] in a [=condition=]. The [=value=] can then be referenced in [=actions=] using the [=variable=]'s name. Effectively, [=variables=] allow applications to copy information from rule [=conditions=] to rule [=actions=].

[=Variables=] are scoped to the [=rule=] where they appear.

count { state start; from ?num1; to ?num2 }
=> increment { @module facts; @do get; number ?num1 }

The above [=rule=] defines a [=condition=] that [=matches=] a [=chunk=] in the goal [=module buffer=] whose [=type=] is count, that has a state [=property=] whose value is start, and that has from and to [=properties=]. The [=condition=] binds the value of the [=variable=] ?num1 to the [=value=] of the from [=property=] in the matching chunk, and the value of the [=variable=] ?num2 to the [=value=] of the to [=property=].

The [=rule=] defines an [=action=] that looks for a [=chunk=] in the facts [=module=] whose [=type=] is increment and that has a [=property=] named number and whose [=value=] equals the value of the ?num1 [=variable=].

[=Variables=] are [=bound=] to a [=value=] the first time they appear in a [=condition=]. Subsequent occurrences of the same [=variable=] in a [=condition=] reference their [=value=].

count { state start; from ?num1; to ?num1 }
=> console { @do log; message ?num1 }

The above [=rule=] defines a [=condition=] that [=matches=] a [=chunk=] in the goal [=module buffer=] whose [=type=] is count, that has a state [=property=] whose value is start, and that has from and to [=properties=] that have identical values. The [=condition=] binds the value of the [=variable=] ?num1 to the [=value=] of the from [=property=] in the matching chunk.

[=Variables=] may represent any type of [=value=]. In particular, a [=variable=] that [=matches=] a property whose value is a list of [=atomic values=] gets bound to the list of [=atomic values=].

basket { fruit ?f }
=> console { @do log; message ?f }

The above [=rule=] defines a [=condition=] that [=matches=] a [=chunk=] in the goal [=module buffer=] whose [=type=] is basket and that has a fruit [=property=]. Given the following [=chunk=] in the goal [=module buffer=], the [=condition=] binds variable ?f to apple, banana, orange:

basket { fruit apple, banana, orange }

A [=condition=] that contains a [=property=] with a list of [=variables=] [=matches=] a list of [=atomic values=] that has the same length. The [=condition=] does not [=match=] when the lengths of the lists differ.

basket { fruit ?a, ?b, ?o }
=> console { @do log; message ?a, ?b, ?o }

The above [=rule=] defines a [=condition=] that [=matches=] a [=chunk=] in the goal [=module buffer=] whose [=type=] is basket and that has a fruit [=property=] whose value is a list of three atomic values. Given the following [=chunk=] in the goal [=module buffer=], the [=condition=] binds variable ?a to apple, ?b to banana, and ?o to orange:

basket { fruit apple, banana, orange }

The wild card operator `*`

The wild card operator * may be used on its own in lieu of a [=name=] in one of the following cases:

As the [=type=] of a [=condition=] or [=action=] to denote that [=condition=] or [=action=] matches a [=chunk=] regardless of its [=type=].
```
* {} => ...
```
The * {} [=condition=] [=matches=] a [=chunk=] regardless of its [=type=] and [=properties=].
In a [=condition=] as the [=value=] of a [=property=] |p| to have the [=condition=] [=match=] a [=chunk=] that has a [=property=] whose [=name=] equals |p|'s [=name=], regardless of its [=value=].
```
basket { fruit * } => ...
```
The [=condition=] [=matches=] a [=chunk=] whose [=type=] is basket and which has a fruit [=property=] .
A [=variable=] may also be used to [=match=] on any [=value=]. The [=wild card operator=] avoids the need to provide a name for the [=variable=] when the actual [=value=] does not need to be captured.
In a [=condition=] as an [=atomic value=] in a list to [=match=] any [=atomic value=] at the same position in a [=chunk=].
```
basket { fruit apple, *, * } => ...
```
The [=condition=] [=matches=] a [=chunk=] whose [=type=] is basket and which has a fruit [=property=] whose [=value=] is a list of three [=atomic values=] starting with apple.

The negation operator `!`

The negation operator ! may be prepended to [=names=] to negate the outcome of their evaluation. The [=negation operator=] may be used in one of the following cases:

In a [=rule=] in front of a [=condition=] to negate it. A rule with a negated [=condition=] !|cond| applies if and only if |cond| does not hold true.
```
# Rule with a negated condition
rule {
@condition !c1
@action a1
}
person c1 { @id John }
console a1 { @do log; message "Type is not person or id is not John" }

# Same rule defined using the compact format
!person { @id John }
=> console { @do log; message "Type is not person or id is not John" }
```
The above example illustrates two equivalent ways to define a rule with a negated condition. In this example, the condition |c1| [=matches=] a [=chunk=] whose [=type=] is person and whose [=identifier=] is John. As such, the negated condition [=matches=] a [=chunk=] whose [=type=] is not person or whose [=identifier=] is not John.
In a [=condition=] in front of a [=property=] value to negate the result of a [=match=]. A negated [=property=] value !|val1| [=equals=] another [=property=] value |val2| if and only if |val1| does not [=equal=] |val2|.
```
person { @id !John }
=> console { @do log; message "Type is person but id is not John" }
```
The above [=condition=] [=matches=] a [=chunk=] whose [=type=] is person and whose [=identifier=] is not John.
```
basket { fruit ?a, !banana, ?o }
=> console { @do log; message "No banana in second position" }
```
The above [=condition=] [=matches=] a [=chunk=] whose [=type=] is basket and which has a fruit [=property=] whose [=value=] is a list of three [=atomic values=]. First and third [=atomic values=] in that list can be anything. Second [=atomic value=] must not be banana.
On its own as a [=property=] value in a [=condition=] to test that a [=property=] is undefined. A [=condition=] with a [=property=] |p| whose value is ! [=matches=] a [=chunk=] if and only if the [=chunk=] does not have a [=property=] whose [=name=] is |p|'s [=name=].
```
basket { fruit ! }
=> console { @do log; message "Basket without fruits" }
```
The above [=condition=] [=matches=] a [=chunk=] whose [=type=] is basket and which does not have a fruit [=property=].

On its own as a [=property=] value in a [=@do patch=], [=@do update=] or similar [=action=] that updates a [=chunk=] to unset a [=property=].

# Given the following chunk in the module buffer
basket { fruit apple, banana, orange }

# ... the following rule drops the fruit property
* {} => basket { @do update; fruit ! }

# Resulting chunk
basket {}

The [=negation operator=] cannot be prepended to a [=variable=] that has not yet been [=bound=]. Similarly, the [=negation operator=] cannot be used on its own as an [=atomic value=] in a list. More generally, the [=negation operator=] cannot be used elsewhere than in the cases detailed above.

# Invalid: variable ?num1 is unbound
count { state counting; start !?num1 } => ...

# Invalid: on its own in a list
basket { fruit ?a, !, ?o } => ...

# Invalid: in an update action but not on its own
* {} => basket { @do update; fruit !apple }

A second [=negation operator=] prepended to a [=name=] that starts with a [=negation operator=] cancels the effect of the first [=negation operator=].

# The following condition
person { @id !!John }

# ... is the same as this one:
person { @id John }

The reserved name operator `@`

The reserved name operator @ may be prepended to a [=name=] to denote a reserved name with specific meaning. Most [=reserved names=] are to be used as [=property=] names, typically in [=conditions=] and [=actions=] to control their behavior (see [[[#properties-for-conditions-and-actions]]]). Some of them may be used as chunk [=types=] to denote a chunk with specific meaning (see [[[#mapping-to-rdf]]]).

Mapping to RDF

Linked Data [[LINKED-DATA]], at the basis of RDF [[RDF11-CONCEPTS]], is a way to create a network of standards-based machine interpretable data across different documents and Web sites. It allows an application to start at one piece of Linked Data, and follow embedded links to other pieces of Linked Data that are hosted on different sites across the Web.

[=Names=] used in [=chunks=] are local to the [=graph of chunks=] in which they appear. For [=names=] to be usable as linked data, there needs to be a way to associate them to global identifiers. [=Reserved names=] defined in this section may be used to create such a mapping.

In turn, this mechanism can be used to map a [=graph of chunks=] to an RDF graph and vice versa.

Algorithms to serialize/deserialize a [=graph of chunks=] to an RDF graph and vice versa are out of scope of this document but may be specified in future revisions of it.

Given the following [=graph of chunks=]:

@rdfmap {
  dog http://example.com/ns/dog
  cat http://example.com/ns/cat
  age http://example.com/ns/age
  name http://example.com/ns/name
}

dog { name "Youki"; age 5 }
cat { name "Isidore"; age 3 }

The [=@rdfmap=] [=chunk=] creates a mapping between local names and a URL. This [=graph of chunks=] is equivalent to the following RDF graph expressed in Turtle [[TURTLE]]:

<http://example.org/ns/dog>
  <http://example.org/ns/name> "Youki";
  <http://example.org/ns/age> 5.

<http://example.org/ns/cat>
  <http://example.org/ns/name> "Isidore";
  <http://example.org/ns/age> 3.

The `@rdfmap` type

The [=@rdfmap=] chunk [=type=] identifies a chunk that defines a mapping between [=names=] and IRIs [[IRI]]. Each [=property=] it defines whose [=name=] does not start with one of the name operators (see [[[#name-operators]]]) creates a mapping between this [=name=] and the property [=value=], interpreted as an IRI.

# Maps the name "thing" to the "Thing" item type in schema.org
@rdfmap {
  thing http://schema.org/Thing
}

The [=@rdfmap=] keyword plays the same role in [=chunks=] as the @context keyword in JSON-LD. See the notion of Context in JSON-LD for details [[JSON-LD]]. The term [=context=] and the [=@context=] keyword have a different meaning in [=chunks=] where they identify the specific situation under which a [=chunk=] should be considered to be true. A distinct [=@rdfmap=] keyword is used here to avoid any confusion.

If multiple [=@rdfmap=] chunks create a mapping for the same [=name=], the last definition in overrides previous ones.

# Creates a mapping from image to the example.org namespace
@rdfmap { image http://example.org/ns/image }

# "image" gets mapped to http://schema.org/image
# due to the second mapping definition below that
# overrides the initial mapping defined above.
thing { image img1 }

# New mapping definition for image, overrides former one
@rdfmap { image http://schema.org/image }

An [=@rdfmap=] chunk may also contain a [=@base=] property to create a default IRI namespace for [=names=] and [=@prefix=] properties to define prefixes for compact IRIs.

The `@base` property

The [=@base=] [=property=] defines a default IRI namespace for [=names=] that are not explicitly declared in an [=@rdfmap=].

@rdfmap {
  @base http://schema.org/
  dog http://example.org/ns/dog
}

dog { name "Youki"; birthDate 2021-07-09 }

In this example, the [=@rdfmap=] chunk maps:

dog to http://example.org/ns/dog
name to http://schema.org/name
birthDate to http://schema.org/birthDate

There can be only one default IRI namespace for a given [=graph of chunks=]. If [=@base=] is used in multiple [=@rdfmap=] chunks, the last definition overrides previous ones.

# Sets example.org as default namespace
@rdfmap {
  @base http://example.org/ns/
}

# Names actually get mapped to schema.org namespace
# due to override below
Thing { name "Desktop" }

# Re-defines default namespace to use schema.org
@rdfmap {
  @base http://schema.org/
}

The `@prefix` property

The [=@prefix=] [=property=] can be used in an [=@rdfmap=] chunk to reference a [=chunk=] that defines IRI prefixes, which in turn allow the use of compact IRIs in the [=@rdfmap=] chunk.

The actual [=chunk=] that defines prefixes can have any [=type=]. Each [=property=] it defines whose [=name=] does not start with one of the name operators (see [[[#name-operators]]]) creates a prefix between the property [=name=] and the property [=value=], interpreted as an IRI.

prefix p1 {
  dcterms http://purl.org/dc/terms/
  foaf http://xmlns.com/foaf/0.1/
}

@rdfmap {
  @prefix p1
  title dcterms:title
  topic foaf:topic
}

book {
  title "Chunks of life"
  topic "Mammalian rules"
}

The [=@rdfmap=] chunk in this example maps:

title to the compact IRI dcterms:title, which gets expanded to http://purl.org/dc/terms/title through the [=@prefix=] property
topic to the compact IRI foaf:topic, which gets expanded to http://xmlns.com/foaf/0.1/topic through the [=@prefix=] property

As with [=@base=], in case of conflicts, the definition that gets referenced last overrides former definitions.

prefix last { foaf http://xmlns.com/foaf/0.1/ }
prefix first { foaf http://example.org/ns/ }

@rdfmap { @prefix first; nick foaf:nick }
@rdfmap { @prefix last }

The last [=@rdfmap=] definition makes the foaf prefix map to http://xmlns.com/foaf/0.1/, overriding the previous mapping to http://example.org/ns/. The nick [=name=] gets mapped to http://xmlns.com/foaf/0.1/nick as a consequence.

Introduction

Conformance classes

Data types

Chunks and graphs

Chunk type

Chunk identifier

Chunk properties

Chunk context

Links between chunks

Graph of chunks

Rules and modules

Rules

Conditions

Actions

Matching chunks

@-properties for conditions and actions

The @context property

The @do property

The @for property

The @from property

The @id property

The @kindof property

The @module property

The @more property

The @pop property

The @push property

The @shift property

The @status property

The @to property

The @type property

The @unshift property

Modules

Module buffers

Built-in operations

The @do clear operation

The @do delete operation

The @do get operation

The @do next operation

The @do patch operation

The @do properties operation

The @do put operation

The @do queue operation

The @do update operation

Name operators

The variable operator ?

The wild card operator *

The negation operator !

The reserved name operator @

Rule engine execution

Chunks documents

Parsing a chunks document

Chunks grammar

Railroad diagrams

Mapping to RDF

The @rdfmap type

The @base property

The @prefix property

The `@context` property

The `@do` property

The `@for` property

The `@from` property

The `@id` property

The `@kindof` property

The `@module` property

The `@more` property

The `@pop` property

The `@push` property

The `@shift` property

The `@status` property

The `@to` property

The `@type` property

The `@unshift` property

The `@do clear` operation

The `@do delete` operation

The `@do get` operation

The `@do next` operation

The `@do patch` operation

The `@do properties` operation

The `@do put` operation

The `@do queue` operation

The `@do update` operation

The variable operator `?`

The wild card operator `*`

The negation operator `!`

The reserved name operator `@`

The `@rdfmap` type

The `@base` property

The `@prefix` property