# The XTT^2 Attribute Specification

Author: Grzegorz J. Nalepa

Version: Draft 2008Q3

Please put bigger remarks/discussusion, to the attributes development page

## Introduction

The following assumptions for system modeling with ALSV(FD) rules is given:

• the system is modeled with the use of attributes (state variables!),
• the state of the system is fully described with attribute values,
• rule firing can possibly change system state by changing attribute values,
• the state can be changed from the outside by means of attributes

Perspectives:

• controller vs. object
• decision system (information system) vs. physical system (subject of decision)
• system vs. environment

The expressiveness of the attributive language constraints the expressiveness of the rule language.

## Attribute Types

For each attribute a type (named type) has to be stated. It is based on the basic type.

### Basic Types

Attribute types allow to be more specific about certain object properties, certain types allow for certain intuitive operations, e. g. arithmetic,

The following very general basic types are provided:

• symbolic
• numeric with scale

The numeric types are introduced to allow for arithmetic operations.

With numeric type there exist explicitly predefined upper and lower limits enforced by the implementation, simply referenced as LMAX, and LMIN (L stands for limit).

### Domains

A domain is a discrete, finite set of allowed attribute values.

The numeric domain is an ordered one.

For the symbolic domain we consider two cases:

• an unordered one, corresponds to a set
• ordered one, corresponds to a list

Real numbers (floats) can be used in the system, but we explicitly state how many digits are allowed before and after the decimal point (so they are in fact integers like in many other programming languages).

#### Domain Spec

Domain specification can use a straightforward notation in a form:

DOMAIN := VALS ('u' VALS)*
VALS   := '{'SYM(','SYM)*'}'
VALS   := '<'NUM','NUM'>'
VALS   := '{'NUM(','NUM)*'}'
NUM    := '0'|'1'|'2'|'3'|'4'|'5'|'6'|'7'|'8'|'9'
SYM    := LETTER(LETTER|NUM)*
LETTER := 'a'-'z'|'A'-'Z'

#### Ordered symbolic domain

Ordered symbolic domain is a set of symbols with an order function defined. This corresponds (in a vague sense) to the so-called linguistic variables in other formalisms.

The order specification can start from 0 or 1.

In this way, one might have a named attribute type day-of-week having an ordered symbolic domain, and be able to:

• use 1 instead of sunday and vice versa
• compare monday < tuesday

### Named Types

It is assumed, that in a given system the so called named attribute types are used.

The named attribute type description includes

• a type name, e.g. boolean, colors, temperature
• a basic type, e.g. symbolic, symbolic, numeric
• in the case of the numeric type the scale specification
• domain definition, e.g. {false,true} (ordered, starts from 0), {red,green,blue}, {-50,100}

A type is named and it specifies:

• basic type
• domain
• a group (optional)

## Defining Attributes

1. create a named attribute type or use an existing one, e.g. temperature
2. choose name that uniquely identifies the attribute, e.g. thermostat_setting, thus create a named attribute
3. decide whether the attribute is a simple or general one (see ALSV(FD), that is if it takes only single (atomic) values, or multiple or (non-atomic)) values
4. attribute specification can also optionally inlcude
• abbreviated name
• textual description
• a group reference (see below)
• semantic annotation see Semantic annotation
5. communication mode has to be specified, see System Communication,
• communication class: in, out, state, comm
• attribute callback predicate

## Attribute Values

Attributes can have atomic or non-atomic values (for general attributes). Number of values for general attributes is not limited.

In a general sense the general attribute value is an unordered set. This set can be treated in different ways depending on semantics as a regular set or an ordered one.

Currently there are no plans to support regions algebra, that is to allow treating the value set as an ordord one (a list).

### NULL

To provide the proper semantics: “no value”, “unset”, “not defined yet”, etc. the special value NULL is introduced.

Following the RDBM convention and logic, a NULL attribute value is possible.

The semantics can be: “no value”, “unset”, “not defined yet”, etc. Yes; to me, we should accept NULL exactly as it is in RDB systems. This allows to import data as they are.

See here for the binding resolution.

However, we could consider another semantics, such as “unknown”, see below.

### ND or NA

On the other hand, we can consider introducing ND or NA as for example the capacity of and electric engine, meaning “does not apply”, e.g. “maiden name” in case of a male.

NULL as “unknown” should be treated as an extension. Its use should be explicitly allowed in the attribute specification.

### Explicit Notation

A simple explicit notation for attributes is to represent/store all values, e.g. {1,2,3,4,5}.

### Implicit Notation

For setting attribute value the same implicit notation as for the domains should be used (a sum of ranges or values), i.e. S=<5,8>u{3}. at both the HML and HMR levels.

I agree. We should define the rules for well-formed expressions (enabling unique calculation of values), and allow for using it. This should be based on set algebra and incorporate the notational variants, such as A > 5 (which in fact means A={6,7} if the domain of A is {1,2,3,4,5,6,7}.

So we use the sum SetTheory operator and sets of values.

Syntactic suger on the interface level, consider attribute T, domain {0,50}, we mean, t=<10, the tool sould hint, t=<0,10>, in STATE we store t=<0,10>, see above.

## Attribute Groups

### Definition

Attribute groups (AG) provide means for defining a certain common context for a given set of named attributes. AG provide a certain namespace for attributes. Attributes within a group can be referenced by their name only, by using a simple Group.Attribute syntax.

### AG Example

Example: to support date, we would:

1. define a named attribute year as integer with domain <0,upper>
2. define a named attribute month as ordered symbolic with domain <1-12> (see ordered symbolic domain)
3. define a named attribute day as ordered symbolic with domain {mon-sun}
4. define a AG date with named atts year, month, day in its scope.

### AG Template

An AG can could function as template (an “attribute type”).

Let's suppose we want to represent a “date of birth” and “current date”. So, we need a “date”, then think what is a date.

1. we define “day” as a numeric integer attribute with constraints <1,30>
2. we define “month” as a symbolic attribute with values jan-dec and an ordered domain 1-12
3. we define “year” as a numeric integer attribute with constraints e.g. 1970-MAX
4. we define a AG type “date” having day, month, and year.
5. we define two physical attributes “date of birth” and “current date” having the type of “date”

The CASE tools should support a concept of an attribute library, where some predefined types are available.

this requires some discussion

(For some developers: Attribute groups are not the so-called grouped attributes from the XTT+ proposal, where they were supposed to work a special data structure…)

## Attribute Blackboard

In XTT^2 attributes are indirectly used as communication means between the system and the world.

For the full discussion see System Communication in the XTT^2 page.

## Pending and Future Work

### ALSV numerics

intepret alsv operators/formulas for numerics

### Type mappings

(For developers)

For implementing the inference engine, explicit language mappings between Prolog and:

• ANSI C
• Java
• SQL

have to be considered

Type specification has Prolog, SQL and Java mapping in mind (we map to Java object, not basic types, so Integer, not int).

• For RDB2Prolog see SWI ODBC
• Java/Prolog types mapping in JPL
• There is no binary type (blob)!

Below is an OLD Discussion, needs updates.

Integer is a subset of Numeric. An integer value is a numeric value with scale set to zero.

Name Prolog Java C RDB
Bool basic use java.lang.Boolean int bool
Symbol atom java.lang.String char* var char
Numeric (fixed-point) float java.lang.Number.Float float float
Integer integer java.lang.Number.Integer int integer

Symbol might also be called String.

check types in Hibernate!!!

Basic types in other languages (also called primitive types):

1. in Prolog there are no types (on the low-level)
2. in Java/C there are the so-called primitive data types, these are:

byte short int long, float double, char String, boolean,

1. so these Java types could correspond to certain XTT basic types
2. please note: at this level the Java system is NOT exandable at all!!!
3. so primitive types map to the above Java primitive types, but we could have

integer (a special case of numeric) for (byte short int long), numeric (general) for (float double), symbolic for (char String), bool for (boolean),

### Semantic annotation

In defining attributes, a relation to system semantics, other attributes, etc. may be stated. predicate(thermostat_setting,A,B).

### RDF Atts

the attribute specification (ATTML) should be in RDF.

FIMXE the ARDML including TPH in OWL.

### Attributes and ARD

Considering the ARD process and TPH, certain relationships should be defined/discovered between:

• attribute groups
• attribute types
• scope as in ARD
• gen-spec/composition and finalization/split in ARD