====== The XTT^2 Attribute Specification ====== **Author**: Grzegorz J. Nalepa **Version**: Draft 2008Q3 //Please put bigger remarks/discussusion, to the [[hekatedev:attributes|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 [[wp>linguistic variable]]s 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 FIXME * 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 ===== - create a //named attribute type// or use an existing one, e.g. ''temperature'' - choose //name// that //uniquely// identifies the attribute, e.g. ''thermostat_setting'', thus create a //named attribute// - 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 - attribute specification can also //optionally// inlcude * abbreviated name * textual description * a group reference (see below) * semantic annotation see [[hekate:attributes#Semantic annotation]] - communication mode has to be specified, see [[hekate:xtt2#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 [[hekate:alsvfd#any_and_null|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: - define a named attribute //year// as ''integer'' with domain <0,upper> - define a named attribute //month// as ordered ''symbolic'' with domain <1-12> (see [[hekate:attributes#ordered symbolic domain]]) - define a named attribute //day// as ordered ''symbolic'' with domain {mon-sun} - 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. - we define "day" as a numeric integer attribute with constraints ''<1,30>'' - we define "month" as a symbolic attribute with values ''jan-dec'' and an ordered domain ''1-12'' - we define "year" as a numeric integer attribute with constraints e.g. ''1970-MAX'' - we define a AG type "date" having day, month, and year. - 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. FIXME 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 [[hekate:xtt2#System Communication]] in the XTT^2 page. ===== SPOOL ===== see for FIXME s in this page. ===== Pending and Future Work ===== ==== ALSV numerics ==== FIXME intepret alsv operators/formulas for numerics ==== Type mappings ==== (**For developers**) FIXME 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 [[http://www.swi-prolog.org/packages/odbc.html#sec:2.6|SWI ODBC]] * See also [[http://www.unixodbc.org/|UnixODBC]] * Java/Prolog types mapping in [[http://www.swi-prolog.org/packages/jpl/prolog_api/overview.html#JPL_types_Java_types_as_seen_by|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!!! FIXME Basic types in other languages (also called primitive types): - in Prolog there are no types (on the low-level) - in Java/C there are the so-called //[[http://java.sun.com/docs/books/tutorial/java/nutsandbolts/datatypes.html|primitive data types]]//, these are: byte short int long, float double, char String, boolean, - so these Java types could correspond to certain XTT basic types - please note: at this level the Java system is **NOT** exandable at all!!! - 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 ==== FIXME In defining attributes, a relation to system semantics, other attributes, etc. may be stated. ''predicate(thermostat_setting,A,B).'' ==== RDF Atts ==== FIXME the attribute specification (ATTML) should be in RDF. FIMXE the ARDML including TPH in OWL. ==== Attributes and ARD ==== FIXME 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