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:
Perspectives:
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:
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:
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:
sunday
and vice versamonday < tuesday
It is assumed, that in a given system the so called named attribute types are used.
The named attribute type description includes
boolean
, colors
, temperature
symbolic
, symbolic
, numeric
{false,true}
(ordered, starts from 0), {red,green,blue}
, {-50,100}
A type is named and it specifies:
temperature
thermostat_setting
, thus create a named attributeAttributes 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:
integer
with domain <0,upper>symbolic
with domain <1-12> (see ordered symbolic domain)symbolic
with domain {mon-sun}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,30>
jan-dec
and an ordered domain 1-12
1970-MAX
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:
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).
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):
byte short int long, float double, char String, boolean,
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: