The following define query creates a new entity type, object, by subtyping the entity built-in type.

Optionally, types can be defined as abstract. An abstract type can’t be instantiated and must be subtyped in order to create entities. It exists only so other types can inherit ownerships over attribute types it owns and the roles it plays. We can use abstract types in queries, expecting to retrieve instances of its concrete subtypes.

To define a new entity type that owns one or more attribute types, use the owns keyword followed by the label of the attribute type. The attribute types are appended to the entity type definition with commas. Note, attribute types must be defined before or concurrently (in the same query) with its owner(s). We can add owners later, but we can’t own nonexistent attribute types.

To add roles that entities of a specific entity type can play, use the plays keyword.

An entity type can subtype another entity type by using the same sub keyword, but replacing the entity keyword after it with a label of another entity type to subtype.

In the above example, the resource and file entity types are subtypes of the object, which itself is a subtype of the entity built-in type. They inherit the object-type attribute type ownership from it as well as its access:object role. However, while the resource subtype is abstract, the file subtype is not. Hence, we can create file entities, but not resource entities.

Further, the path attribute type will only be owned by the file entity type and any other entity types which subtype it or directly define ownership.

To override an inherited ownership use owns keyword with the new attribute type label, followed by the as keyword and the inherited attribute type label. For example:

The new attribute type that overrides inherited type is defined in the schema as subtype of the inherited attribute type. Hence, the inherited attribute type is abstract and has the same value type as the new attribute type. The example above in a schema would look like this:

In the above example, the file entity type owns the path and file-type attribute types, with the file-type attribute type overriding the inherited object-type attribute type.

The following statement creates an access relation that defines two roles:

In addition to defining its own roles played by other types, a relation type can play roles in other relation types.

In the above example, access relation type can play the access role in permission relation type and the change role in change-request relation type. Besides, an access relation type relates an object role (e.g., file) and a action role (e.g., read). Thus, a permission relation type relates the access (i.e., read + file) and a subject (e.g., person with full-name attribute Kevin Morrison).

A relation can define multiple roles (from one to many).

A relation type can own zero, one, or many attribute types.

Optionally, relation types can be defined as abstract, so they must be subtyped in order to create instances. An abstract relation type exists only so other relation types can inherit the attribute types it owns and the roles it defines and plays.

A relation type can subtype another relation type by replacing the relation keyword with the label of another relation type. The subtype will inherit all owned attribute types and all roles related or played by the parent type.

In the example above, the collection-membership relation type inherits the parent and member roles defined in its parent type: membership.

The labels of the inherited roles can be overridden to distinguish between the roles inherited by a relation subtype versus the roles defined by its parent type.

In the example above, the collection-membership relation type subtypes the membership relation type and overrides the inherited parent role as collection. The inherited member role is inherited as it is.

The example above defines one attribute type and five relation types:

An attribute type can subtype another attribute type if its abstract. This is useful when the possible values of an attribute type can be categorized, and applications can benefit from querying entities and relations not only by a value of an attribute but also by a label of attribute type.

The above example creates an attribute type, id. However, because different entities can be identified by different information, the id type is subtyped by email, name, path, and number types — making it possible to query users by email, business units by name, files by path and records by number.

Use the @unique keyword to add uniqueness constraint to the ownership of an attribute. This prevents two instances of the same type from owning the same attribute instance (with the same value).

Unique annotation can be inherited, even using override of an ownership.

Use the @key keyword to set the owned attribute as key. That limits the cardinality to exactly one and adds uniqueness constraint. Hence, the instance of the type with attribute ownership with @key annotation will have exactly one (no more and no less) key attribute instance, and it will be unique for all instances of the same type.

The values of an attribute type can be restricted using Java regular expressions. For example, to constrain it to a set of options.

The above example defines an attribute type: visibility. It is intended for user groups, and specifies a regex to restrict its values to public, private and closed.

While it is more common for entity and relation types to own attributes, attribute types can also own (other) attribute types.

The above example creates an attribute type filepath, intended for files. It is assumed there can be multiple copies of a file, each with its own filepath — and symlinks can be created that point to these filepaths. Thus, the filepath attribute type (and NOT the file entity type) owns the symlink attribute type.

While it is more common for the roles in relations to be played by entities or other relations, they can also be played by attributes.

The above example creates the credential attribute type, and specifies it can play the role of change in the change-request relation type. While change-requests were intended to manage access changes, they can now be used to manage credential changes as well.