Author: Grzegorz J. Nalepa

Version: Draft 2008Q3

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

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.

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

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).

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 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 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

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)

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

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).

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.

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.

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

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 (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.

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.

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…)

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.

see for s in this page.

intepret alsv operators/formulas for numerics

(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
• See also UnixODBC
• 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.

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),

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

the attribute specification (ATTML) should be in RDF.

FIMXE the ARDML including TPH in OWL.

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