]>
0.1 (30.05.2010 21:51:45)
ANY (DataValue)
Defines the basic properties of every data value. This is an abstract
type, meaning that no value can be just a data value without belonging
to any concrete type. Every concrete type is a specialization of this
general abstract DataValue type.
abstract type DataValue alias ANY {
TYPE dataType;
BN nonNull;
BN isNull;
CS nullFlavor;
BL notApplicable;
BL unknown;
BL other;
BL equal(ANY x);
};
Defines the basic properties of every data value. This is an abstract
type, meaning that no value can be just a data value without belonging
to any concrete type. Every concrete type is a specialization of this
general abstract DataValue type.
abstract type DataValue alias ANY {
TYPE dataType;
BN nonNull;
BN isNull;
CS nullFlavor;
BL notApplicable;
BL unknown;
BL other;
BL equal(ANY x);
};
Defines the basic properties of every data value. This is an abstract
type, meaning that no value can be just a data value without belonging
to any concrete type. Every concrete type is a specialization of this
general abstract DataValue type.
abstract type DataValue alias ANY {
TYPE dataType;
BN nonNull;
BN isNull;
CS nullFlavor;
BL notApplicable;
BL unknown;
BL other;
BL equal(ANY x);
};
Defines the basic properties of every data value. This is an abstract
type, meaning that no value can be just a data value without belonging
to any concrete type. Every concrete type is a specialization of this
general abstract DataValue type.
abstract type DataValue alias ANY {
TYPE dataType;
BN nonNull;
BN isNull;
CS nullFlavor;
BL notApplicable;
BL unknown;
BL other;
BL equal(ANY x);
};
Defines the basic properties of every data value. This is an abstract
type, meaning that no value can be just a data value without belonging
to any concrete type. Every concrete type is a specialization of this
general abstract DataValue type.
abstract type DataValue alias ANY {
TYPE dataType;
BN nonNull;
BN isNull;
CS nullFlavor;
BL notApplicable;
BL unknown;
BL other;
BL equal(ANY x);
};
Defines the basic properties of every data value. This is an abstract
type, meaning that no value can be just a data value without belonging
to any concrete type. Every concrete type is a specialization of this
general abstract DataValue type.
abstract type DataValue alias ANY {
TYPE dataType;
BN nonNull;
BN isNull;
CS nullFlavor;
BL notApplicable;
BL unknown;
BL other;
BL equal(ANY x);
};
Defines the basic properties of every data value. This is an abstract
type, meaning that no value can be just a data value without belonging
to any concrete type. Every concrete type is a specialization of this
general abstract DataValue type.
abstract type DataValue alias ANY {
TYPE dataType;
BN nonNull;
BN isNull;
CS nullFlavor;
BL notApplicable;
BL unknown;
BL other;
BL equal(ANY x);
};
Defines the basic properties of every data value. This is an abstract
type, meaning that no value can be just a data value without belonging
to any concrete type. Every concrete type is a specialization of this
general abstract DataValue type.
abstract type DataValue alias ANY {
TYPE dataType;
BN nonNull;
BN isNull;
CS nullFlavor;
BL notApplicable;
BL unknown;
BL other;
BL equal(ANY x);
};
Defines the basic properties of every data value. This is an abstract
type, meaning that no value can be just a data value without belonging
to any concrete type. Every concrete type is a specialization of this
general abstract DataValue type.
abstract type DataValue alias ANY {
TYPE dataType;
BN nonNull;
BN isNull;
CS nullFlavor;
BL notApplicable;
BL unknown;
BL other;
BL equal(ANY x);
};
TYPE (DataType)
A meta-type declared in order to allow the formal definitions to speak
about the data type of a value. Any data type defined in this
specification is a value of the type DataType.
private type DataType alias TYPE specializes ANY {
CS shortName;
CS longName;
BN implies(TYPE that);
};
A meta-type declared in order to allow the formal definitions to speak
about the data type of a value. Any data type defined in this
specification is a value of the type DataType.
private type DataType alias TYPE specializes ANY {
CS shortName;
CS longName;
BN implies(TYPE that);
};
A meta-type declared in order to allow the formal definitions to speak
about the data type of a value. Any data type defined in this
specification is a value of the type DataType.
private type DataType alias TYPE specializes ANY {
CS shortName;
CS longName;
BN implies(TYPE that);
};
A meta-type declared in order to allow the formal definitions to speak
about the data type of a value. Any data type defined in this
specification is a value of the type DataType.
private type DataType alias TYPE specializes ANY {
CS shortName;
CS longName;
BN implies(TYPE that);
};
BL (Boolean)
The Boolean type stands for the values of two-valued logic. A Boolean
value can be either true or false, or, as
any other value may be NULL.
With any data value potentially being NULL, the two-valued logic is
effectively extended to a three-valued logic as shown in the following
truth tables:
Truth Table: NOT NOT ? true false false true NULL NULL Truth Table: AND AND true false NULL true true false NULL false false false false NULL NULL false NULL Truth Table: OR OR true false NULL true true true true false true false NULL NULL true NULL NULL
Where a boolean operation is performed upon 2 data types with different
nullFlavors, the nullFlavor of the result is the first common ancestor
of the 2 different nullFlavors, though conformant applications may also
create a result that is any common ancestor
type Boolean alias BL specializes ANY
values(true, false)
{
BL not;
BL and(BL x);
BL or(BL x);
BL xor(BL x);
BL implies(BL x);
literal ST;
};
The Boolean type stands for the values of two-valued logic. A Boolean
value can be either true or false, or, as
any other value may be NULL.
With any data value potentially being NULL, the two-valued logic is
effectively extended to a three-valued logic as shown in the following
truth tables:
Truth Table: NOT NOT ? true false false true NULL NULL Truth Table: AND AND true false NULL true true false NULL false false false false NULL NULL false NULL Truth Table: OR OR true false NULL true true true true false true false NULL NULL true NULL NULL
Where a boolean operation is performed upon 2 data types with different
nullFlavors, the nullFlavor of the result is the first common ancestor
of the 2 different nullFlavors, though conformant applications may also
create a result that is any common ancestor
type Boolean alias BL specializes ANY
values(true, false)
{
BL not;
BL and(BL x);
BL or(BL x);
BL xor(BL x);
BL implies(BL x);
literal ST;
};
The Boolean type stands for the values of two-valued logic. A Boolean
value can be either true or false, or, as
any other value may be NULL.
With any data value potentially being NULL, the two-valued logic is
effectively extended to a three-valued logic as shown in the following
truth tables:
Truth Table: NOT NOT ? true false false true NULL NULL Truth Table: AND AND true false NULL true true false NULL false false false false NULL NULL false NULL Truth Table: OR OR true false NULL true true true true false true false NULL NULL true NULL NULL
Where a boolean operation is performed upon 2 data types with different
nullFlavors, the nullFlavor of the result is the first common ancestor
of the 2 different nullFlavors, though conformant applications may also
create a result that is any common ancestor
type Boolean alias BL specializes ANY
values(true, false)
{
BL not;
BL and(BL x);
BL or(BL x);
BL xor(BL x);
BL implies(BL x);
literal ST;
};
The Boolean type stands for the values of two-valued logic. A Boolean
value can be either true or false, or, as
any other value may be NULL.
With any data value potentially being NULL, the two-valued logic is
effectively extended to a three-valued logic as shown in the following
truth tables:
Truth Table: NOT NOT ? true false false true NULL NULL Truth Table: AND AND true false NULL true true false NULL false false false false NULL NULL false NULL Truth Table: OR OR true false NULL true true true true false true false NULL NULL true NULL NULL
Where a boolean operation is performed upon 2 data types with different
nullFlavors, the nullFlavor of the result is the first common ancestor
of the 2 different nullFlavors, though conformant applications may also
create a result that is any common ancestor
type Boolean alias BL specializes ANY
values(true, false)
{
BL not;
BL and(BL x);
BL or(BL x);
BL xor(BL x);
BL implies(BL x);
literal ST;
};
The Boolean type stands for the values of two-valued logic. A Boolean
value can be either true or false, or, as
any other value may be NULL.
With any data value potentially being NULL, the two-valued logic is
effectively extended to a three-valued logic as shown in the following
truth tables:
Truth Table: NOT NOT ? true false false true NULL NULL Truth Table: AND AND true false NULL true true false NULL false false false false NULL NULL false NULL Truth Table: OR OR true false NULL true true true true false true false NULL NULL true NULL NULL
Where a boolean operation is performed upon 2 data types with different
nullFlavors, the nullFlavor of the result is the first common ancestor
of the 2 different nullFlavors, though conformant applications may also
create a result that is any common ancestor
type Boolean alias BL specializes ANY
values(true, false)
{
BL not;
BL and(BL x);
BL or(BL x);
BL xor(BL x);
BL implies(BL x);
literal ST;
};
The Boolean type stands for the values of two-valued logic. A Boolean
value can be either true or false, or, as
any other value may be NULL.
With any data value potentially being NULL, the two-valued logic is
effectively extended to a three-valued logic as shown in the following
truth tables:
Truth Table: NOT NOT ? true false false true NULL NULL Truth Table: AND AND true false NULL true true false NULL false false false false NULL NULL false NULL Truth Table: OR OR true false NULL true true true true false true false NULL NULL true NULL NULL
Where a boolean operation is performed upon 2 data types with different
nullFlavors, the nullFlavor of the result is the first common ancestor
of the 2 different nullFlavors, though conformant applications may also
create a result that is any common ancestor
type Boolean alias BL specializes ANY
values(true, false)
{
BL not;
BL and(BL x);
BL or(BL x);
BL xor(BL x);
BL implies(BL x);
literal ST;
};
The Boolean type stands for the values of two-valued logic. A Boolean
value can be either true or false, or, as
any other value may be NULL.
With any data value potentially being NULL, the two-valued logic is
effectively extended to a three-valued logic as shown in the following
truth tables:
Truth Table: NOT NOT ? true false false true NULL NULL Truth Table: AND AND true false NULL true true false NULL false false false false NULL NULL false NULL Truth Table: OR OR true false NULL true true true true false true false NULL NULL true NULL NULL
Where a boolean operation is performed upon 2 data types with different
nullFlavors, the nullFlavor of the result is the first common ancestor
of the 2 different nullFlavors, though conformant applications may also
create a result that is any common ancestor
type Boolean alias BL specializes ANY
values(true, false)
{
BL not;
BL and(BL x);
BL or(BL x);
BL xor(BL x);
BL implies(BL x);
literal ST;
};
BN (BooleanNonNull)
The BooleanNonNull constrains the boolean type so that the value may not be NULL.
This type is created for use within the data types specification where it is not
appropriate for a null value to be used
private type BooleanNonNull alias BN specializes BL;
The BooleanNonNull constrains the boolean type so that the value may not be NULL.
This type is created for use within the data types specification where it is not
appropriate for a null value to be used
private type BooleanNonNull alias BN specializes BL;
BIN (BinaryData)
Binary data is a raw block of bits. Binary data is a protected
type that should not be declared outside the data type specification.
A bit is semantically identical with a non-null Boolean value. Thus,
all binary data is - semantically - a sequence of non-null
Boolean values.
protected type BinaryData alias BIN specializes LIST<BN>;
the representation of arbitrary binary data is the responsibility of
an ITS. How the ITS accomplishes this depends on the underlying
Implementation Technology (whether it is character-based or binary)
and on the represented data. Semantically character data is
represented as binary data, however, a character-based ITS should not
convert character data into arbitrary binary data and then represent
binary data in a character encoding. Ultimately even character-based
implementation technology will communicate binary data.
ED (EncapsulatedData)
Data that is primarily intended for human interpretation or for
further machine processing outside the scope of HL7. This includes
unformatted or formatted written language, multimedia data, or
structured information in as defined by a different standard (e.g.,
XML-signatures.) Instead of the data itself, an
may contain only a reference (see .) Note that
the data type is a specialization of the
data type when the media
type is text/plain.
Encapsulated data can be present in two forms, inline or by
reference. Inline data is communicated or moved as part of the
encapsulated data value, whereas by-reference data may reside at a
different (remote) location. The data is the same whether it is
located inline or remote.
type EncapsulatedData alias ED specializes BIN {
CS mediaType;
CS charset;
CS language;
CS compression;
TEL reference;
BIN integrityCheck;
CS integrityCheckAlgorithm;
ED thumbnail;
};
Data that is primarily intended for human interpretation or for
further machine processing outside the scope of HL7. This includes
unformatted or formatted written language, multimedia data, or
structured information in as defined by a different standard (e.g.,
XML-signatures.) Instead of the data itself, an
may contain only a reference (see .) Note that
the data type is a specialization of the
data type when the media
type is text/plain.
Encapsulated data can be present in two forms, inline or by
reference. Inline data is communicated or moved as part of the
encapsulated data value, whereas by-reference data may reside at a
different (remote) location. The data is the same whether it is
located inline or remote.
type EncapsulatedData alias ED specializes BIN {
CS mediaType;
CS charset;
CS language;
CS compression;
TEL reference;
BIN integrityCheck;
CS integrityCheckAlgorithm;
ED thumbnail;
};
Data that is primarily intended for human interpretation or for
further machine processing outside the scope of HL7. This includes
unformatted or formatted written language, multimedia data, or
structured information in as defined by a different standard (e.g.,
XML-signatures.) Instead of the data itself, an
may contain only a reference (see .) Note that
the data type is a specialization of the
data type when the media
type is text/plain.
Encapsulated data can be present in two forms, inline or by
reference. Inline data is communicated or moved as part of the
encapsulated data value, whereas by-reference data may reside at a
different (remote) location. The data is the same whether it is
located inline or remote.
type EncapsulatedData alias ED specializes BIN {
CS mediaType;
CS charset;
CS language;
CS compression;
TEL reference;
BIN integrityCheck;
CS integrityCheckAlgorithm;
ED thumbnail;
};
Data that is primarily intended for human interpretation or for
further machine processing outside the scope of HL7. This includes
unformatted or formatted written language, multimedia data, or
structured information in as defined by a different standard (e.g.,
XML-signatures.) Instead of the data itself, an
may contain only a reference (see .) Note that
the data type is a specialization of the
data type when the media
type is text/plain.
Encapsulated data can be present in two forms, inline or by
reference. Inline data is communicated or moved as part of the
encapsulated data value, whereas by-reference data may reside at a
different (remote) location. The data is the same whether it is
located inline or remote.
type EncapsulatedData alias ED specializes BIN {
CS mediaType;
CS charset;
CS language;
CS compression;
TEL reference;
BIN integrityCheck;
CS integrityCheckAlgorithm;
ED thumbnail;
};
Data that is primarily intended for human interpretation or for
further machine processing outside the scope of HL7. This includes
unformatted or formatted written language, multimedia data, or
structured information in as defined by a different standard (e.g.,
XML-signatures.) Instead of the data itself, an
may contain only a reference (see .) Note that
the data type is a specialization of the
data type when the media
type is text/plain.
Encapsulated data can be present in two forms, inline or by
reference. Inline data is communicated or moved as part of the
encapsulated data value, whereas by-reference data may reside at a
different (remote) location. The data is the same whether it is
located inline or remote.
type EncapsulatedData alias ED specializes BIN {
CS mediaType;
CS charset;
CS language;
CS compression;
TEL reference;
BIN integrityCheck;
CS integrityCheckAlgorithm;
ED thumbnail;
};
Data that is primarily intended for human interpretation or for
further machine processing outside the scope of HL7. This includes
unformatted or formatted written language, multimedia data, or
structured information in as defined by a different standard (e.g.,
XML-signatures.) Instead of the data itself, an
may contain only a reference (see .) Note that
the data type is a specialization of the
data type when the media
type is text/plain.
Encapsulated data can be present in two forms, inline or by
reference. Inline data is communicated or moved as part of the
encapsulated data value, whereas by-reference data may reside at a
different (remote) location. The data is the same whether it is
located inline or remote.
type EncapsulatedData alias ED specializes BIN {
CS mediaType;
CS charset;
CS language;
CS compression;
TEL reference;
BIN integrityCheck;
CS integrityCheckAlgorithm;
ED thumbnail;
};
Data that is primarily intended for human interpretation or for
further machine processing outside the scope of HL7. This includes
unformatted or formatted written language, multimedia data, or
structured information in as defined by a different standard (e.g.,
XML-signatures.) Instead of the data itself, an
may contain only a reference (see .) Note that
the data type is a specialization of the
data type when the media
type is text/plain.
Encapsulated data can be present in two forms, inline or by
reference. Inline data is communicated or moved as part of the
encapsulated data value, whereas by-reference data may reside at a
different (remote) location. The data is the same whether it is
located inline or remote.
type EncapsulatedData alias ED specializes BIN {
CS mediaType;
CS charset;
CS language;
CS compression;
TEL reference;
BIN integrityCheck;
CS integrityCheckAlgorithm;
ED thumbnail;
};
Data that is primarily intended for human interpretation or for
further machine processing outside the scope of HL7. This includes
unformatted or formatted written language, multimedia data, or
structured information in as defined by a different standard (e.g.,
XML-signatures.) Instead of the data itself, an
may contain only a reference (see .) Note that
the data type is a specialization of the
data type when the media
type is text/plain.
Encapsulated data can be present in two forms, inline or by
reference. Inline data is communicated or moved as part of the
encapsulated data value, whereas by-reference data may reside at a
different (remote) location. The data is the same whether it is
located inline or remote.
type EncapsulatedData alias ED specializes BIN {
CS mediaType;
CS charset;
CS language;
CS compression;
TEL reference;
BIN integrityCheck;
CS integrityCheckAlgorithm;
ED thumbnail;
};
Data that is primarily intended for human interpretation or for
further machine processing outside the scope of HL7. This includes
unformatted or formatted written language, multimedia data, or
structured information in as defined by a different standard (e.g.,
XML-signatures.) Instead of the data itself, an
may contain only a reference (see .) Note that
the data type is a specialization of the
data type when the media
type is text/plain.
Encapsulated data can be present in two forms, inline or by
reference. Inline data is communicated or moved as part of the
encapsulated data value, whereas by-reference data may reside at a
different (remote) location. The data is the same whether it is
located inline or remote.
type EncapsulatedData alias ED specializes BIN {
CS mediaType;
CS charset;
CS language;
CS compression;
TEL reference;
BIN integrityCheck;
CS integrityCheckAlgorithm;
ED thumbnail;
};
Data that is primarily intended for human interpretation or for
further machine processing outside the scope of HL7. This includes
unformatted or formatted written language, multimedia data, or
structured information in as defined by a different standard (e.g.,
XML-signatures.) Instead of the data itself, an
may contain only a reference (see .) Note that
the data type is a specialization of the
data type when the media
type is text/plain.
Encapsulated data can be present in two forms, inline or by
reference. Inline data is communicated or moved as part of the
encapsulated data value, whereas by-reference data may reside at a
different (remote) location. The data is the same whether it is
located inline or remote.
type EncapsulatedData alias ED specializes BIN {
CS mediaType;
CS charset;
CS language;
CS compression;
TEL reference;
BIN integrityCheck;
CS integrityCheckAlgorithm;
ED thumbnail;
};
ST (CharacterString)
The character string data type stands for text data, primarily
intended for machine processing (e.g., sorting, querying, indexing,
etc.) Used for names, symbols, and formal expressions.
Requirement:
ST is a specialization of ED so that any RIM attribute which has the type
ED can be constrained to a ST. The most important case is Act.text, which is
an ED to cater for the use of references and multimedia data, but is often
constrained to plain text.
The character string is a restricted encapsulated data type ( ),
whose type property is fixed to text/plain, and whose data must be
inlined and not compressed. Thus, the properties compression, reference,
integrity check, algorithm, and thumbnail are not applicable. The character
string data type is used when the appearance of text does not bear meaning,
which is true for formalized text and all kinds of names.
The character string (ST) data type interprets the encapsulated data
as character data (as opposed to bits), depending on the charset
property of the encapsulated data type.
The headCharacter and tailString properties define ST as a sequence
of entities each of which uniquely identifies one character from the
joint set of all characters known by any language of the world.
ISO/IEC 10646-1: 1993 defines a character as "A member of a set of
elements used for the organization, control, or representation of
data." ISO/IEC TR 15285 - An operational model for characters and
glyphs. Discusses the problems involved in defining
characters. Notably, characters are abstract entities of information,
independent of type font or language. The ISO 10646 (UNICODE
[http://www.unicode.org]) - or in Japan, JIS X0221 - is a globally
applicable character set that uniquely identifies all characters of
any language in the world.
In this specification, ISO 10646 serves as a semantic model for
character strings. The important point is that for semantic purposes,
there is no notion of separate character sets and switching between
character sets. Character set and character encoding are ITS layer
considerations. The formal definition gives indication to this effect
because each character is by itself an value that
has a charset property. Thus, the binary encoding of each character is
always understood in the context of a certain character set. This does
not mean that the ITS should represent a character string as a
sequence of full blown values. What it means is that
on the application layer the notion of character encoding is
irrelevant when we deal with character strings.
The length of a character string is the number of characters in the string.
The head of a string is a string of only one character. A character
string must at least have one character or else it is NULL. A
zero-length string is an exceptional value (NULL), not a proper
character string value.
The length of a string is the number of characters, not the number of
encoded bytes. Byte encoding is an ITS issue and is not relevant on
the application layer.
The following rules apply to whitespace contained within character strings:
TAB, space and end-of-line are all considered whitespace characters.
Both preceding and trailing whitespace is significant.
Different whitespace characters are not interchangable.
Different representations of end-of-line are normalised according to the
method described in the XML specification
[]
Sequences of whitespace cannot be compressed to shorter sequences.
type CharacterString alias ST specializes ED {
ST headCharacter;
ST tailString;
literal ST;
};
The character string data type stands for text data, primarily
intended for machine processing (e.g., sorting, querying, indexing,
etc.) Used for names, symbols, and formal expressions.
Requirement:
ST is a specialization of ED so that any RIM attribute which has the type
ED can be constrained to a ST. The most important case is Act.text, which is
an ED to cater for the use of references and multimedia data, but is often
constrained to plain text.
The character string is a restricted encapsulated data type ( ),
whose type property is fixed to text/plain, and whose data must be
inlined and not compressed. Thus, the properties compression, reference,
integrity check, algorithm, and thumbnail are not applicable. The character
string data type is used when the appearance of text does not bear meaning,
which is true for formalized text and all kinds of names.
The character string (ST) data type interprets the encapsulated data
as character data (as opposed to bits), depending on the charset
property of the encapsulated data type.
The headCharacter and tailString properties define ST as a sequence
of entities each of which uniquely identifies one character from the
joint set of all characters known by any language of the world.
ISO/IEC 10646-1: 1993 defines a character as "A member of a set of
elements used for the organization, control, or representation of
data." ISO/IEC TR 15285 - An operational model for characters and
glyphs. Discusses the problems involved in defining
characters. Notably, characters are abstract entities of information,
independent of type font or language. The ISO 10646 (UNICODE
[http://www.unicode.org]) - or in Japan, JIS X0221 - is a globally
applicable character set that uniquely identifies all characters of
any language in the world.
In this specification, ISO 10646 serves as a semantic model for
character strings. The important point is that for semantic purposes,
there is no notion of separate character sets and switching between
character sets. Character set and character encoding are ITS layer
considerations. The formal definition gives indication to this effect
because each character is by itself an value that
has a charset property. Thus, the binary encoding of each character is
always understood in the context of a certain character set. This does
not mean that the ITS should represent a character string as a
sequence of full blown values. What it means is that
on the application layer the notion of character encoding is
irrelevant when we deal with character strings.
The length of a character string is the number of characters in the string.
The head of a string is a string of only one character. A character
string must at least have one character or else it is NULL. A
zero-length string is an exceptional value (NULL), not a proper
character string value.
The length of a string is the number of characters, not the number of
encoded bytes. Byte encoding is an ITS issue and is not relevant on
the application layer.
The following rules apply to whitespace contained within character strings:
TAB, space and end-of-line are all considered whitespace characters.
Both preceding and trailing whitespace is significant.
Different whitespace characters are not interchangable.
Different representations of end-of-line are normalised according to the
method described in the XML specification
[]
Sequences of whitespace cannot be compressed to shorter sequences.
type CharacterString alias ST specializes ED {
ST headCharacter;
ST tailString;
literal ST;
};
The character string data type stands for text data, primarily
intended for machine processing (e.g., sorting, querying, indexing,
etc.) Used for names, symbols, and formal expressions.
Requirement:
ST is a specialization of ED so that any RIM attribute which has the type
ED can be constrained to a ST. The most important case is Act.text, which is
an ED to cater for the use of references and multimedia data, but is often
constrained to plain text.
The character string is a restricted encapsulated data type ( ),
whose type property is fixed to text/plain, and whose data must be
inlined and not compressed. Thus, the properties compression, reference,
integrity check, algorithm, and thumbnail are not applicable. The character
string data type is used when the appearance of text does not bear meaning,
which is true for formalized text and all kinds of names.
The character string (ST) data type interprets the encapsulated data
as character data (as opposed to bits), depending on the charset
property of the encapsulated data type.
The headCharacter and tailString properties define ST as a sequence
of entities each of which uniquely identifies one character from the
joint set of all characters known by any language of the world.
ISO/IEC 10646-1: 1993 defines a character as "A member of a set of
elements used for the organization, control, or representation of
data." ISO/IEC TR 15285 - An operational model for characters and
glyphs. Discusses the problems involved in defining
characters. Notably, characters are abstract entities of information,
independent of type font or language. The ISO 10646 (UNICODE
[http://www.unicode.org]) - or in Japan, JIS X0221 - is a globally
applicable character set that uniquely identifies all characters of
any language in the world.
In this specification, ISO 10646 serves as a semantic model for
character strings. The important point is that for semantic purposes,
there is no notion of separate character sets and switching between
character sets. Character set and character encoding are ITS layer
considerations. The formal definition gives indication to this effect
because each character is by itself an value that
has a charset property. Thus, the binary encoding of each character is
always understood in the context of a certain character set. This does
not mean that the ITS should represent a character string as a
sequence of full blown values. What it means is that
on the application layer the notion of character encoding is
irrelevant when we deal with character strings.
The length of a character string is the number of characters in the string.
The head of a string is a string of only one character. A character
string must at least have one character or else it is NULL. A
zero-length string is an exceptional value (NULL), not a proper
character string value.
The length of a string is the number of characters, not the number of
encoded bytes. Byte encoding is an ITS issue and is not relevant on
the application layer.
The following rules apply to whitespace contained within character strings:
TAB, space and end-of-line are all considered whitespace characters.
Both preceding and trailing whitespace is significant.
Different whitespace characters are not interchangable.
Different representations of end-of-line are normalised according to the
method described in the XML specification
[]
Sequences of whitespace cannot be compressed to shorter sequences.
type CharacterString alias ST specializes ED {
ST headCharacter;
ST tailString;
literal ST;
};
The character string data type stands for text data, primarily
intended for machine processing (e.g., sorting, querying, indexing,
etc.) Used for names, symbols, and formal expressions.
Requirement:
ST is a specialization of ED so that any RIM attribute which has the type
ED can be constrained to a ST. The most important case is Act.text, which is
an ED to cater for the use of references and multimedia data, but is often
constrained to plain text.
The character string is a restricted encapsulated data type ( ),
whose type property is fixed to text/plain, and whose data must be
inlined and not compressed. Thus, the properties compression, reference,
integrity check, algorithm, and thumbnail are not applicable. The character
string data type is used when the appearance of text does not bear meaning,
which is true for formalized text and all kinds of names.
The character string (ST) data type interprets the encapsulated data
as character data (as opposed to bits), depending on the charset
property of the encapsulated data type.
The headCharacter and tailString properties define ST as a sequence
of entities each of which uniquely identifies one character from the
joint set of all characters known by any language of the world.
ISO/IEC 10646-1: 1993 defines a character as "A member of a set of
elements used for the organization, control, or representation of
data." ISO/IEC TR 15285 - An operational model for characters and
glyphs. Discusses the problems involved in defining
characters. Notably, characters are abstract entities of information,
independent of type font or language. The ISO 10646 (UNICODE
[http://www.unicode.org]) - or in Japan, JIS X0221 - is a globally
applicable character set that uniquely identifies all characters of
any language in the world.
In this specification, ISO 10646 serves as a semantic model for
character strings. The important point is that for semantic purposes,
there is no notion of separate character sets and switching between
character sets. Character set and character encoding are ITS layer
considerations. The formal definition gives indication to this effect
because each character is by itself an value that
has a charset property. Thus, the binary encoding of each character is
always understood in the context of a certain character set. This does
not mean that the ITS should represent a character string as a
sequence of full blown values. What it means is that
on the application layer the notion of character encoding is
irrelevant when we deal with character strings.
The length of a character string is the number of characters in the string.
The head of a string is a string of only one character. A character
string must at least have one character or else it is NULL. A
zero-length string is an exceptional value (NULL), not a proper
character string value.
The length of a string is the number of characters, not the number of
encoded bytes. Byte encoding is an ITS issue and is not relevant on
the application layer.
The following rules apply to whitespace contained within character strings:
TAB, space and end-of-line are all considered whitespace characters.
Both preceding and trailing whitespace is significant.
Different whitespace characters are not interchangable.
Different representations of end-of-line are normalised according to the
method described in the XML specification
[]
Sequences of whitespace cannot be compressed to shorter sequences.
type CharacterString alias ST specializes ED {
ST headCharacter;
ST tailString;
literal ST;
};
The character string data type stands for text data, primarily
intended for machine processing (e.g., sorting, querying, indexing,
etc.) Used for names, symbols, and formal expressions.
Requirement:
ST is a specialization of ED so that any RIM attribute which has the type
ED can be constrained to a ST. The most important case is Act.text, which is
an ED to cater for the use of references and multimedia data, but is often
constrained to plain text.
The character string is a restricted encapsulated data type ( ),
whose type property is fixed to text/plain, and whose data must be
inlined and not compressed. Thus, the properties compression, reference,
integrity check, algorithm, and thumbnail are not applicable. The character
string data type is used when the appearance of text does not bear meaning,
which is true for formalized text and all kinds of names.
The character string (ST) data type interprets the encapsulated data
as character data (as opposed to bits), depending on the charset
property of the encapsulated data type.
The headCharacter and tailString properties define ST as a sequence
of entities each of which uniquely identifies one character from the
joint set of all characters known by any language of the world.
ISO/IEC 10646-1: 1993 defines a character as "A member of a set of
elements used for the organization, control, or representation of
data." ISO/IEC TR 15285 - An operational model for characters and
glyphs. Discusses the problems involved in defining
characters. Notably, characters are abstract entities of information,
independent of type font or language. The ISO 10646 (UNICODE
[http://www.unicode.org]) - or in Japan, JIS X0221 - is a globally
applicable character set that uniquely identifies all characters of
any language in the world.
In this specification, ISO 10646 serves as a semantic model for
character strings. The important point is that for semantic purposes,
there is no notion of separate character sets and switching between
character sets. Character set and character encoding are ITS layer
considerations. The formal definition gives indication to this effect
because each character is by itself an value that
has a charset property. Thus, the binary encoding of each character is
always understood in the context of a certain character set. This does
not mean that the ITS should represent a character string as a
sequence of full blown values. What it means is that
on the application layer the notion of character encoding is
irrelevant when we deal with character strings.
The length of a character string is the number of characters in the string.
The head of a string is a string of only one character. A character
string must at least have one character or else it is NULL. A
zero-length string is an exceptional value (NULL), not a proper
character string value.
The length of a string is the number of characters, not the number of
encoded bytes. Byte encoding is an ITS issue and is not relevant on
the application layer.
The following rules apply to whitespace contained within character strings:
TAB, space and end-of-line are all considered whitespace characters.
Both preceding and trailing whitespace is significant.
Different whitespace characters are not interchangable.
Different representations of end-of-line are normalised according to the
method described in the XML specification
[]
Sequences of whitespace cannot be compressed to shorter sequences.
type CharacterString alias ST specializes ED {
ST headCharacter;
ST tailString;
literal ST;
};
The character string data type stands for text data, primarily
intended for machine processing (e.g., sorting, querying, indexing,
etc.) Used for names, symbols, and formal expressions.
Requirement:
ST is a specialization of ED so that any RIM attribute which has the type
ED can be constrained to a ST. The most important case is Act.text, which is
an ED to cater for the use of references and multimedia data, but is often
constrained to plain text.
The character string is a restricted encapsulated data type ( ),
whose type property is fixed to text/plain, and whose data must be
inlined and not compressed. Thus, the properties compression, reference,
integrity check, algorithm, and thumbnail are not applicable. The character
string data type is used when the appearance of text does not bear meaning,
which is true for formalized text and all kinds of names.
The character string (ST) data type interprets the encapsulated data
as character data (as opposed to bits), depending on the charset
property of the encapsulated data type.
The headCharacter and tailString properties define ST as a sequence
of entities each of which uniquely identifies one character from the
joint set of all characters known by any language of the world.
ISO/IEC 10646-1: 1993 defines a character as "A member of a set of
elements used for the organization, control, or representation of
data." ISO/IEC TR 15285 - An operational model for characters and
glyphs. Discusses the problems involved in defining
characters. Notably, characters are abstract entities of information,
independent of type font or language. The ISO 10646 (UNICODE
[http://www.unicode.org]) - or in Japan, JIS X0221 - is a globally
applicable character set that uniquely identifies all characters of
any language in the world.
In this specification, ISO 10646 serves as a semantic model for
character strings. The important point is that for semantic purposes,
there is no notion of separate character sets and switching between
character sets. Character set and character encoding are ITS layer
considerations. The formal definition gives indication to this effect
because each character is by itself an value that
has a charset property. Thus, the binary encoding of each character is
always understood in the context of a certain character set. This does
not mean that the ITS should represent a character string as a
sequence of full blown values. What it means is that
on the application layer the notion of character encoding is
irrelevant when we deal with character strings.
The length of a character string is the number of characters in the string.
The head of a string is a string of only one character. A character
string must at least have one character or else it is NULL. A
zero-length string is an exceptional value (NULL), not a proper
character string value.
The length of a string is the number of characters, not the number of
encoded bytes. Byte encoding is an ITS issue and is not relevant on
the application layer.
The following rules apply to whitespace contained within character strings:
TAB, space and end-of-line are all considered whitespace characters.
Both preceding and trailing whitespace is significant.
Different whitespace characters are not interchangable.
Different representations of end-of-line are normalised according to the
method described in the XML specification
[]
Sequences of whitespace cannot be compressed to shorter sequences.
type CharacterString alias ST specializes ED {
ST headCharacter;
ST tailString;
literal ST;
};
The character string data type stands for text data, primarily
intended for machine processing (e.g., sorting, querying, indexing,
etc.) Used for names, symbols, and formal expressions.
Requirement:
ST is a specialization of ED so that any RIM attribute which has the type
ED can be constrained to a ST. The most important case is Act.text, which is
an ED to cater for the use of references and multimedia data, but is often
constrained to plain text.
The character string is a restricted encapsulated data type ( ),
whose type property is fixed to text/plain, and whose data must be
inlined and not compressed. Thus, the properties compression, reference,
integrity check, algorithm, and thumbnail are not applicable. The character
string data type is used when the appearance of text does not bear meaning,
which is true for formalized text and all kinds of names.
The character string (ST) data type interprets the encapsulated data
as character data (as opposed to bits), depending on the charset
property of the encapsulated data type.
The headCharacter and tailString properties define ST as a sequence
of entities each of which uniquely identifies one character from the
joint set of all characters known by any language of the world.
ISO/IEC 10646-1: 1993 defines a character as "A member of a set of
elements used for the organization, control, or representation of
data." ISO/IEC TR 15285 - An operational model for characters and
glyphs. Discusses the problems involved in defining
characters. Notably, characters are abstract entities of information,
independent of type font or language. The ISO 10646 (UNICODE
[http://www.unicode.org]) - or in Japan, JIS X0221 - is a globally
applicable character set that uniquely identifies all characters of
any language in the world.
In this specification, ISO 10646 serves as a semantic model for
character strings. The important point is that for semantic purposes,
there is no notion of separate character sets and switching between
character sets. Character set and character encoding are ITS layer
considerations. The formal definition gives indication to this effect
because each character is by itself an value that
has a charset property. Thus, the binary encoding of each character is
always understood in the context of a certain character set. This does
not mean that the ITS should represent a character string as a
sequence of full blown values. What it means is that
on the application layer the notion of character encoding is
irrelevant when we deal with character strings.
The length of a character string is the number of characters in the string.
The head of a string is a string of only one character. A character
string must at least have one character or else it is NULL. A
zero-length string is an exceptional value (NULL), not a proper
character string value.
The length of a string is the number of characters, not the number of
encoded bytes. Byte encoding is an ITS issue and is not relevant on
the application layer.
The following rules apply to whitespace contained within character strings:
TAB, space and end-of-line are all considered whitespace characters.
Both preceding and trailing whitespace is significant.
Different whitespace characters are not interchangable.
Different representations of end-of-line are normalised according to the
method described in the XML specification
[]
Sequences of whitespace cannot be compressed to shorter sequences.
type CharacterString alias ST specializes ED {
ST headCharacter;
ST tailString;
literal ST;
};
The character string data type stands for text data, primarily
intended for machine processing (e.g., sorting, querying, indexing,
etc.) Used for names, symbols, and formal expressions.
Requirement:
ST is a specialization of ED so that any RIM attribute which has the type
ED can be constrained to a ST. The most important case is Act.text, which is
an ED to cater for the use of references and multimedia data, but is often
constrained to plain text.
The character string is a restricted encapsulated data type ( ),
whose type property is fixed to text/plain, and whose data must be
inlined and not compressed. Thus, the properties compression, reference,
integrity check, algorithm, and thumbnail are not applicable. The character
string data type is used when the appearance of text does not bear meaning,
which is true for formalized text and all kinds of names.
The character string (ST) data type interprets the encapsulated data
as character data (as opposed to bits), depending on the charset
property of the encapsulated data type.
The headCharacter and tailString properties define ST as a sequence
of entities each of which uniquely identifies one character from the
joint set of all characters known by any language of the world.
ISO/IEC 10646-1: 1993 defines a character as "A member of a set of
elements used for the organization, control, or representation of
data." ISO/IEC TR 15285 - An operational model for characters and
glyphs. Discusses the problems involved in defining
characters. Notably, characters are abstract entities of information,
independent of type font or language. The ISO 10646 (UNICODE
[http://www.unicode.org]) - or in Japan, JIS X0221 - is a globally
applicable character set that uniquely identifies all characters of
any language in the world.
In this specification, ISO 10646 serves as a semantic model for
character strings. The important point is that for semantic purposes,
there is no notion of separate character sets and switching between
character sets. Character set and character encoding are ITS layer
considerations. The formal definition gives indication to this effect
because each character is by itself an value that
has a charset property. Thus, the binary encoding of each character is
always understood in the context of a certain character set. This does
not mean that the ITS should represent a character string as a
sequence of full blown values. What it means is that
on the application layer the notion of character encoding is
irrelevant when we deal with character strings.
The length of a character string is the number of characters in the string.
The head of a string is a string of only one character. A character
string must at least have one character or else it is NULL. A
zero-length string is an exceptional value (NULL), not a proper
character string value.
The length of a string is the number of characters, not the number of
encoded bytes. Byte encoding is an ITS issue and is not relevant on
the application layer.
The following rules apply to whitespace contained within character strings:
TAB, space and end-of-line are all considered whitespace characters.
Both preceding and trailing whitespace is significant.
Different whitespace characters are not interchangable.
Different representations of end-of-line are normalised according to the
method described in the XML specification
[]
Sequences of whitespace cannot be compressed to shorter sequences.
type CharacterString alias ST specializes ED {
ST headCharacter;
ST tailString;
literal ST;
};
The character string data type stands for text data, primarily
intended for machine processing (e.g., sorting, querying, indexing,
etc.) Used for names, symbols, and formal expressions.
Requirement:
ST is a specialization of ED so that any RIM attribute which has the type
ED can be constrained to a ST. The most important case is Act.text, which is
an ED to cater for the use of references and multimedia data, but is often
constrained to plain text.
The character string is a restricted encapsulated data type ( ),
whose type property is fixed to text/plain, and whose data must be
inlined and not compressed. Thus, the properties compression, reference,
integrity check, algorithm, and thumbnail are not applicable. The character
string data type is used when the appearance of text does not bear meaning,
which is true for formalized text and all kinds of names.
The character string (ST) data type interprets the encapsulated data
as character data (as opposed to bits), depending on the charset
property of the encapsulated data type.
The headCharacter and tailString properties define ST as a sequence
of entities each of which uniquely identifies one character from the
joint set of all characters known by any language of the world.
ISO/IEC 10646-1: 1993 defines a character as "A member of a set of
elements used for the organization, control, or representation of
data." ISO/IEC TR 15285 - An operational model for characters and
glyphs. Discusses the problems involved in defining
characters. Notably, characters are abstract entities of information,
independent of type font or language. The ISO 10646 (UNICODE
[http://www.unicode.org]) - or in Japan, JIS X0221 - is a globally
applicable character set that uniquely identifies all characters of
any language in the world.
In this specification, ISO 10646 serves as a semantic model for
character strings. The important point is that for semantic purposes,
there is no notion of separate character sets and switching between
character sets. Character set and character encoding are ITS layer
considerations. The formal definition gives indication to this effect
because each character is by itself an value that
has a charset property. Thus, the binary encoding of each character is
always understood in the context of a certain character set. This does
not mean that the ITS should represent a character string as a
sequence of full blown values. What it means is that
on the application layer the notion of character encoding is
irrelevant when we deal with character strings.
The length of a character string is the number of characters in the string.
The head of a string is a string of only one character. A character
string must at least have one character or else it is NULL. A
zero-length string is an exceptional value (NULL), not a proper
character string value.
The length of a string is the number of characters, not the number of
encoded bytes. Byte encoding is an ITS issue and is not relevant on
the application layer.
The following rules apply to whitespace contained within character strings:
TAB, space and end-of-line are all considered whitespace characters.
Both preceding and trailing whitespace is significant.
Different whitespace characters are not interchangable.
Different representations of end-of-line are normalised according to the
method described in the XML specification
[]
Sequences of whitespace cannot be compressed to shorter sequences.
type CharacterString alias ST specializes ED {
ST headCharacter;
ST tailString;
literal ST;
};
The character string data type stands for text data, primarily
intended for machine processing (e.g., sorting, querying, indexing,
etc.) Used for names, symbols, and formal expressions.
Requirement:
ST is a specialization of ED so that any RIM attribute which has the type
ED can be constrained to a ST. The most important case is Act.text, which is
an ED to cater for the use of references and multimedia data, but is often
constrained to plain text.
The character string is a restricted encapsulated data type ( ),
whose type property is fixed to text/plain, and whose data must be
inlined and not compressed. Thus, the properties compression, reference,
integrity check, algorithm, and thumbnail are not applicable. The character
string data type is used when the appearance of text does not bear meaning,
which is true for formalized text and all kinds of names.
The character string (ST) data type interprets the encapsulated data
as character data (as opposed to bits), depending on the charset
property of the encapsulated data type.
The headCharacter and tailString properties define ST as a sequence
of entities each of which uniquely identifies one character from the
joint set of all characters known by any language of the world.
ISO/IEC 10646-1: 1993 defines a character as "A member of a set of
elements used for the organization, control, or representation of
data." ISO/IEC TR 15285 - An operational model for characters and
glyphs. Discusses the problems involved in defining
characters. Notably, characters are abstract entities of information,
independent of type font or language. The ISO 10646 (UNICODE
[http://www.unicode.org]) - or in Japan, JIS X0221 - is a globally
applicable character set that uniquely identifies all characters of
any language in the world.
In this specification, ISO 10646 serves as a semantic model for
character strings. The important point is that for semantic purposes,
there is no notion of separate character sets and switching between
character sets. Character set and character encoding are ITS layer
considerations. The formal definition gives indication to this effect
because each character is by itself an value that
has a charset property. Thus, the binary encoding of each character is
always understood in the context of a certain character set. This does
not mean that the ITS should represent a character string as a
sequence of full blown values. What it means is that
on the application layer the notion of character encoding is
irrelevant when we deal with character strings.
The length of a character string is the number of characters in the string.
The head of a string is a string of only one character. A character
string must at least have one character or else it is NULL. A
zero-length string is an exceptional value (NULL), not a proper
character string value.
The length of a string is the number of characters, not the number of
encoded bytes. Byte encoding is an ITS issue and is not relevant on
the application layer.
The following rules apply to whitespace contained within character strings:
TAB, space and end-of-line are all considered whitespace characters.
Both preceding and trailing whitespace is significant.
Different whitespace characters are not interchangable.
Different representations of end-of-line are normalised according to the
method described in the XML specification
[]
Sequences of whitespace cannot be compressed to shorter sequences.
type CharacterString alias ST specializes ED {
ST headCharacter;
ST tailString;
literal ST;
};
The character string data type stands for text data, primarily
intended for machine processing (e.g., sorting, querying, indexing,
etc.) Used for names, symbols, and formal expressions.
Requirement:
ST is a specialization of ED so that any RIM attribute which has the type
ED can be constrained to a ST. The most important case is Act.text, which is
an ED to cater for the use of references and multimedia data, but is often
constrained to plain text.
The character string is a restricted encapsulated data type ( ),
whose type property is fixed to text/plain, and whose data must be
inlined and not compressed. Thus, the properties compression, reference,
integrity check, algorithm, and thumbnail are not applicable. The character
string data type is used when the appearance of text does not bear meaning,
which is true for formalized text and all kinds of names.
The character string (ST) data type interprets the encapsulated data
as character data (as opposed to bits), depending on the charset
property of the encapsulated data type.
The headCharacter and tailString properties define ST as a sequence
of entities each of which uniquely identifies one character from the
joint set of all characters known by any language of the world.
ISO/IEC 10646-1: 1993 defines a character as "A member of a set of
elements used for the organization, control, or representation of
data." ISO/IEC TR 15285 - An operational model for characters and
glyphs. Discusses the problems involved in defining
characters. Notably, characters are abstract entities of information,
independent of type font or language. The ISO 10646 (UNICODE
[http://www.unicode.org]) - or in Japan, JIS X0221 - is a globally
applicable character set that uniquely identifies all characters of
any language in the world.
In this specification, ISO 10646 serves as a semantic model for
character strings. The important point is that for semantic purposes,
there is no notion of separate character sets and switching between
character sets. Character set and character encoding are ITS layer
considerations. The formal definition gives indication to this effect
because each character is by itself an value that
has a charset property. Thus, the binary encoding of each character is
always understood in the context of a certain character set. This does
not mean that the ITS should represent a character string as a
sequence of full blown values. What it means is that
on the application layer the notion of character encoding is
irrelevant when we deal with character strings.
The length of a character string is the number of characters in the string.
The head of a string is a string of only one character. A character
string must at least have one character or else it is NULL. A
zero-length string is an exceptional value (NULL), not a proper
character string value.
The length of a string is the number of characters, not the number of
encoded bytes. Byte encoding is an ITS issue and is not relevant on
the application layer.
The following rules apply to whitespace contained within character strings:
TAB, space and end-of-line are all considered whitespace characters.
Both preceding and trailing whitespace is significant.
Different whitespace characters are not interchangable.
Different representations of end-of-line are normalised according to the
method described in the XML specification
[]
Sequences of whitespace cannot be compressed to shorter sequences.
type CharacterString alias ST specializes ED {
ST headCharacter;
ST tailString;
literal ST;
};
CD (ConceptDescriptor)
A concept descriptor represents any kind of concept usually by
giving a code defined in a code system.
A concept descriptor can contain the original text or phrase that
served as the basis of the coding and one or more translations into
different coding systems.
A concept descriptor can also contain qualifiers to describe, e.g., the
concept of a "left foot" as a postcoordinated term built from the
primary code "FOOT" and the qualifier "LEFT".
In cases of an exceptional value, the concept descriptor need not contain a code
but only the original text describing that concept.
The concept descriptor is mostly used in one of its restricted or
'profiled' forms, CS, CE, CV.
Use of the full concept descriptor data type is not common. It
requires a conscious decision and documented rationale. In all other
cases, one of the restrictions shall be
used.
The advantage of the concept descriptor data type is its expressiveness,
however, if all of its features, such as coding exceptions, text, translations
and qualifiers are used at all times, implementation and use become very
difficult and unsafe. Therefore, the type is most often
used in a restricted form with reduced features.
All restrictions constrain certain properties of the
. Properties may be constrained to the extent that
only one value may be allowed for that property, in which case
mentioning the property becomes redundant. Constraining a property to
one value is referred to as suppressing that property. Although,
conceptually a suppressed property is still semantically applicable,
it is safe for an HL7 interface to assume the implicit default value
without testing.
type ConceptDescriptor alias CD specializes ANY {
ST code;
UID codeSystem;
ST codeSystemName;
ST codeSystemVersion;
ST displayName;
ED originalText;
SET<CD> translation;
LIST<CR> qualifier;
BL implies(CD x);
};
A concept descriptor represents any kind of concept usually by
giving a code defined in a code system.
A concept descriptor can contain the original text or phrase that
served as the basis of the coding and one or more translations into
different coding systems.
A concept descriptor can also contain qualifiers to describe, e.g., the
concept of a "left foot" as a postcoordinated term built from the
primary code "FOOT" and the qualifier "LEFT".
In cases of an exceptional value, the concept descriptor need not contain a code
but only the original text describing that concept.
The concept descriptor is mostly used in one of its restricted or
'profiled' forms, CS, CE, CV.
Use of the full concept descriptor data type is not common. It
requires a conscious decision and documented rationale. In all other
cases, one of the restrictions shall be
used.
The advantage of the concept descriptor data type is its expressiveness,
however, if all of its features, such as coding exceptions, text, translations
and qualifiers are used at all times, implementation and use become very
difficult and unsafe. Therefore, the type is most often
used in a restricted form with reduced features.
All restrictions constrain certain properties of the
. Properties may be constrained to the extent that
only one value may be allowed for that property, in which case
mentioning the property becomes redundant. Constraining a property to
one value is referred to as suppressing that property. Although,
conceptually a suppressed property is still semantically applicable,
it is safe for an HL7 interface to assume the implicit default value
without testing.
type ConceptDescriptor alias CD specializes ANY {
ST code;
UID codeSystem;
ST codeSystemName;
ST codeSystemVersion;
ST displayName;
ED originalText;
SET<CD> translation;
LIST<CR> qualifier;
BL implies(CD x);
};
A concept descriptor represents any kind of concept usually by
giving a code defined in a code system.
A concept descriptor can contain the original text or phrase that
served as the basis of the coding and one or more translations into
different coding systems.
A concept descriptor can also contain qualifiers to describe, e.g., the
concept of a "left foot" as a postcoordinated term built from the
primary code "FOOT" and the qualifier "LEFT".
In cases of an exceptional value, the concept descriptor need not contain a code
but only the original text describing that concept.
The concept descriptor is mostly used in one of its restricted or
'profiled' forms, CS, CE, CV.
Use of the full concept descriptor data type is not common. It
requires a conscious decision and documented rationale. In all other
cases, one of the restrictions shall be
used.
The advantage of the concept descriptor data type is its expressiveness,
however, if all of its features, such as coding exceptions, text, translations
and qualifiers are used at all times, implementation and use become very
difficult and unsafe. Therefore, the type is most often
used in a restricted form with reduced features.
All restrictions constrain certain properties of the
. Properties may be constrained to the extent that
only one value may be allowed for that property, in which case
mentioning the property becomes redundant. Constraining a property to
one value is referred to as suppressing that property. Although,
conceptually a suppressed property is still semantically applicable,
it is safe for an HL7 interface to assume the implicit default value
without testing.
type ConceptDescriptor alias CD specializes ANY {
ST code;
UID codeSystem;
ST codeSystemName;
ST codeSystemVersion;
ST displayName;
ED originalText;
SET<CD> translation;
LIST<CR> qualifier;
BL implies(CD x);
};
A concept descriptor represents any kind of concept usually by
giving a code defined in a code system.
A concept descriptor can contain the original text or phrase that
served as the basis of the coding and one or more translations into
different coding systems.
A concept descriptor can also contain qualifiers to describe, e.g., the
concept of a "left foot" as a postcoordinated term built from the
primary code "FOOT" and the qualifier "LEFT".
In cases of an exceptional value, the concept descriptor need not contain a code
but only the original text describing that concept.
The concept descriptor is mostly used in one of its restricted or
'profiled' forms, CS, CE, CV.
Use of the full concept descriptor data type is not common. It
requires a conscious decision and documented rationale. In all other
cases, one of the restrictions shall be
used.
The advantage of the concept descriptor data type is its expressiveness,
however, if all of its features, such as coding exceptions, text, translations
and qualifiers are used at all times, implementation and use become very
difficult and unsafe. Therefore, the type is most often
used in a restricted form with reduced features.
All restrictions constrain certain properties of the
. Properties may be constrained to the extent that
only one value may be allowed for that property, in which case
mentioning the property becomes redundant. Constraining a property to
one value is referred to as suppressing that property. Although,
conceptually a suppressed property is still semantically applicable,
it is safe for an HL7 interface to assume the implicit default value
without testing.
type ConceptDescriptor alias CD specializes ANY {
ST code;
UID codeSystem;
ST codeSystemName;
ST codeSystemVersion;
ST displayName;
ED originalText;
SET<CD> translation;
LIST<CR> qualifier;
BL implies(CD x);
};
A concept descriptor represents any kind of concept usually by
giving a code defined in a code system.
A concept descriptor can contain the original text or phrase that
served as the basis of the coding and one or more translations into
different coding systems.
A concept descriptor can also contain qualifiers to describe, e.g., the
concept of a "left foot" as a postcoordinated term built from the
primary code "FOOT" and the qualifier "LEFT".
In cases of an exceptional value, the concept descriptor need not contain a code
but only the original text describing that concept.
The concept descriptor is mostly used in one of its restricted or
'profiled' forms, CS, CE, CV.
Use of the full concept descriptor data type is not common. It
requires a conscious decision and documented rationale. In all other
cases, one of the restrictions shall be
used.
The advantage of the concept descriptor data type is its expressiveness,
however, if all of its features, such as coding exceptions, text, translations
and qualifiers are used at all times, implementation and use become very
difficult and unsafe. Therefore, the type is most often
used in a restricted form with reduced features.
All restrictions constrain certain properties of the
. Properties may be constrained to the extent that
only one value may be allowed for that property, in which case
mentioning the property becomes redundant. Constraining a property to
one value is referred to as suppressing that property. Although,
conceptually a suppressed property is still semantically applicable,
it is safe for an HL7 interface to assume the implicit default value
without testing.
type ConceptDescriptor alias CD specializes ANY {
ST code;
UID codeSystem;
ST codeSystemName;
ST codeSystemVersion;
ST displayName;
ED originalText;
SET<CD> translation;
LIST<CR> qualifier;
BL implies(CD x);
};
A concept descriptor represents any kind of concept usually by
giving a code defined in a code system.
A concept descriptor can contain the original text or phrase that
served as the basis of the coding and one or more translations into
different coding systems.
A concept descriptor can also contain qualifiers to describe, e.g., the
concept of a "left foot" as a postcoordinated term built from the
primary code "FOOT" and the qualifier "LEFT".
In cases of an exceptional value, the concept descriptor need not contain a code
but only the original text describing that concept.
The concept descriptor is mostly used in one of its restricted or
'profiled' forms, CS, CE, CV.
Use of the full concept descriptor data type is not common. It
requires a conscious decision and documented rationale. In all other
cases, one of the restrictions shall be
used.
The advantage of the concept descriptor data type is its expressiveness,
however, if all of its features, such as coding exceptions, text, translations
and qualifiers are used at all times, implementation and use become very
difficult and unsafe. Therefore, the type is most often
used in a restricted form with reduced features.
All restrictions constrain certain properties of the
. Properties may be constrained to the extent that
only one value may be allowed for that property, in which case
mentioning the property becomes redundant. Constraining a property to
one value is referred to as suppressing that property. Although,
conceptually a suppressed property is still semantically applicable,
it is safe for an HL7 interface to assume the implicit default value
without testing.
type ConceptDescriptor alias CD specializes ANY {
ST code;
UID codeSystem;
ST codeSystemName;
ST codeSystemVersion;
ST displayName;
ED originalText;
SET<CD> translation;
LIST<CR> qualifier;
BL implies(CD x);
};
A concept descriptor represents any kind of concept usually by
giving a code defined in a code system.
A concept descriptor can contain the original text or phrase that
served as the basis of the coding and one or more translations into
different coding systems.
A concept descriptor can also contain qualifiers to describe, e.g., the
concept of a "left foot" as a postcoordinated term built from the
primary code "FOOT" and the qualifier "LEFT".
In cases of an exceptional value, the concept descriptor need not contain a code
but only the original text describing that concept.
The concept descriptor is mostly used in one of its restricted or
'profiled' forms, CS, CE, CV.
Use of the full concept descriptor data type is not common. It
requires a conscious decision and documented rationale. In all other
cases, one of the restrictions shall be
used.
The advantage of the concept descriptor data type is its expressiveness,
however, if all of its features, such as coding exceptions, text, translations
and qualifiers are used at all times, implementation and use become very
difficult and unsafe. Therefore, the type is most often
used in a restricted form with reduced features.
All restrictions constrain certain properties of the
. Properties may be constrained to the extent that
only one value may be allowed for that property, in which case
mentioning the property becomes redundant. Constraining a property to
one value is referred to as suppressing that property. Although,
conceptually a suppressed property is still semantically applicable,
it is safe for an HL7 interface to assume the implicit default value
without testing.
type ConceptDescriptor alias CD specializes ANY {
ST code;
UID codeSystem;
ST codeSystemName;
ST codeSystemVersion;
ST displayName;
ED originalText;
SET<CD> translation;
LIST<CR> qualifier;
BL implies(CD x);
};
A concept descriptor represents any kind of concept usually by
giving a code defined in a code system.
A concept descriptor can contain the original text or phrase that
served as the basis of the coding and one or more translations into
different coding systems.
A concept descriptor can also contain qualifiers to describe, e.g., the
concept of a "left foot" as a postcoordinated term built from the
primary code "FOOT" and the qualifier "LEFT".
In cases of an exceptional value, the concept descriptor need not contain a code
but only the original text describing that concept.
The concept descriptor is mostly used in one of its restricted or
'profiled' forms, CS, CE, CV.
Use of the full concept descriptor data type is not common. It
requires a conscious decision and documented rationale. In all other
cases, one of the restrictions shall be
used.
The advantage of the concept descriptor data type is its expressiveness,
however, if all of its features, such as coding exceptions, text, translations
and qualifiers are used at all times, implementation and use become very
difficult and unsafe. Therefore, the type is most often
used in a restricted form with reduced features.
All restrictions constrain certain properties of the
. Properties may be constrained to the extent that
only one value may be allowed for that property, in which case
mentioning the property becomes redundant. Constraining a property to
one value is referred to as suppressing that property. Although,
conceptually a suppressed property is still semantically applicable,
it is safe for an HL7 interface to assume the implicit default value
without testing.
type ConceptDescriptor alias CD specializes ANY {
ST code;
UID codeSystem;
ST codeSystemName;
ST codeSystemVersion;
ST displayName;
ED originalText;
SET<CD> translation;
LIST<CR> qualifier;
BL implies(CD x);
};
A concept descriptor represents any kind of concept usually by
giving a code defined in a code system.
A concept descriptor can contain the original text or phrase that
served as the basis of the coding and one or more translations into
different coding systems.
A concept descriptor can also contain qualifiers to describe, e.g., the
concept of a "left foot" as a postcoordinated term built from the
primary code "FOOT" and the qualifier "LEFT".
In cases of an exceptional value, the concept descriptor need not contain a code
but only the original text describing that concept.
The concept descriptor is mostly used in one of its restricted or
'profiled' forms, CS, CE, CV.
Use of the full concept descriptor data type is not common. It
requires a conscious decision and documented rationale. In all other
cases, one of the restrictions shall be
used.
The advantage of the concept descriptor data type is its expressiveness,
however, if all of its features, such as coding exceptions, text, translations
and qualifiers are used at all times, implementation and use become very
difficult and unsafe. Therefore, the type is most often
used in a restricted form with reduced features.
All restrictions constrain certain properties of the
. Properties may be constrained to the extent that
only one value may be allowed for that property, in which case
mentioning the property becomes redundant. Constraining a property to
one value is referred to as suppressing that property. Although,
conceptually a suppressed property is still semantically applicable,
it is safe for an HL7 interface to assume the implicit default value
without testing.
type ConceptDescriptor alias CD specializes ANY {
ST code;
UID codeSystem;
ST codeSystemName;
ST codeSystemVersion;
ST displayName;
ED originalText;
SET<CD> translation;
LIST<CR> qualifier;
BL implies(CD x);
};
A concept descriptor represents any kind of concept usually by
giving a code defined in a code system.
A concept descriptor can contain the original text or phrase that
served as the basis of the coding and one or more translations into
different coding systems.
A concept descriptor can also contain qualifiers to describe, e.g., the
concept of a "left foot" as a postcoordinated term built from the
primary code "FOOT" and the qualifier "LEFT".
In cases of an exceptional value, the concept descriptor need not contain a code
but only the original text describing that concept.
The concept descriptor is mostly used in one of its restricted or
'profiled' forms, CS, CE, CV.
Use of the full concept descriptor data type is not common. It
requires a conscious decision and documented rationale. In all other
cases, one of the restrictions shall be
used.
The advantage of the concept descriptor data type is its expressiveness,
however, if all of its features, such as coding exceptions, text, translations
and qualifiers are used at all times, implementation and use become very
difficult and unsafe. Therefore, the type is most often
used in a restricted form with reduced features.
All restrictions constrain certain properties of the
. Properties may be constrained to the extent that
only one value may be allowed for that property, in which case
mentioning the property becomes redundant. Constraining a property to
one value is referred to as suppressing that property. Although,
conceptually a suppressed property is still semantically applicable,
it is safe for an HL7 interface to assume the implicit default value
without testing.
type ConceptDescriptor alias CD specializes ANY {
ST code;
UID codeSystem;
ST codeSystemName;
ST codeSystemVersion;
ST displayName;
ED originalText;
SET<CD> translation;
LIST<CR> qualifier;
BL implies(CD x);
};
A concept descriptor represents any kind of concept usually by
giving a code defined in a code system.
A concept descriptor can contain the original text or phrase that
served as the basis of the coding and one or more translations into
different coding systems.
A concept descriptor can also contain qualifiers to describe, e.g., the
concept of a "left foot" as a postcoordinated term built from the
primary code "FOOT" and the qualifier "LEFT".
In cases of an exceptional value, the concept descriptor need not contain a code
but only the original text describing that concept.
The concept descriptor is mostly used in one of its restricted or
'profiled' forms, CS, CE, CV.
Use of the full concept descriptor data type is not common. It
requires a conscious decision and documented rationale. In all other
cases, one of the restrictions shall be
used.
The advantage of the concept descriptor data type is its expressiveness,
however, if all of its features, such as coding exceptions, text, translations
and qualifiers are used at all times, implementation and use become very
difficult and unsafe. Therefore, the type is most often
used in a restricted form with reduced features.
All restrictions constrain certain properties of the
. Properties may be constrained to the extent that
only one value may be allowed for that property, in which case
mentioning the property becomes redundant. Constraining a property to
one value is referred to as suppressing that property. Although,
conceptually a suppressed property is still semantically applicable,
it is safe for an HL7 interface to assume the implicit default value
without testing.
type ConceptDescriptor alias CD specializes ANY {
ST code;
UID codeSystem;
ST codeSystemName;
ST codeSystemVersion;
ST displayName;
ED originalText;
SET<CD> translation;
LIST<CR> qualifier;
BL implies(CD x);
};
CR (ConceptRole)
A concept qualifier code with optionally named role. Both qualifier
role and value codes must be defined by the coding system of the CD containing
the concept qualifier. For example, if SNOMED RT defines a concept "leg", a
role relation "has-laterality", and another concept "left", the concept role
relation allows to add the qualifier "has-laterality: left" to a
primary code "leg" to construct the meaning "left leg".
The use of qualifiers is strictly governed by the code system
used. The data type does not permit using code
qualifiers with code systems that do not provide for qualifiers
(e.g. pre-coordinated systems, such as LOINC, ICD-10 PCS.)
protected type ConceptRole alias CR specializes ANY {
CV name;
CD value;
BN inverted;
};
A concept qualifier code with optionally named role. Both qualifier
role and value codes must be defined by the coding system of the CD containing
the concept qualifier. For example, if SNOMED RT defines a concept "leg", a
role relation "has-laterality", and another concept "left", the concept role
relation allows to add the qualifier "has-laterality: left" to a
primary code "leg" to construct the meaning "left leg".
The use of qualifiers is strictly governed by the code system
used. The data type does not permit using code
qualifiers with code systems that do not provide for qualifiers
(e.g. pre-coordinated systems, such as LOINC, ICD-10 PCS.)
protected type ConceptRole alias CR specializes ANY {
CV name;
CD value;
BN inverted;
};
A concept qualifier code with optionally named role. Both qualifier
role and value codes must be defined by the coding system of the CD containing
the concept qualifier. For example, if SNOMED RT defines a concept "leg", a
role relation "has-laterality", and another concept "left", the concept role
relation allows to add the qualifier "has-laterality: left" to a
primary code "leg" to construct the meaning "left leg".
The use of qualifiers is strictly governed by the code system
used. The data type does not permit using code
qualifiers with code systems that do not provide for qualifiers
(e.g. pre-coordinated systems, such as LOINC, ICD-10 PCS.)
protected type ConceptRole alias CR specializes ANY {
CV name;
CD value;
BN inverted;
};
A concept qualifier code with optionally named role. Both qualifier
role and value codes must be defined by the coding system of the CD containing
the concept qualifier. For example, if SNOMED RT defines a concept "leg", a
role relation "has-laterality", and another concept "left", the concept role
relation allows to add the qualifier "has-laterality: left" to a
primary code "leg" to construct the meaning "left leg".
The use of qualifiers is strictly governed by the code system
used. The data type does not permit using code
qualifiers with code systems that do not provide for qualifiers
(e.g. pre-coordinated systems, such as LOINC, ICD-10 PCS.)
protected type ConceptRole alias CR specializes ANY {
CV name;
CD value;
BN inverted;
};
CS (CodedSimpleValue)
XCoded data in its simplest form, where only the code is not predetermined.
The code system and code system version are fixed by the context in which
the CS value occurs. CS is used for coded attributes that have a single
HL7-defined value set.
can only be used in either of the following
cases:
for a coded attribute which has a single HL7-defined code system, and
where code additions to that value set require formal HL7 action (such
as harmonization.) Such coded attributes must be assigned the
restriction.
for a property in this specification that is assigned to a single code
system defined either in this specification or defined outside HL7 by a body
that has authority over the concept and the maintenance of that code system.
For example, since the type subscribes to the MIME
design, it trusts IETF to manage the media type. This includes that this
specification subscribes to the extension mechanism built into the MIME media
type code (e.g., "application/x-myapp").
For values, the designation of the domain qualifier
will always be CNE (coded, non-extensible) and the
context will determine which HL7 values to use.
This is not withstanding the fact that an external referenced domain,
such as the IETF MIME media type may include an extension
mechanism. These extended MIME type codes would not be considered
"extensions" in the sense of violating the CNE provision. The CNE
provision is only violated if an attempt is made in using a different
code system (by means of the CD.codeSystem property), which is not
possible with the data type.
type CodedSimpleValue alias CS specializes CV {
literal ST;
};
XCoded data in its simplest form, where only the code is not predetermined.
The code system and code system version are fixed by the context in which
the CS value occurs. CS is used for coded attributes that have a single
HL7-defined value set.
can only be used in either of the following
cases:
for a coded attribute which has a single HL7-defined code system, and
where code additions to that value set require formal HL7 action (such
as harmonization.) Such coded attributes must be assigned the
restriction.
for a property in this specification that is assigned to a single code
system defined either in this specification or defined outside HL7 by a body
that has authority over the concept and the maintenance of that code system.
For example, since the type subscribes to the MIME
design, it trusts IETF to manage the media type. This includes that this
specification subscribes to the extension mechanism built into the MIME media
type code (e.g., "application/x-myapp").
For values, the designation of the domain qualifier
will always be CNE (coded, non-extensible) and the
context will determine which HL7 values to use.
This is not withstanding the fact that an external referenced domain,
such as the IETF MIME media type may include an extension
mechanism. These extended MIME type codes would not be considered
"extensions" in the sense of violating the CNE provision. The CNE
provision is only violated if an attempt is made in using a different
code system (by means of the CD.codeSystem property), which is not
possible with the data type.
type CodedSimpleValue alias CS specializes CV {
literal ST;
};
XCoded data in its simplest form, where only the code is not predetermined.
The code system and code system version are fixed by the context in which
the CS value occurs. CS is used for coded attributes that have a single
HL7-defined value set.
can only be used in either of the following
cases:
for a coded attribute which has a single HL7-defined code system, and
where code additions to that value set require formal HL7 action (such
as harmonization.) Such coded attributes must be assigned the
restriction.
for a property in this specification that is assigned to a single code
system defined either in this specification or defined outside HL7 by a body
that has authority over the concept and the maintenance of that code system.
For example, since the type subscribes to the MIME
design, it trusts IETF to manage the media type. This includes that this
specification subscribes to the extension mechanism built into the MIME media
type code (e.g., "application/x-myapp").
For values, the designation of the domain qualifier
will always be CNE (coded, non-extensible) and the
context will determine which HL7 values to use.
This is not withstanding the fact that an external referenced domain,
such as the IETF MIME media type may include an extension
mechanism. These extended MIME type codes would not be considered
"extensions" in the sense of violating the CNE provision. The CNE
provision is only violated if an attempt is made in using a different
code system (by means of the CD.codeSystem property), which is not
possible with the data type.
type CodedSimpleValue alias CS specializes CV {
literal ST;
};
XCoded data in its simplest form, where only the code is not predetermined.
The code system and code system version are fixed by the context in which
the CS value occurs. CS is used for coded attributes that have a single
HL7-defined value set.
can only be used in either of the following
cases:
for a coded attribute which has a single HL7-defined code system, and
where code additions to that value set require formal HL7 action (such
as harmonization.) Such coded attributes must be assigned the
restriction.
for a property in this specification that is assigned to a single code
system defined either in this specification or defined outside HL7 by a body
that has authority over the concept and the maintenance of that code system.
For example, since the type subscribes to the MIME
design, it trusts IETF to manage the media type. This includes that this
specification subscribes to the extension mechanism built into the MIME media
type code (e.g., "application/x-myapp").
For values, the designation of the domain qualifier
will always be CNE (coded, non-extensible) and the
context will determine which HL7 values to use.
This is not withstanding the fact that an external referenced domain,
such as the IETF MIME media type may include an extension
mechanism. These extended MIME type codes would not be considered
"extensions" in the sense of violating the CNE provision. The CNE
provision is only violated if an attempt is made in using a different
code system (by means of the CD.codeSystem property), which is not
possible with the data type.
type CodedSimpleValue alias CS specializes CV {
literal ST;
};
XCoded data in its simplest form, where only the code is not predetermined.
The code system and code system version are fixed by the context in which
the CS value occurs. CS is used for coded attributes that have a single
HL7-defined value set.
can only be used in either of the following
cases:
for a coded attribute which has a single HL7-defined code system, and
where code additions to that value set require formal HL7 action (such
as harmonization.) Such coded attributes must be assigned the
restriction.
for a property in this specification that is assigned to a single code
system defined either in this specification or defined outside HL7 by a body
that has authority over the concept and the maintenance of that code system.
For example, since the type subscribes to the MIME
design, it trusts IETF to manage the media type. This includes that this
specification subscribes to the extension mechanism built into the MIME media
type code (e.g., "application/x-myapp").
For values, the designation of the domain qualifier
will always be CNE (coded, non-extensible) and the
context will determine which HL7 values to use.
This is not withstanding the fact that an external referenced domain,
such as the IETF MIME media type may include an extension
mechanism. These extended MIME type codes would not be considered
"extensions" in the sense of violating the CNE provision. The CNE
provision is only violated if an attempt is made in using a different
code system (by means of the CD.codeSystem property), which is not
possible with the data type.
type CodedSimpleValue alias CS specializes CV {
literal ST;
};
XCoded data in its simplest form, where only the code is not predetermined.
The code system and code system version are fixed by the context in which
the CS value occurs. CS is used for coded attributes that have a single
HL7-defined value set.
can only be used in either of the following
cases:
for a coded attribute which has a single HL7-defined code system, and
where code additions to that value set require formal HL7 action (such
as harmonization.) Such coded attributes must be assigned the
restriction.
for a property in this specification that is assigned to a single code
system defined either in this specification or defined outside HL7 by a body
that has authority over the concept and the maintenance of that code system.
For example, since the type subscribes to the MIME
design, it trusts IETF to manage the media type. This includes that this
specification subscribes to the extension mechanism built into the MIME media
type code (e.g., "application/x-myapp").
For values, the designation of the domain qualifier
will always be CNE (coded, non-extensible) and the
context will determine which HL7 values to use.
This is not withstanding the fact that an external referenced domain,
such as the IETF MIME media type may include an extension
mechanism. These extended MIME type codes would not be considered
"extensions" in the sense of violating the CNE provision. The CNE
provision is only violated if an attempt is made in using a different
code system (by means of the CD.codeSystem property), which is not
possible with the data type.
type CodedSimpleValue alias CS specializes CV {
literal ST;
};
XCoded data in its simplest form, where only the code is not predetermined.
The code system and code system version are fixed by the context in which
the CS value occurs. CS is used for coded attributes that have a single
HL7-defined value set.
can only be used in either of the following
cases:
for a coded attribute which has a single HL7-defined code system, and
where code additions to that value set require formal HL7 action (such
as harmonization.) Such coded attributes must be assigned the
restriction.
for a property in this specification that is assigned to a single code
system defined either in this specification or defined outside HL7 by a body
that has authority over the concept and the maintenance of that code system.
For example, since the type subscribes to the MIME
design, it trusts IETF to manage the media type. This includes that this
specification subscribes to the extension mechanism built into the MIME media
type code (e.g., "application/x-myapp").
For values, the designation of the domain qualifier
will always be CNE (coded, non-extensible) and the
context will determine which HL7 values to use.
This is not withstanding the fact that an external referenced domain,
such as the IETF MIME media type may include an extension
mechanism. These extended MIME type codes would not be considered
"extensions" in the sense of violating the CNE provision. The CNE
provision is only violated if an attempt is made in using a different
code system (by means of the CD.codeSystem property), which is not
possible with the data type.
type CodedSimpleValue alias CS specializes CV {
literal ST;
};
XCoded data in its simplest form, where only the code is not predetermined.
The code system and code system version are fixed by the context in which
the CS value occurs. CS is used for coded attributes that have a single
HL7-defined value set.
can only be used in either of the following
cases:
for a coded attribute which has a single HL7-defined code system, and
where code additions to that value set require formal HL7 action (such
as harmonization.) Such coded attributes must be assigned the
restriction.
for a property in this specification that is assigned to a single code
system defined either in this specification or defined outside HL7 by a body
that has authority over the concept and the maintenance of that code system.
For example, since the type subscribes to the MIME
design, it trusts IETF to manage the media type. This includes that this
specification subscribes to the extension mechanism built into the MIME media
type code (e.g., "application/x-myapp").
For values, the designation of the domain qualifier
will always be CNE (coded, non-extensible) and the
context will determine which HL7 values to use.
This is not withstanding the fact that an external referenced domain,
such as the IETF MIME media type may include an extension
mechanism. These extended MIME type codes would not be considered
"extensions" in the sense of violating the CNE provision. The CNE
provision is only violated if an attempt is made in using a different
code system (by means of the CD.codeSystem property), which is not
possible with the data type.
type CodedSimpleValue alias CS specializes CV {
literal ST;
};
XCoded data in its simplest form, where only the code is not predetermined.
The code system and code system version are fixed by the context in which
the CS value occurs. CS is used for coded attributes that have a single
HL7-defined value set.
can only be used in either of the following
cases:
for a coded attribute which has a single HL7-defined code system, and
where code additions to that value set require formal HL7 action (such
as harmonization.) Such coded attributes must be assigned the
restriction.
for a property in this specification that is assigned to a single code
system defined either in this specification or defined outside HL7 by a body
that has authority over the concept and the maintenance of that code system.
For example, since the type subscribes to the MIME
design, it trusts IETF to manage the media type. This includes that this
specification subscribes to the extension mechanism built into the MIME media
type code (e.g., "application/x-myapp").
For values, the designation of the domain qualifier
will always be CNE (coded, non-extensible) and the
context will determine which HL7 values to use.
This is not withstanding the fact that an external referenced domain,
such as the IETF MIME media type may include an extension
mechanism. These extended MIME type codes would not be considered
"extensions" in the sense of violating the CNE provision. The CNE
provision is only violated if an attempt is made in using a different
code system (by means of the CD.codeSystem property), which is not
possible with the data type.
type CodedSimpleValue alias CS specializes CV {
literal ST;
};
XCoded data in its simplest form, where only the code is not predetermined.
The code system and code system version are fixed by the context in which
the CS value occurs. CS is used for coded attributes that have a single
HL7-defined value set.
can only be used in either of the following
cases:
for a coded attribute which has a single HL7-defined code system, and
where code additions to that value set require formal HL7 action (such
as harmonization.) Such coded attributes must be assigned the
restriction.
for a property in this specification that is assigned to a single code
system defined either in this specification or defined outside HL7 by a body
that has authority over the concept and the maintenance of that code system.
For example, since the type subscribes to the MIME
design, it trusts IETF to manage the media type. This includes that this
specification subscribes to the extension mechanism built into the MIME media
type code (e.g., "application/x-myapp").
For values, the designation of the domain qualifier
will always be CNE (coded, non-extensible) and the
context will determine which HL7 values to use.
This is not withstanding the fact that an external referenced domain,
such as the IETF MIME media type may include an extension
mechanism. These extended MIME type codes would not be considered
"extensions" in the sense of violating the CNE provision. The CNE
provision is only violated if an attempt is made in using a different
code system (by means of the CD.codeSystem property), which is not
possible with the data type.
type CodedSimpleValue alias CS specializes CV {
literal ST;
};
CV (CodedValue)
Coded data, specifying only a code, code system, and optionally
display name and original text. Used only as the data type for other
data types' properties.
This type is used when any reasonable use case will require only a
single code value to be sent. Thus, it should not be used in
circumstances where multiple alternative codes for a given value are
desired. This type may be used with both the CNE (coded,
non-extensible) and the CWE (coded, with
extensibility) domain qualifiers.
protected type CodedValue alias CV specializes CE;
Coded data, specifying only a code, code system, and optionally
display name and original text. Used only as the data type for other
data types' properties.
This type is used when any reasonable use case will require only a
single code value to be sent. Thus, it should not be used in
circumstances where multiple alternative codes for a given value are
desired. This type may be used with both the CNE (coded,
non-extensible) and the CWE (coded, with
extensibility) domain qualifiers.
protected type CodedValue alias CV specializes CE;
Coded data, specifying only a code, code system, and optionally
display name and original text. Used only as the data type for other
data types' properties.
This type is used when any reasonable use case will require only a
single code value to be sent. Thus, it should not be used in
circumstances where multiple alternative codes for a given value are
desired. This type may be used with both the CNE (coded,
non-extensible) and the CWE (coded, with
extensibility) domain qualifiers.
protected type CodedValue alias CV specializes CE;
Coded data, specifying only a code, code system, and optionally
display name and original text. Used only as the data type for other
data types' properties.
This type is used when any reasonable use case will require only a
single code value to be sent. Thus, it should not be used in
circumstances where multiple alternative codes for a given value are
desired. This type may be used with both the CNE (coded,
non-extensible) and the CWE (coded, with
extensibility) domain qualifiers.
protected type CodedValue alias CV specializes CE;
Coded data, specifying only a code, code system, and optionally
display name and original text. Used only as the data type for other
data types' properties.
This type is used when any reasonable use case will require only a
single code value to be sent. Thus, it should not be used in
circumstances where multiple alternative codes for a given value are
desired. This type may be used with both the CNE (coded,
non-extensible) and the CWE (coded, with
extensibility) domain qualifiers.
protected type CodedValue alias CV specializes CE;
Coded data, specifying only a code, code system, and optionally
display name and original text. Used only as the data type for other
data types' properties.
This type is used when any reasonable use case will require only a
single code value to be sent. Thus, it should not be used in
circumstances where multiple alternative codes for a given value are
desired. This type may be used with both the CNE (coded,
non-extensible) and the CWE (coded, with
extensibility) domain qualifiers.
protected type CodedValue alias CV specializes CE;
Coded data, specifying only a code, code system, and optionally
display name and original text. Used only as the data type for other
data types' properties.
This type is used when any reasonable use case will require only a
single code value to be sent. Thus, it should not be used in
circumstances where multiple alternative codes for a given value are
desired. This type may be used with both the CNE (coded,
non-extensible) and the CWE (coded, with
extensibility) domain qualifiers.
protected type CodedValue alias CV specializes CE;
Coded data, specifying only a code, code system, and optionally
display name and original text. Used only as the data type for other
data types' properties.
This type is used when any reasonable use case will require only a
single code value to be sent. Thus, it should not be used in
circumstances where multiple alternative codes for a given value are
desired. This type may be used with both the CNE (coded,
non-extensible) and the CWE (coded, with
extensibility) domain qualifiers.
protected type CodedValue alias CV specializes CE;
Coded data, specifying only a code, code system, and optionally
display name and original text. Used only as the data type for other
data types' properties.
This type is used when any reasonable use case will require only a
single code value to be sent. Thus, it should not be used in
circumstances where multiple alternative codes for a given value are
desired. This type may be used with both the CNE (coded,
non-extensible) and the CWE (coded, with
extensibility) domain qualifiers.
protected type CodedValue alias CV specializes CE;
CO (CodedOrdinal)
Coded data, where the domain from which the codeset comes is ordered. The
Coded Ordinal data type adds semantics related to ordering so that models
that make use of such domains may introduce model elements that involve
statements about the order of the terms in a domain.
The relative order of this type's values need not be independently
obvious in their literal representation. It is expected that an
application will look up the ordering of these values from some
table.
type CodedOrdinal alias CO specializes CV {
BL lessOrEqual(CO o);
BL lessThan(CO o);
BL greaterThan(CO o);
BL greaterOrEqual(CO o);
};
Coded data, where the domain from which the codeset comes is ordered. The
Coded Ordinal data type adds semantics related to ordering so that models
that make use of such domains may introduce model elements that involve
statements about the order of the terms in a domain.
The relative order of this type's values need not be independently
obvious in their literal representation. It is expected that an
application will look up the ordering of these values from some
table.
type CodedOrdinal alias CO specializes CV {
BL lessOrEqual(CO o);
BL lessThan(CO o);
BL greaterThan(CO o);
BL greaterOrEqual(CO o);
};
Coded data, where the domain from which the codeset comes is ordered. The
Coded Ordinal data type adds semantics related to ordering so that models
that make use of such domains may introduce model elements that involve
statements about the order of the terms in a domain.
The relative order of this type's values need not be independently
obvious in their literal representation. It is expected that an
application will look up the ordering of these values from some
table.
type CodedOrdinal alias CO specializes CV {
BL lessOrEqual(CO o);
BL lessThan(CO o);
BL greaterThan(CO o);
BL greaterOrEqual(CO o);
};
Coded data, where the domain from which the codeset comes is ordered. The
Coded Ordinal data type adds semantics related to ordering so that models
that make use of such domains may introduce model elements that involve
statements about the order of the terms in a domain.
The relative order of this type's values need not be independently
obvious in their literal representation. It is expected that an
application will look up the ordering of these values from some
table.
type CodedOrdinal alias CO specializes CV {
BL lessOrEqual(CO o);
BL lessThan(CO o);
BL greaterThan(CO o);
BL greaterOrEqual(CO o);
};
Coded data, where the domain from which the codeset comes is ordered. The
Coded Ordinal data type adds semantics related to ordering so that models
that make use of such domains may introduce model elements that involve
statements about the order of the terms in a domain.
The relative order of this type's values need not be independently
obvious in their literal representation. It is expected that an
application will look up the ordering of these values from some
table.
type CodedOrdinal alias CO specializes CV {
BL lessOrEqual(CO o);
BL lessThan(CO o);
BL greaterThan(CO o);
BL greaterOrEqual(CO o);
};
CE (CodedWithEquivalents)
Coded data that consists of a coded value (CV) and, optionally, coded
value(s) from other coding systems that identify the same
concept. Used when alternative codes may exist.
The type is used when the use case indicates that alternative
codes may exist and where it is useful to communicate these. The
type provides for a primary code value, plus a set of
alternative or equivalent representations.
type CodedWithEquivalents alias CE specializes CD;
Coded data that consists of a coded value (CV) and, optionally, coded
value(s) from other coding systems that identify the same
concept. Used when alternative codes may exist.
The type is used when the use case indicates that alternative
codes may exist and where it is useful to communicate these. The
type provides for a primary code value, plus a set of
alternative or equivalent representations.
type CodedWithEquivalents alias CE specializes CD;
Coded data that consists of a coded value (CV) and, optionally, coded
value(s) from other coding systems that identify the same
concept. Used when alternative codes may exist.
The type is used when the use case indicates that alternative
codes may exist and where it is useful to communicate these. The
type provides for a primary code value, plus a set of
alternative or equivalent representations.
type CodedWithEquivalents alias CE specializes CD;
Coded data that consists of a coded value (CV) and, optionally, coded
value(s) from other coding systems that identify the same
concept. Used when alternative codes may exist.
The type is used when the use case indicates that alternative
codes may exist and where it is useful to communicate these. The
type provides for a primary code value, plus a set of
alternative or equivalent representations.
type CodedWithEquivalents alias CE specializes CD;
Coded data that consists of a coded value (CV) and, optionally, coded
value(s) from other coding systems that identify the same
concept. Used when alternative codes may exist.
The type is used when the use case indicates that alternative
codes may exist and where it is useful to communicate these. The
type provides for a primary code value, plus a set of
alternative or equivalent representations.
type CodedWithEquivalents alias CE specializes CD;
Coded data that consists of a coded value (CV) and, optionally, coded
value(s) from other coding systems that identify the same
concept. Used when alternative codes may exist.
The type is used when the use case indicates that alternative
codes may exist and where it is useful to communicate these. The
type provides for a primary code value, plus a set of
alternative or equivalent representations.
type CodedWithEquivalents alias CE specializes CD;
Coded data that consists of a coded value (CV) and, optionally, coded
value(s) from other coding systems that identify the same
concept. Used when alternative codes may exist.
The type is used when the use case indicates that alternative
codes may exist and where it is useful to communicate these. The
type provides for a primary code value, plus a set of
alternative or equivalent representations.
type CodedWithEquivalents alias CE specializes CD;
Coded data that consists of a coded value (CV) and, optionally, coded
value(s) from other coding systems that identify the same
concept. Used when alternative codes may exist.
The type is used when the use case indicates that alternative
codes may exist and where it is useful to communicate these. The
type provides for a primary code value, plus a set of
alternative or equivalent representations.
type CodedWithEquivalents alias CE specializes CD;
Coded data that consists of a coded value (CV) and, optionally, coded
value(s) from other coding systems that identify the same
concept. Used when alternative codes may exist.
The type is used when the use case indicates that alternative
codes may exist and where it is useful to communicate these. The
type provides for a primary code value, plus a set of
alternative or equivalent representations.
type CodedWithEquivalents alias CE specializes CD;
SC (CharacterStringWithCode)
A character string that optionally may have a code attached. The text
must always be present if a code is present. The code is often a
local code.
This data type is used in cases where coding is exceptional (e.g.,
user text messages are essentially text messages, and a printable
message is the important content. Yet, sometimes messages come from a
catalog of canned messages, which the SC allows to reference.
type CharacterStringWithCode alias SC specializes ST {
CE code;
};
A character string that optionally may have a code attached. The text
must always be present if a code is present. The code is often a
local code.
This data type is used in cases where coding is exceptional (e.g.,
user text messages are essentially text messages, and a printable
message is the important content. Yet, sometimes messages come from a
catalog of canned messages, which the SC allows to reference.
type CharacterStringWithCode alias SC specializes ST {
CE code;
};
UID (UniqueIdentifierString)
A unique identifier string is a character string which identifies an
object in a globally unique and timeless manner. The allowable formats
and values and procedures of this data type are strictly controlled by
HL7. At this time, user-assigned identifiers may be certain character
representations of ISO Object Identifiers (OID) and DCE Universally
Unique Identifiers (UUID). HL7 also reserves the right to assign other
forms of UIDs, such as mnemonic identifiers for code systems.
The sole purpose of the UID is to be a globally and timelessly unique
identifier. The form of the UID, whether it is an OID, an UUID or any
other form is entirely irrelevant. As far as HL7 is concerned, the
only thing one can do with a UID is denote to the object for which it
stands. Comparison of UIDs is literal, i.e. if two UIDs are literally
identical, they are assumed to denote to the same object. If two UIDs
are not literally identical they may not denote to the
same object.
No difference in semantics is recognized between the different
allowed forms of the UID. The different forms are not distinguished
by a component within or aside from the identifier string itself.
Even though this specification recognizes no semantic difference
between the different forms of the unique identifier forms, there are
differences of how these identifiers are built and managed, which is
the sole reason to define subtypes to the UID for each of the
variants.
protected type UniqueIdentifierString alias UID specializes ST;
OID (ObjectIdentifier)
A globally unique string representing an ISO Object Identifier
(OID) in a form that consists only of numbers and dots (e.g.,
"2.16.840.1.113883.3.1"). According to ISO, OIDs are paths in a tree
structure, with the left-most number representing the root and the
right-most number representing a leaf.
Each branch under the root corresponds to an assigning authority. Each
of these assigning authorities may, in turn, designate its own set of
assigning authorities that work under its auspices, and so on down the
line. Eventually, one of these authorities assigns a unique (to it as
an assigning authority) number that corresponds to a leaf node on the
tree. The leaf may represent an assigning authority (in which case the
root OID identifies the authority), or an instance of an object. An
assigning authority owns a namespace, consisting of its sub-tree.
OIDs are the preferred scheme for unique identifiers. OIDs should
always be used except if one of the inclusion criteria for other
schemes apply.
ISO/IEC 8824:1990(E) clause 28 defines the Object Identifier as
28.9 The semantics of an
object identifier value are defined by reference to an
object identifier tree. An object identifier tree is a tree whose root
corresponds to [the ISO/IEC 8824 standard] and whose vertices [i.e. nodes]
correspond to administrative authorities responsible for allocating arcs [i.e.
branches] from that vertex. Each arc from that tree is labeled by an object
identifier component, which is [an integer number]. Each information object to
be identified is allocated precisely one vertex (normally a leaf) and no other
information object (of the same or a different type) is allocated to
that same vertex. Thus an information object is uniquely and
unambiguously identified by the sequence of [integer numbers] (object
identifier components) labeling the arcs in a path from the root to
the vertex allocated to the information object.
28.10 An object identifier value is
semantically an ordered list of object identifier component
values. Starting with the root of the object identifier tree, each
object identifier component value identifies an arc in the object
identifier tree. The last object identifier component value identifies
an arc leading to a vertex to which an information object has been
assigned. It is this information object, which is identified by the
object identifier value. [...]
According to ISO/IEC 8824 an object identifier is a sequence of object
identifier component values, which are integer numbers. These
component values are ordered such that the root of the object
identifier tree is the head of the list followed by all the arcs down
to the leaf representing the information object identified by the
OID. The fact that OID specializes <
> represents this path of object identifier component
values from the root to the leaf.
The leaf and "butLeaf"
properties take the opposite view. The
leaf is the last object identifier component value in the list, and
the "butLeaf" property is all of the OID but the
leaf. In a sense, the leaf is the identifier value and
all of the OID but the leaf refers to the namespace in which the leaf
is unique and meaningful.
However, what part of the OID is considered value
and what is namespace may be viewed differently. In
general, any OID component sequence to the left can be considered the namespace
in which the rest of the sequence to the right is defined as a
meaningful and unique identifier value. The value-property with a
namespace OID as its argument represents this point of view.
The value/namespace view on ISO object identifiers has important
semantic relevance. It represents the notion of identifier value
versus identifier assigning authority (= namespace), which is common
in healthcare information systems in general, and HL7 v2.x in
particular.
section-OID.procedures
HL7 shall establish an OID registry and assign OIDs in its branch for
HL7 users and vendors upon their request. HL7 shall also assign OIDs
to public identifier-assigning authorities both U.S. nationally (e.g.,
the U.S. State driver license bureaus, U.S. Social Security
Administration, HIPAA Provider ID registry, etc.) and internationally
(e.g., other countries Social Security Administrations, Citizen ID
registries, etc.) The HL7 registered OIDs must be used for these
organizations, regardless whether these organizations have other OIDs
assigned from other sources.
When assigning OIDs to third parties or entities, HL7 shall
investigate whether an OID is already assigned for such entities
through other sources. It this is the case, HL7 shall record such OID
in a catalog, but HL7 shall not assign a duplicate OID in the HL7
branch. If possible, HL7 shall notify a third party when an OID is
being assigned for that party in the HL7 branch.
Though HL7 shall exercise diligence before assigning an OID in the HL7
branch to third parties, given the lack of a global OID registry
mechanism, one cannot make absolutely certain that there is no
preexisting OID assignment for such third-party entity. Also, a
duplicate assignment can happen in the future through another
source. If such cases of supplicate assignment become known to HL7,
HL7 shall make efforts to resolve this situation. For continued
interoperability in the meantime, the HL7 assigned OID shall be the
preferred OID used.
While most owners of an OID will "design" their namespace sub-tree in
some meaningful way, there is no way to generally infer any meaning on
the parts of an OID. HL7 does not standardize or require any namespace
sub-structure. An OID owner, or anyone having knowledge about the
logical structure of part of an OID, may still use that knowledge to
infer information about the associated object; however, the techniques
cannot be generalized.
Example for a tree of ISO object identifiers. HL7's OID
is 2.16.840.1.113883.
An HL7 interface must not rely on any
knowledge about the substructure of an OID for which it cannot control the
assignment policies.
protected type ObjectIdentifier alias OID specializes UID, LIST<INT> {
INT leaf;
OID butLeaf;
OID value(OID namespace);
literal ST;
};
A globally unique string representing an ISO Object Identifier
(OID) in a form that consists only of numbers and dots (e.g.,
"2.16.840.1.113883.3.1"). According to ISO, OIDs are paths in a tree
structure, with the left-most number representing the root and the
right-most number representing a leaf.
Each branch under the root corresponds to an assigning authority. Each
of these assigning authorities may, in turn, designate its own set of
assigning authorities that work under its auspices, and so on down the
line. Eventually, one of these authorities assigns a unique (to it as
an assigning authority) number that corresponds to a leaf node on the
tree. The leaf may represent an assigning authority (in which case the
root OID identifies the authority), or an instance of an object. An
assigning authority owns a namespace, consisting of its sub-tree.
OIDs are the preferred scheme for unique identifiers. OIDs should
always be used except if one of the inclusion criteria for other
schemes apply.
ISO/IEC 8824:1990(E) clause 28 defines the Object Identifier as
28.9 The semantics of an
object identifier value are defined by reference to an
object identifier tree. An object identifier tree is a tree whose root
corresponds to [the ISO/IEC 8824 standard] and whose vertices [i.e. nodes]
correspond to administrative authorities responsible for allocating arcs [i.e.
branches] from that vertex. Each arc from that tree is labeled by an object
identifier component, which is [an integer number]. Each information object to
be identified is allocated precisely one vertex (normally a leaf) and no other
information object (of the same or a different type) is allocated to
that same vertex. Thus an information object is uniquely and
unambiguously identified by the sequence of [integer numbers] (object
identifier components) labeling the arcs in a path from the root to
the vertex allocated to the information object.
28.10 An object identifier value is
semantically an ordered list of object identifier component
values. Starting with the root of the object identifier tree, each
object identifier component value identifies an arc in the object
identifier tree. The last object identifier component value identifies
an arc leading to a vertex to which an information object has been
assigned. It is this information object, which is identified by the
object identifier value. [...]
According to ISO/IEC 8824 an object identifier is a sequence of object
identifier component values, which are integer numbers. These
component values are ordered such that the root of the object
identifier tree is the head of the list followed by all the arcs down
to the leaf representing the information object identified by the
OID. The fact that OID specializes <
> represents this path of object identifier component
values from the root to the leaf.
The leaf and "butLeaf"
properties take the opposite view. The
leaf is the last object identifier component value in the list, and
the "butLeaf" property is all of the OID but the
leaf. In a sense, the leaf is the identifier value and
all of the OID but the leaf refers to the namespace in which the leaf
is unique and meaningful.
However, what part of the OID is considered value
and what is namespace may be viewed differently. In
general, any OID component sequence to the left can be considered the namespace
in which the rest of the sequence to the right is defined as a
meaningful and unique identifier value. The value-property with a
namespace OID as its argument represents this point of view.
The value/namespace view on ISO object identifiers has important
semantic relevance. It represents the notion of identifier value
versus identifier assigning authority (= namespace), which is common
in healthcare information systems in general, and HL7 v2.x in
particular.
section-OID.procedures
HL7 shall establish an OID registry and assign OIDs in its branch for
HL7 users and vendors upon their request. HL7 shall also assign OIDs
to public identifier-assigning authorities both U.S. nationally (e.g.,
the U.S. State driver license bureaus, U.S. Social Security
Administration, HIPAA Provider ID registry, etc.) and internationally
(e.g., other countries Social Security Administrations, Citizen ID
registries, etc.) The HL7 registered OIDs must be used for these
organizations, regardless whether these organizations have other OIDs
assigned from other sources.
When assigning OIDs to third parties or entities, HL7 shall
investigate whether an OID is already assigned for such entities
through other sources. It this is the case, HL7 shall record such OID
in a catalog, but HL7 shall not assign a duplicate OID in the HL7
branch. If possible, HL7 shall notify a third party when an OID is
being assigned for that party in the HL7 branch.
Though HL7 shall exercise diligence before assigning an OID in the HL7
branch to third parties, given the lack of a global OID registry
mechanism, one cannot make absolutely certain that there is no
preexisting OID assignment for such third-party entity. Also, a
duplicate assignment can happen in the future through another
source. If such cases of supplicate assignment become known to HL7,
HL7 shall make efforts to resolve this situation. For continued
interoperability in the meantime, the HL7 assigned OID shall be the
preferred OID used.
While most owners of an OID will "design" their namespace sub-tree in
some meaningful way, there is no way to generally infer any meaning on
the parts of an OID. HL7 does not standardize or require any namespace
sub-structure. An OID owner, or anyone having knowledge about the
logical structure of part of an OID, may still use that knowledge to
infer information about the associated object; however, the techniques
cannot be generalized.
Example for a tree of ISO object identifiers. HL7's OID
is 2.16.840.1.113883.
An HL7 interface must not rely on any
knowledge about the substructure of an OID for which it cannot control the
assignment policies.
protected type ObjectIdentifier alias OID specializes UID, LIST<INT> {
INT leaf;
OID butLeaf;
OID value(OID namespace);
literal ST;
};
A globally unique string representing an ISO Object Identifier
(OID) in a form that consists only of numbers and dots (e.g.,
"2.16.840.1.113883.3.1"). According to ISO, OIDs are paths in a tree
structure, with the left-most number representing the root and the
right-most number representing a leaf.
Each branch under the root corresponds to an assigning authority. Each
of these assigning authorities may, in turn, designate its own set of
assigning authorities that work under its auspices, and so on down the
line. Eventually, one of these authorities assigns a unique (to it as
an assigning authority) number that corresponds to a leaf node on the
tree. The leaf may represent an assigning authority (in which case the
root OID identifies the authority), or an instance of an object. An
assigning authority owns a namespace, consisting of its sub-tree.
OIDs are the preferred scheme for unique identifiers. OIDs should
always be used except if one of the inclusion criteria for other
schemes apply.
ISO/IEC 8824:1990(E) clause 28 defines the Object Identifier as
28.9 The semantics of an
object identifier value are defined by reference to an
object identifier tree. An object identifier tree is a tree whose root
corresponds to [the ISO/IEC 8824 standard] and whose vertices [i.e. nodes]
correspond to administrative authorities responsible for allocating arcs [i.e.
branches] from that vertex. Each arc from that tree is labeled by an object
identifier component, which is [an integer number]. Each information object to
be identified is allocated precisely one vertex (normally a leaf) and no other
information object (of the same or a different type) is allocated to
that same vertex. Thus an information object is uniquely and
unambiguously identified by the sequence of [integer numbers] (object
identifier components) labeling the arcs in a path from the root to
the vertex allocated to the information object.
28.10 An object identifier value is
semantically an ordered list of object identifier component
values. Starting with the root of the object identifier tree, each
object identifier component value identifies an arc in the object
identifier tree. The last object identifier component value identifies
an arc leading to a vertex to which an information object has been
assigned. It is this information object, which is identified by the
object identifier value. [...]
According to ISO/IEC 8824 an object identifier is a sequence of object
identifier component values, which are integer numbers. These
component values are ordered such that the root of the object
identifier tree is the head of the list followed by all the arcs down
to the leaf representing the information object identified by the
OID. The fact that OID specializes <
> represents this path of object identifier component
values from the root to the leaf.
The leaf and "butLeaf"
properties take the opposite view. The
leaf is the last object identifier component value in the list, and
the "butLeaf" property is all of the OID but the
leaf. In a sense, the leaf is the identifier value and
all of the OID but the leaf refers to the namespace in which the leaf
is unique and meaningful.
However, what part of the OID is considered value
and what is namespace may be viewed differently. In
general, any OID component sequence to the left can be considered the namespace
in which the rest of the sequence to the right is defined as a
meaningful and unique identifier value. The value-property with a
namespace OID as its argument represents this point of view.
The value/namespace view on ISO object identifiers has important
semantic relevance. It represents the notion of identifier value
versus identifier assigning authority (= namespace), which is common
in healthcare information systems in general, and HL7 v2.x in
particular.
section-OID.procedures
HL7 shall establish an OID registry and assign OIDs in its branch for
HL7 users and vendors upon their request. HL7 shall also assign OIDs
to public identifier-assigning authorities both U.S. nationally (e.g.,
the U.S. State driver license bureaus, U.S. Social Security
Administration, HIPAA Provider ID registry, etc.) and internationally
(e.g., other countries Social Security Administrations, Citizen ID
registries, etc.) The HL7 registered OIDs must be used for these
organizations, regardless whether these organizations have other OIDs
assigned from other sources.
When assigning OIDs to third parties or entities, HL7 shall
investigate whether an OID is already assigned for such entities
through other sources. It this is the case, HL7 shall record such OID
in a catalog, but HL7 shall not assign a duplicate OID in the HL7
branch. If possible, HL7 shall notify a third party when an OID is
being assigned for that party in the HL7 branch.
Though HL7 shall exercise diligence before assigning an OID in the HL7
branch to third parties, given the lack of a global OID registry
mechanism, one cannot make absolutely certain that there is no
preexisting OID assignment for such third-party entity. Also, a
duplicate assignment can happen in the future through another
source. If such cases of supplicate assignment become known to HL7,
HL7 shall make efforts to resolve this situation. For continued
interoperability in the meantime, the HL7 assigned OID shall be the
preferred OID used.
While most owners of an OID will "design" their namespace sub-tree in
some meaningful way, there is no way to generally infer any meaning on
the parts of an OID. HL7 does not standardize or require any namespace
sub-structure. An OID owner, or anyone having knowledge about the
logical structure of part of an OID, may still use that knowledge to
infer information about the associated object; however, the techniques
cannot be generalized.
Example for a tree of ISO object identifiers. HL7's OID
is 2.16.840.1.113883.
An HL7 interface must not rely on any
knowledge about the substructure of an OID for which it cannot control the
assignment policies.
protected type ObjectIdentifier alias OID specializes UID, LIST<INT> {
INT leaf;
OID butLeaf;
OID value(OID namespace);
literal ST;
};
A globally unique string representing an ISO Object Identifier
(OID) in a form that consists only of numbers and dots (e.g.,
"2.16.840.1.113883.3.1"). According to ISO, OIDs are paths in a tree
structure, with the left-most number representing the root and the
right-most number representing a leaf.
Each branch under the root corresponds to an assigning authority. Each
of these assigning authorities may, in turn, designate its own set of
assigning authorities that work under its auspices, and so on down the
line. Eventually, one of these authorities assigns a unique (to it as
an assigning authority) number that corresponds to a leaf node on the
tree. The leaf may represent an assigning authority (in which case the
root OID identifies the authority), or an instance of an object. An
assigning authority owns a namespace, consisting of its sub-tree.
OIDs are the preferred scheme for unique identifiers. OIDs should
always be used except if one of the inclusion criteria for other
schemes apply.
ISO/IEC 8824:1990(E) clause 28 defines the Object Identifier as
28.9 The semantics of an
object identifier value are defined by reference to an
object identifier tree. An object identifier tree is a tree whose root
corresponds to [the ISO/IEC 8824 standard] and whose vertices [i.e. nodes]
correspond to administrative authorities responsible for allocating arcs [i.e.
branches] from that vertex. Each arc from that tree is labeled by an object
identifier component, which is [an integer number]. Each information object to
be identified is allocated precisely one vertex (normally a leaf) and no other
information object (of the same or a different type) is allocated to
that same vertex. Thus an information object is uniquely and
unambiguously identified by the sequence of [integer numbers] (object
identifier components) labeling the arcs in a path from the root to
the vertex allocated to the information object.
28.10 An object identifier value is
semantically an ordered list of object identifier component
values. Starting with the root of the object identifier tree, each
object identifier component value identifies an arc in the object
identifier tree. The last object identifier component value identifies
an arc leading to a vertex to which an information object has been
assigned. It is this information object, which is identified by the
object identifier value. [...]
According to ISO/IEC 8824 an object identifier is a sequence of object
identifier component values, which are integer numbers. These
component values are ordered such that the root of the object
identifier tree is the head of the list followed by all the arcs down
to the leaf representing the information object identified by the
OID. The fact that OID specializes <
> represents this path of object identifier component
values from the root to the leaf.
The leaf and "butLeaf"
properties take the opposite view. The
leaf is the last object identifier component value in the list, and
the "butLeaf" property is all of the OID but the
leaf. In a sense, the leaf is the identifier value and
all of the OID but the leaf refers to the namespace in which the leaf
is unique and meaningful.
However, what part of the OID is considered value
and what is namespace may be viewed differently. In
general, any OID component sequence to the left can be considered the namespace
in which the rest of the sequence to the right is defined as a
meaningful and unique identifier value. The value-property with a
namespace OID as its argument represents this point of view.
The value/namespace view on ISO object identifiers has important
semantic relevance. It represents the notion of identifier value
versus identifier assigning authority (= namespace), which is common
in healthcare information systems in general, and HL7 v2.x in
particular.
section-OID.procedures
HL7 shall establish an OID registry and assign OIDs in its branch for
HL7 users and vendors upon their request. HL7 shall also assign OIDs
to public identifier-assigning authorities both U.S. nationally (e.g.,
the U.S. State driver license bureaus, U.S. Social Security
Administration, HIPAA Provider ID registry, etc.) and internationally
(e.g., other countries Social Security Administrations, Citizen ID
registries, etc.) The HL7 registered OIDs must be used for these
organizations, regardless whether these organizations have other OIDs
assigned from other sources.
When assigning OIDs to third parties or entities, HL7 shall
investigate whether an OID is already assigned for such entities
through other sources. It this is the case, HL7 shall record such OID
in a catalog, but HL7 shall not assign a duplicate OID in the HL7
branch. If possible, HL7 shall notify a third party when an OID is
being assigned for that party in the HL7 branch.
Though HL7 shall exercise diligence before assigning an OID in the HL7
branch to third parties, given the lack of a global OID registry
mechanism, one cannot make absolutely certain that there is no
preexisting OID assignment for such third-party entity. Also, a
duplicate assignment can happen in the future through another
source. If such cases of supplicate assignment become known to HL7,
HL7 shall make efforts to resolve this situation. For continued
interoperability in the meantime, the HL7 assigned OID shall be the
preferred OID used.
While most owners of an OID will "design" their namespace sub-tree in
some meaningful way, there is no way to generally infer any meaning on
the parts of an OID. HL7 does not standardize or require any namespace
sub-structure. An OID owner, or anyone having knowledge about the
logical structure of part of an OID, may still use that knowledge to
infer information about the associated object; however, the techniques
cannot be generalized.
Example for a tree of ISO object identifiers. HL7's OID
is 2.16.840.1.113883.
An HL7 interface must not rely on any
knowledge about the substructure of an OID for which it cannot control the
assignment policies.
protected type ObjectIdentifier alias OID specializes UID, LIST<INT> {
INT leaf;
OID butLeaf;
OID value(OID namespace);
literal ST;
};
A globally unique string representing an ISO Object Identifier
(OID) in a form that consists only of numbers and dots (e.g.,
"2.16.840.1.113883.3.1"). According to ISO, OIDs are paths in a tree
structure, with the left-most number representing the root and the
right-most number representing a leaf.
Each branch under the root corresponds to an assigning authority. Each
of these assigning authorities may, in turn, designate its own set of
assigning authorities that work under its auspices, and so on down the
line. Eventually, one of these authorities assigns a unique (to it as
an assigning authority) number that corresponds to a leaf node on the
tree. The leaf may represent an assigning authority (in which case the
root OID identifies the authority), or an instance of an object. An
assigning authority owns a namespace, consisting of its sub-tree.
OIDs are the preferred scheme for unique identifiers. OIDs should
always be used except if one of the inclusion criteria for other
schemes apply.
ISO/IEC 8824:1990(E) clause 28 defines the Object Identifier as
28.9 The semantics of an
object identifier value are defined by reference to an
object identifier tree. An object identifier tree is a tree whose root
corresponds to [the ISO/IEC 8824 standard] and whose vertices [i.e. nodes]
correspond to administrative authorities responsible for allocating arcs [i.e.
branches] from that vertex. Each arc from that tree is labeled by an object
identifier component, which is [an integer number]. Each information object to
be identified is allocated precisely one vertex (normally a leaf) and no other
information object (of the same or a different type) is allocated to
that same vertex. Thus an information object is uniquely and
unambiguously identified by the sequence of [integer numbers] (object
identifier components) labeling the arcs in a path from the root to
the vertex allocated to the information object.
28.10 An object identifier value is
semantically an ordered list of object identifier component
values. Starting with the root of the object identifier tree, each
object identifier component value identifies an arc in the object
identifier tree. The last object identifier component value identifies
an arc leading to a vertex to which an information object has been
assigned. It is this information object, which is identified by the
object identifier value. [...]
According to ISO/IEC 8824 an object identifier is a sequence of object
identifier component values, which are integer numbers. These
component values are ordered such that the root of the object
identifier tree is the head of the list followed by all the arcs down
to the leaf representing the information object identified by the
OID. The fact that OID specializes <
> represents this path of object identifier component
values from the root to the leaf.
The leaf and "butLeaf"
properties take the opposite view. The
leaf is the last object identifier component value in the list, and
the "butLeaf" property is all of the OID but the
leaf. In a sense, the leaf is the identifier value and
all of the OID but the leaf refers to the namespace in which the leaf
is unique and meaningful.
However, what part of the OID is considered value
and what is namespace may be viewed differently. In
general, any OID component sequence to the left can be considered the namespace
in which the rest of the sequence to the right is defined as a
meaningful and unique identifier value. The value-property with a
namespace OID as its argument represents this point of view.
The value/namespace view on ISO object identifiers has important
semantic relevance. It represents the notion of identifier value
versus identifier assigning authority (= namespace), which is common
in healthcare information systems in general, and HL7 v2.x in
particular.
section-OID.procedures
HL7 shall establish an OID registry and assign OIDs in its branch for
HL7 users and vendors upon their request. HL7 shall also assign OIDs
to public identifier-assigning authorities both U.S. nationally (e.g.,
the U.S. State driver license bureaus, U.S. Social Security
Administration, HIPAA Provider ID registry, etc.) and internationally
(e.g., other countries Social Security Administrations, Citizen ID
registries, etc.) The HL7 registered OIDs must be used for these
organizations, regardless whether these organizations have other OIDs
assigned from other sources.
When assigning OIDs to third parties or entities, HL7 shall
investigate whether an OID is already assigned for such entities
through other sources. It this is the case, HL7 shall record such OID
in a catalog, but HL7 shall not assign a duplicate OID in the HL7
branch. If possible, HL7 shall notify a third party when an OID is
being assigned for that party in the HL7 branch.
Though HL7 shall exercise diligence before assigning an OID in the HL7
branch to third parties, given the lack of a global OID registry
mechanism, one cannot make absolutely certain that there is no
preexisting OID assignment for such third-party entity. Also, a
duplicate assignment can happen in the future through another
source. If such cases of supplicate assignment become known to HL7,
HL7 shall make efforts to resolve this situation. For continued
interoperability in the meantime, the HL7 assigned OID shall be the
preferred OID used.
While most owners of an OID will "design" their namespace sub-tree in
some meaningful way, there is no way to generally infer any meaning on
the parts of an OID. HL7 does not standardize or require any namespace
sub-structure. An OID owner, or anyone having knowledge about the
logical structure of part of an OID, may still use that knowledge to
infer information about the associated object; however, the techniques
cannot be generalized.
Example for a tree of ISO object identifiers. HL7's OID
is 2.16.840.1.113883.
An HL7 interface must not rely on any
knowledge about the substructure of an OID for which it cannot control the
assignment policies.
protected type ObjectIdentifier alias OID specializes UID, LIST<INT> {
INT leaf;
OID butLeaf;
OID value(OID namespace);
literal ST;
};
UUID (UniversalUniqueIdentifier)
A globally unique string representing a DCE Universal Unique
Identifier (UUID) in the common UUID format that consists of 5
hyphen-separated groups of hexadecimal digits having 8, 4, 4, 4,
and 12 places respectively.
Both the UUID and its string representation are defined by the Open
Group, CDE 1.1 Remote Procedure Call specification, Appendix A.
UUIDs are assigned based on Ethernet MAC addresses, the point in time
of creation and some random component. This mix is believed to
generate sufficiently unique identifiers without any organizational
policy for identifier assignment (in fact this piggy-backs on the
organization of MAC address assignment.)
UUIDs are not the preferred identifier
scheme for use as HL7 UIDs. UUIDs may be used when identifiers are
issued to objects representing individuals (e.g., entity instance
identifiers, act event identifiers, etc.) For objects describing
classes of things or events (e.g., catalog items), OIDs are the
preferred identifier scheme.
protected type UniversalUniqueIdentifier alias UUID specializes UID {
INT timeLow;
INT timeMid;
INT timeHighAndVersion;
INT clockSequence;
INT node;
literal ST;
};
A globally unique string representing a DCE Universal Unique
Identifier (UUID) in the common UUID format that consists of 5
hyphen-separated groups of hexadecimal digits having 8, 4, 4, 4,
and 12 places respectively.
Both the UUID and its string representation are defined by the Open
Group, CDE 1.1 Remote Procedure Call specification, Appendix A.
UUIDs are assigned based on Ethernet MAC addresses, the point in time
of creation and some random component. This mix is believed to
generate sufficiently unique identifiers without any organizational
policy for identifier assignment (in fact this piggy-backs on the
organization of MAC address assignment.)
UUIDs are not the preferred identifier
scheme for use as HL7 UIDs. UUIDs may be used when identifiers are
issued to objects representing individuals (e.g., entity instance
identifiers, act event identifiers, etc.) For objects describing
classes of things or events (e.g., catalog items), OIDs are the
preferred identifier scheme.
protected type UniversalUniqueIdentifier alias UUID specializes UID {
INT timeLow;
INT timeMid;
INT timeHighAndVersion;
INT clockSequence;
INT node;
literal ST;
};
A globally unique string representing a DCE Universal Unique
Identifier (UUID) in the common UUID format that consists of 5
hyphen-separated groups of hexadecimal digits having 8, 4, 4, 4,
and 12 places respectively.
Both the UUID and its string representation are defined by the Open
Group, CDE 1.1 Remote Procedure Call specification, Appendix A.
UUIDs are assigned based on Ethernet MAC addresses, the point in time
of creation and some random component. This mix is believed to
generate sufficiently unique identifiers without any organizational
policy for identifier assignment (in fact this piggy-backs on the
organization of MAC address assignment.)
UUIDs are not the preferred identifier
scheme for use as HL7 UIDs. UUIDs may be used when identifiers are
issued to objects representing individuals (e.g., entity instance
identifiers, act event identifiers, etc.) For objects describing
classes of things or events (e.g., catalog items), OIDs are the
preferred identifier scheme.
protected type UniversalUniqueIdentifier alias UUID specializes UID {
INT timeLow;
INT timeMid;
INT timeHighAndVersion;
INT clockSequence;
INT node;
literal ST;
};
A globally unique string representing a DCE Universal Unique
Identifier (UUID) in the common UUID format that consists of 5
hyphen-separated groups of hexadecimal digits having 8, 4, 4, 4,
and 12 places respectively.
Both the UUID and its string representation are defined by the Open
Group, CDE 1.1 Remote Procedure Call specification, Appendix A.
UUIDs are assigned based on Ethernet MAC addresses, the point in time
of creation and some random component. This mix is believed to
generate sufficiently unique identifiers without any organizational
policy for identifier assignment (in fact this piggy-backs on the
organization of MAC address assignment.)
UUIDs are not the preferred identifier
scheme for use as HL7 UIDs. UUIDs may be used when identifiers are
issued to objects representing individuals (e.g., entity instance
identifiers, act event identifiers, etc.) For objects describing
classes of things or events (e.g., catalog items), OIDs are the
preferred identifier scheme.
protected type UniversalUniqueIdentifier alias UUID specializes UID {
INT timeLow;
INT timeMid;
INT timeHighAndVersion;
INT clockSequence;
INT node;
literal ST;
};
A globally unique string representing a DCE Universal Unique
Identifier (UUID) in the common UUID format that consists of 5
hyphen-separated groups of hexadecimal digits having 8, 4, 4, 4,
and 12 places respectively.
Both the UUID and its string representation are defined by the Open
Group, CDE 1.1 Remote Procedure Call specification, Appendix A.
UUIDs are assigned based on Ethernet MAC addresses, the point in time
of creation and some random component. This mix is believed to
generate sufficiently unique identifiers without any organizational
policy for identifier assignment (in fact this piggy-backs on the
organization of MAC address assignment.)
UUIDs are not the preferred identifier
scheme for use as HL7 UIDs. UUIDs may be used when identifiers are
issued to objects representing individuals (e.g., entity instance
identifiers, act event identifiers, etc.) For objects describing
classes of things or events (e.g., catalog items), OIDs are the
preferred identifier scheme.
protected type UniversalUniqueIdentifier alias UUID specializes UID {
INT timeLow;
INT timeMid;
INT timeHighAndVersion;
INT clockSequence;
INT node;
literal ST;
};
A globally unique string representing a DCE Universal Unique
Identifier (UUID) in the common UUID format that consists of 5
hyphen-separated groups of hexadecimal digits having 8, 4, 4, 4,
and 12 places respectively.
Both the UUID and its string representation are defined by the Open
Group, CDE 1.1 Remote Procedure Call specification, Appendix A.
UUIDs are assigned based on Ethernet MAC addresses, the point in time
of creation and some random component. This mix is believed to
generate sufficiently unique identifiers without any organizational
policy for identifier assignment (in fact this piggy-backs on the
organization of MAC address assignment.)
UUIDs are not the preferred identifier
scheme for use as HL7 UIDs. UUIDs may be used when identifiers are
issued to objects representing individuals (e.g., entity instance
identifiers, act event identifiers, etc.) For objects describing
classes of things or events (e.g., catalog items), OIDs are the
preferred identifier scheme.
protected type UniversalUniqueIdentifier alias UUID specializes UID {
INT timeLow;
INT timeMid;
INT timeHighAndVersion;
INT clockSequence;
INT node;
literal ST;
};
A globally unique string representing a DCE Universal Unique
Identifier (UUID) in the common UUID format that consists of 5
hyphen-separated groups of hexadecimal digits having 8, 4, 4, 4,
and 12 places respectively.
Both the UUID and its string representation are defined by the Open
Group, CDE 1.1 Remote Procedure Call specification, Appendix A.
UUIDs are assigned based on Ethernet MAC addresses, the point in time
of creation and some random component. This mix is believed to
generate sufficiently unique identifiers without any organizational
policy for identifier assignment (in fact this piggy-backs on the
organization of MAC address assignment.)
UUIDs are not the preferred identifier
scheme for use as HL7 UIDs. UUIDs may be used when identifiers are
issued to objects representing individuals (e.g., entity instance
identifiers, act event identifiers, etc.) For objects describing
classes of things or events (e.g., catalog items), OIDs are the
preferred identifier scheme.
protected type UniversalUniqueIdentifier alias UUID specializes UID {
INT timeLow;
INT timeMid;
INT timeHighAndVersion;
INT clockSequence;
INT node;
literal ST;
};
RUID (HL7ReservedIdentifierScheme)
A globally unique string defined exclusively by HL7. Identifiers in
this scheme are only defined by balloted HL7 specifications. Local
communities or systems must never use such reserved identifiers based
on bilateral negotiations.
HL7 reserved identifiers are strings that consist only of (US-ASCII)
letters, digits and hyphens, where the first character must be a
letter. HL7 may assign these reserved identifiers as mnemonic
identifiers for major concepts of interest to HL7.
protected type HL7ReservedIdentifierScheme alias RUID specializes UID;
II (InstanceIdentifier)
An identifier that uniquely identifies a thing or object. Examples
are object identifier for HL7 RIM objects, medical record number,
order id, service catalog item id, Vehicle Identification Number
(VIN), etc. Instance identifiers are defined based on ISO object
identifiers.
type InstanceIdentifier alias II specializes ANY {
UID root;
ST extension;
ST assigningAuthorityName;
BL displayable;
};
An identifier that uniquely identifies a thing or object. Examples
are object identifier for HL7 RIM objects, medical record number,
order id, service catalog item id, Vehicle Identification Number
(VIN), etc. Instance identifiers are defined based on ISO object
identifiers.
type InstanceIdentifier alias II specializes ANY {
UID root;
ST extension;
ST assigningAuthorityName;
BL displayable;
};
An identifier that uniquely identifies a thing or object. Examples
are object identifier for HL7 RIM objects, medical record number,
order id, service catalog item id, Vehicle Identification Number
(VIN), etc. Instance identifiers are defined based on ISO object
identifiers.
type InstanceIdentifier alias II specializes ANY {
UID root;
ST extension;
ST assigningAuthorityName;
BL displayable;
};
An identifier that uniquely identifies a thing or object. Examples
are object identifier for HL7 RIM objects, medical record number,
order id, service catalog item id, Vehicle Identification Number
(VIN), etc. Instance identifiers are defined based on ISO object
identifiers.
type InstanceIdentifier alias II specializes ANY {
UID root;
ST extension;
ST assigningAuthorityName;
BL displayable;
};
An identifier that uniquely identifies a thing or object. Examples
are object identifier for HL7 RIM objects, medical record number,
order id, service catalog item id, Vehicle Identification Number
(VIN), etc. Instance identifiers are defined based on ISO object
identifiers.
type InstanceIdentifier alias II specializes ANY {
UID root;
ST extension;
ST assigningAuthorityName;
BL displayable;
};
An identifier that uniquely identifies a thing or object. Examples
are object identifier for HL7 RIM objects, medical record number,
order id, service catalog item id, Vehicle Identification Number
(VIN), etc. Instance identifiers are defined based on ISO object
identifiers.
type InstanceIdentifier alias II specializes ANY {
UID root;
ST extension;
ST assigningAuthorityName;
BL displayable;
};
URL (UniversalResourceLocator)
A telecommunications address specified according to Internet standard
RFC 2396 []. The
URI specifies the protocol and the contact point defined by that
protocol for the resource. Notable uses of the telecommunication
address data type are for telephone and telefax numbers, e-mail
addresses, Hypertext references, FTP references, etc.
The Internet standard RFC 2396 [] defines a URI as
follows:
Just as there are many different methods of access to resources, there
are several schemes for describing the location of such resources.
The generic syntax for s provides a framework for
new schemes to be established using protocols other than those defined
in this document.
URLs are used to "locate" resources, by providing an abstract
identification of the resource location. Having located a resource, a
system may perform a variety of operations on the resource, as might
be characterized by such words as "access", "update", "replace", "find
attributes". In general, only the "access" method needs to be
specified for any scheme.
protected type UniversalResourceLocator
alias URL specializes ANY {
CS scheme;
ST address;
literal ST;
};
A telecommunications address specified according to Internet standard
RFC 2396 []. The
URI specifies the protocol and the contact point defined by that
protocol for the resource. Notable uses of the telecommunication
address data type are for telephone and telefax numbers, e-mail
addresses, Hypertext references, FTP references, etc.
The Internet standard RFC 2396 [] defines a URI as
follows:
Just as there are many different methods of access to resources, there
are several schemes for describing the location of such resources.
The generic syntax for s provides a framework for
new schemes to be established using protocols other than those defined
in this document.
URLs are used to "locate" resources, by providing an abstract
identification of the resource location. Having located a resource, a
system may perform a variety of operations on the resource, as might
be characterized by such words as "access", "update", "replace", "find
attributes". In general, only the "access" method needs to be
specified for any scheme.
protected type UniversalResourceLocator
alias URL specializes ANY {
CS scheme;
ST address;
literal ST;
};
A telecommunications address specified according to Internet standard
RFC 2396 []. The
URI specifies the protocol and the contact point defined by that
protocol for the resource. Notable uses of the telecommunication
address data type are for telephone and telefax numbers, e-mail
addresses, Hypertext references, FTP references, etc.
The Internet standard RFC 2396 [] defines a URI as
follows:
Just as there are many different methods of access to resources, there
are several schemes for describing the location of such resources.
The generic syntax for s provides a framework for
new schemes to be established using protocols other than those defined
in this document.
URLs are used to "locate" resources, by providing an abstract
identification of the resource location. Having located a resource, a
system may perform a variety of operations on the resource, as might
be characterized by such words as "access", "update", "replace", "find
attributes". In general, only the "access" method needs to be
specified for any scheme.
protected type UniversalResourceLocator
alias URL specializes ANY {
CS scheme;
ST address;
literal ST;
};
A telecommunications address specified according to Internet standard
RFC 2396 []. The
URI specifies the protocol and the contact point defined by that
protocol for the resource. Notable uses of the telecommunication
address data type are for telephone and telefax numbers, e-mail
addresses, Hypertext references, FTP references, etc.
The Internet standard RFC 2396 [] defines a URI as
follows:
Just as there are many different methods of access to resources, there
are several schemes for describing the location of such resources.
The generic syntax for s provides a framework for
new schemes to be established using protocols other than those defined
in this document.
URLs are used to "locate" resources, by providing an abstract
identification of the resource location. Having located a resource, a
system may perform a variety of operations on the resource, as might
be characterized by such words as "access", "update", "replace", "find
attributes". In general, only the "access" method needs to be
specified for any scheme.
protected type UniversalResourceLocator
alias URL specializes ANY {
CS scheme;
ST address;
literal ST;
};
TEL (TelecommunicationAddress)
A telephone number (voice or fax), e-mail address, or other locator
for a resource mediated by telecommunication equipment. The address is
specified as a Universal Resource Locator (URL) qualified by time
specification and use codes that help in deciding which address to use
for a given time and purpose.
The semantics of a telecommunication address is that a communicating
entity (the responder) listens and responds to that address, and
therefore can be contacted by an other communicating entity (the
initiator.)
The responder of a telecommunication address may be an automatic
service that can respond with information (e.g., FTP or HTTP
services.) In such case a telecommunication address is a reference to
that information accessible through that address. A telecommunication
address value can thus be resolved to some information (in the form of
encapsulated data, .)
The telecommunication address is an extension of the Universal
Resource Locator ( ) specified according to Internet
standard RFC 2396 [].
The specifies the protocol and the contact point
defined by that protocol for the resource. Notable use cases for the
telecommunication address data type are for telephone and fax numbers,
e-mail addresses, Hypertext references, FTP references, etc.
type TelecommunicationAddress alias TEL specializes URL {
GTS useablePeriod;
SET<CS> use;
};
A telephone number (voice or fax), e-mail address, or other locator
for a resource mediated by telecommunication equipment. The address is
specified as a Universal Resource Locator (URL) qualified by time
specification and use codes that help in deciding which address to use
for a given time and purpose.
The semantics of a telecommunication address is that a communicating
entity (the responder) listens and responds to that address, and
therefore can be contacted by an other communicating entity (the
initiator.)
The responder of a telecommunication address may be an automatic
service that can respond with information (e.g., FTP or HTTP
services.) In such case a telecommunication address is a reference to
that information accessible through that address. A telecommunication
address value can thus be resolved to some information (in the form of
encapsulated data, .)
The telecommunication address is an extension of the Universal
Resource Locator ( ) specified according to Internet
standard RFC 2396 [].
The specifies the protocol and the contact point
defined by that protocol for the resource. Notable use cases for the
telecommunication address data type are for telephone and fax numbers,
e-mail addresses, Hypertext references, FTP references, etc.
type TelecommunicationAddress alias TEL specializes URL {
GTS useablePeriod;
SET<CS> use;
};
A telephone number (voice or fax), e-mail address, or other locator
for a resource mediated by telecommunication equipment. The address is
specified as a Universal Resource Locator (URL) qualified by time
specification and use codes that help in deciding which address to use
for a given time and purpose.
The semantics of a telecommunication address is that a communicating
entity (the responder) listens and responds to that address, and
therefore can be contacted by an other communicating entity (the
initiator.)
The responder of a telecommunication address may be an automatic
service that can respond with information (e.g., FTP or HTTP
services.) In such case a telecommunication address is a reference to
that information accessible through that address. A telecommunication
address value can thus be resolved to some information (in the form of
encapsulated data, .)
The telecommunication address is an extension of the Universal
Resource Locator ( ) specified according to Internet
standard RFC 2396 [].
The specifies the protocol and the contact point
defined by that protocol for the resource. Notable use cases for the
telecommunication address data type are for telephone and fax numbers,
e-mail addresses, Hypertext references, FTP references, etc.
type TelecommunicationAddress alias TEL specializes URL {
GTS useablePeriod;
SET<CS> use;
};
A telephone number (voice or fax), e-mail address, or other locator
for a resource mediated by telecommunication equipment. The address is
specified as a Universal Resource Locator (URL) qualified by time
specification and use codes that help in deciding which address to use
for a given time and purpose.
The semantics of a telecommunication address is that a communicating
entity (the responder) listens and responds to that address, and
therefore can be contacted by an other communicating entity (the
initiator.)
The responder of a telecommunication address may be an automatic
service that can respond with information (e.g., FTP or HTTP
services.) In such case a telecommunication address is a reference to
that information accessible through that address. A telecommunication
address value can thus be resolved to some information (in the form of
encapsulated data, .)
The telecommunication address is an extension of the Universal
Resource Locator ( ) specified according to Internet
standard RFC 2396 [].
The specifies the protocol and the contact point
defined by that protocol for the resource. Notable use cases for the
telecommunication address data type are for telephone and fax numbers,
e-mail addresses, Hypertext references, FTP references, etc.
type TelecommunicationAddress alias TEL specializes URL {
GTS useablePeriod;
SET<CS> use;
};
ADXP (AddressPart)
A character string that may have a type-tag signifying its role in the
address. Typical parts that exist in about every address are street,
house number, or post box, postal code, city, country but other roles
may be defined regionally, nationally, or on an enterprise level
(e.g. in military addresses). Addresses are usually broken up into
lines, which are indicated by special line-breaking delimiter elements
(e.g., DEL).
protected type AddressPart alias ADXP specializes ST {
CS partType;
};
A character string that may have a type-tag signifying its role in the
address. Typical parts that exist in about every address are street,
house number, or post box, postal code, city, country but other roles
may be defined regionally, nationally, or on an enterprise level
(e.g. in military addresses). Addresses are usually broken up into
lines, which are indicated by special line-breaking delimiter elements
(e.g., DEL).
protected type AddressPart alias ADXP specializes ST {
CS partType;
};
AD (PostalAddress)
Mailing and home or office addresses. A sequence of address parts,
such as street or post office Box, city, postal code, country, etc.
The is primarily used to communicate data that will allow
printing mail labels, that will allow a person to physically visit
that address. The postal address data type is not supposed to be a
container for additional information that might be useful for finding
geographic locations (e.g., GPS coordinates) or for performing
epidemiological studies. Such additional information is captured by
other, more appropriate HL7 elements.
Addresses are conceptualized as text with added logical mark-up. The
mark-up may break the address into lines and may describe in detail
the role of each address part if it is known. Address parts occur in
the address in the order in which they would be printed on a mailing
label. The approach is similar to HTML or XML markup of text (but it
is not technically limited to XML representations.)
Addresses are essentially sequences of address parts, but add a "use"
code and a valid time range for information about if and when the
address can be used for a given purpose.
type PostalAddress alias AD specializes LIST<ADXP> {
SET<CS> use;
GTS useablePeriod;
BL isNotOrdered;
ST formatted;
};
Mailing and home or office addresses. A sequence of address parts,
such as street or post office Box, city, postal code, country, etc.
The is primarily used to communicate data that will allow
printing mail labels, that will allow a person to physically visit
that address. The postal address data type is not supposed to be a
container for additional information that might be useful for finding
geographic locations (e.g., GPS coordinates) or for performing
epidemiological studies. Such additional information is captured by
other, more appropriate HL7 elements.
Addresses are conceptualized as text with added logical mark-up. The
mark-up may break the address into lines and may describe in detail
the role of each address part if it is known. Address parts occur in
the address in the order in which they would be printed on a mailing
label. The approach is similar to HTML or XML markup of text (but it
is not technically limited to XML representations.)
Addresses are essentially sequences of address parts, but add a "use"
code and a valid time range for information about if and when the
address can be used for a given purpose.
type PostalAddress alias AD specializes LIST<ADXP> {
SET<CS> use;
GTS useablePeriod;
BL isNotOrdered;
ST formatted;
};
Mailing and home or office addresses. A sequence of address parts,
such as street or post office Box, city, postal code, country, etc.
The is primarily used to communicate data that will allow
printing mail labels, that will allow a person to physically visit
that address. The postal address data type is not supposed to be a
container for additional information that might be useful for finding
geographic locations (e.g., GPS coordinates) or for performing
epidemiological studies. Such additional information is captured by
other, more appropriate HL7 elements.
Addresses are conceptualized as text with added logical mark-up. The
mark-up may break the address into lines and may describe in detail
the role of each address part if it is known. Address parts occur in
the address in the order in which they would be printed on a mailing
label. The approach is similar to HTML or XML markup of text (but it
is not technically limited to XML representations.)
Addresses are essentially sequences of address parts, but add a "use"
code and a valid time range for information about if and when the
address can be used for a given purpose.
type PostalAddress alias AD specializes LIST<ADXP> {
SET<CS> use;
GTS useablePeriod;
BL isNotOrdered;
ST formatted;
};
Mailing and home or office addresses. A sequence of address parts,
such as street or post office Box, city, postal code, country, etc.
The is primarily used to communicate data that will allow
printing mail labels, that will allow a person to physically visit
that address. The postal address data type is not supposed to be a
container for additional information that might be useful for finding
geographic locations (e.g., GPS coordinates) or for performing
epidemiological studies. Such additional information is captured by
other, more appropriate HL7 elements.
Addresses are conceptualized as text with added logical mark-up. The
mark-up may break the address into lines and may describe in detail
the role of each address part if it is known. Address parts occur in
the address in the order in which they would be printed on a mailing
label. The approach is similar to HTML or XML markup of text (but it
is not technically limited to XML representations.)
Addresses are essentially sequences of address parts, but add a "use"
code and a valid time range for information about if and when the
address can be used for a given purpose.
type PostalAddress alias AD specializes LIST<ADXP> {
SET<CS> use;
GTS useablePeriod;
BL isNotOrdered;
ST formatted;
};
Mailing and home or office addresses. A sequence of address parts,
such as street or post office Box, city, postal code, country, etc.
The is primarily used to communicate data that will allow
printing mail labels, that will allow a person to physically visit
that address. The postal address data type is not supposed to be a
container for additional information that might be useful for finding
geographic locations (e.g., GPS coordinates) or for performing
epidemiological studies. Such additional information is captured by
other, more appropriate HL7 elements.
Addresses are conceptualized as text with added logical mark-up. The
mark-up may break the address into lines and may describe in detail
the role of each address part if it is known. Address parts occur in
the address in the order in which they would be printed on a mailing
label. The approach is similar to HTML or XML markup of text (but it
is not technically limited to XML representations.)
Addresses are essentially sequences of address parts, but add a "use"
code and a valid time range for information about if and when the
address can be used for a given purpose.
type PostalAddress alias AD specializes LIST<ADXP> {
SET<CS> use;
GTS useablePeriod;
BL isNotOrdered;
ST formatted;
};
Mailing and home or office addresses. A sequence of address parts,
such as street or post office Box, city, postal code, country, etc.
The is primarily used to communicate data that will allow
printing mail labels, that will allow a person to physically visit
that address. The postal address data type is not supposed to be a
container for additional information that might be useful for finding
geographic locations (e.g., GPS coordinates) or for performing
epidemiological studies. Such additional information is captured by
other, more appropriate HL7 elements.
Addresses are conceptualized as text with added logical mark-up. The
mark-up may break the address into lines and may describe in detail
the role of each address part if it is known. Address parts occur in
the address in the order in which they would be printed on a mailing
label. The approach is similar to HTML or XML markup of text (but it
is not technically limited to XML representations.)
Addresses are essentially sequences of address parts, but add a "use"
code and a valid time range for information about if and when the
address can be used for a given purpose.
type PostalAddress alias AD specializes LIST<ADXP> {
SET<CS> use;
GTS useablePeriod;
BL isNotOrdered;
ST formatted;
};
ENXP (EntityNamePart)
A character string token representing a part of a name. May have a
type code signifying the role of the part in the whole entity name,
and a qualifier code for more detail about the name part type.
Typical name parts for person names are given names, and family names,
titles, etc.
protected type EntityNamePart alias ENXP specializes ST {
CS partType;
SET<CS> qualifier;
};
A character string token representing a part of a name. May have a
type code signifying the role of the part in the whole entity name,
and a qualifier code for more detail about the name part type.
Typical name parts for person names are given names, and family names,
titles, etc.
protected type EntityNamePart alias ENXP specializes ST {
CS partType;
SET<CS> qualifier;
};
A character string token representing a part of a name. May have a
type code signifying the role of the part in the whole entity name,
and a qualifier code for more detail about the name part type.
Typical name parts for person names are given names, and family names,
titles, etc.
protected type EntityNamePart alias ENXP specializes ST {
CS partType;
SET<CS> qualifier;
};
EN (EntityName)
A name for a person, organization, place or thing. A sequence of name
parts, such as given name or family name, prefix, suffix, etc.
Examples for entity name values are "Jim Bob Walton, Jr.", "Health
Level Seven, Inc.", "Lake Tahoe", etc. An entity name may be as simple
as a character string or may consist of several entity name parts,
such as, "Jim", "Bob", "Walton", and "Jr.", "Health Level Seven" and
"Inc.", "Lake" and "Tahoe".
Entity names are conceptualized as text with added logical mark-up.
Name parts occur in a natural order in which they would be displayed,
as opposed to in a order detemined by name part. The ordeing of the
name parts is significant a feature that replaces the need for a
separate "display name" property. Applications may change that
ordering of name parts to account for their user's customary ordering
of name parts. The approach is similar to HTML or XML markup of text
(but it is not technically limited to XML representations.)
Entity names are essentially sequences of entity name parts, but add a
"use" code and a valid time range for information about when the name
was used and how to choose between multiple aliases that may be valid
at the same point in time.
Three restrictions to Entity Name are defined in order to allow making
specific constraints for certain kinds of entities, trivial name
( ), person name ( ), and
organization name ( ).
A very simple encoding of "Adam A. Everyman" would be:
Adam
A.
Everyman
None of the special qualifiers need to be mentioned if they are
unknown or irrelevant. The next example shows extensive use of
multiple given names, prefixes, suffixes, for academic degrees,
nobility titles, vorvoegsels ("van"), and professional
designations.
Dr. phil.
Regina
Johanna
Maria
Graefin
Hochheim-Weilenfels
NCFSA
The next example is an organization name, "Health Level Seven, Inc."
in simple string form:
Health Level Seven, Inc.
and as a fully parsed name
Health Level Seven, Inc.
The following example shows a Japanese name in the three forms:
ideographic (Kanji), syllabic (Hiragana), and alphabetic (Romaji).
??
??
???
???
KIMURA
MICHIO
type EntityName alias EN specializes LIST<ENXP> {
SET<CS> use;
IVL<TS> validTime;
ST formatted;
};
A name for a person, organization, place or thing. A sequence of name
parts, such as given name or family name, prefix, suffix, etc.
Examples for entity name values are "Jim Bob Walton, Jr.", "Health
Level Seven, Inc.", "Lake Tahoe", etc. An entity name may be as simple
as a character string or may consist of several entity name parts,
such as, "Jim", "Bob", "Walton", and "Jr.", "Health Level Seven" and
"Inc.", "Lake" and "Tahoe".
Entity names are conceptualized as text with added logical mark-up.
Name parts occur in a natural order in which they would be displayed,
as opposed to in a order detemined by name part. The ordeing of the
name parts is significant a feature that replaces the need for a
separate "display name" property. Applications may change that
ordering of name parts to account for their user's customary ordering
of name parts. The approach is similar to HTML or XML markup of text
(but it is not technically limited to XML representations.)
Entity names are essentially sequences of entity name parts, but add a
"use" code and a valid time range for information about when the name
was used and how to choose between multiple aliases that may be valid
at the same point in time.
Three restrictions to Entity Name are defined in order to allow making
specific constraints for certain kinds of entities, trivial name
( ), person name ( ), and
organization name ( ).
A very simple encoding of "Adam A. Everyman" would be:
Adam
A.
Everyman
None of the special qualifiers need to be mentioned if they are
unknown or irrelevant. The next example shows extensive use of
multiple given names, prefixes, suffixes, for academic degrees,
nobility titles, vorvoegsels ("van"), and professional
designations.
Dr. phil.
Regina
Johanna
Maria
Graefin
Hochheim-Weilenfels
NCFSA
The next example is an organization name, "Health Level Seven, Inc."
in simple string form:
Health Level Seven, Inc.
and as a fully parsed name
Health Level Seven, Inc.
The following example shows a Japanese name in the three forms:
ideographic (Kanji), syllabic (Hiragana), and alphabetic (Romaji).
??
??
???
???
KIMURA
MICHIO
type EntityName alias EN specializes LIST<ENXP> {
SET<CS> use;
IVL<TS> validTime;
ST formatted;
};
A name for a person, organization, place or thing. A sequence of name
parts, such as given name or family name, prefix, suffix, etc.
Examples for entity name values are "Jim Bob Walton, Jr.", "Health
Level Seven, Inc.", "Lake Tahoe", etc. An entity name may be as simple
as a character string or may consist of several entity name parts,
such as, "Jim", "Bob", "Walton", and "Jr.", "Health Level Seven" and
"Inc.", "Lake" and "Tahoe".
Entity names are conceptualized as text with added logical mark-up.
Name parts occur in a natural order in which they would be displayed,
as opposed to in a order detemined by name part. The ordeing of the
name parts is significant a feature that replaces the need for a
separate "display name" property. Applications may change that
ordering of name parts to account for their user's customary ordering
of name parts. The approach is similar to HTML or XML markup of text
(but it is not technically limited to XML representations.)
Entity names are essentially sequences of entity name parts, but add a
"use" code and a valid time range for information about when the name
was used and how to choose between multiple aliases that may be valid
at the same point in time.
Three restrictions to Entity Name are defined in order to allow making
specific constraints for certain kinds of entities, trivial name
( ), person name ( ), and
organization name ( ).
A very simple encoding of "Adam A. Everyman" would be:
Adam
A.
Everyman
None of the special qualifiers need to be mentioned if they are
unknown or irrelevant. The next example shows extensive use of
multiple given names, prefixes, suffixes, for academic degrees,
nobility titles, vorvoegsels ("van"), and professional
designations.
Dr. phil.
Regina
Johanna
Maria
Graefin
Hochheim-Weilenfels
NCFSA
The next example is an organization name, "Health Level Seven, Inc."
in simple string form:
Health Level Seven, Inc.
and as a fully parsed name
Health Level Seven, Inc.
The following example shows a Japanese name in the three forms:
ideographic (Kanji), syllabic (Hiragana), and alphabetic (Romaji).
??
??
???
???
KIMURA
MICHIO
type EntityName alias EN specializes LIST<ENXP> {
SET<CS> use;
IVL<TS> validTime;
ST formatted;
};
A name for a person, organization, place or thing. A sequence of name
parts, such as given name or family name, prefix, suffix, etc.
Examples for entity name values are "Jim Bob Walton, Jr.", "Health
Level Seven, Inc.", "Lake Tahoe", etc. An entity name may be as simple
as a character string or may consist of several entity name parts,
such as, "Jim", "Bob", "Walton", and "Jr.", "Health Level Seven" and
"Inc.", "Lake" and "Tahoe".
Entity names are conceptualized as text with added logical mark-up.
Name parts occur in a natural order in which they would be displayed,
as opposed to in a order detemined by name part. The ordeing of the
name parts is significant a feature that replaces the need for a
separate "display name" property. Applications may change that
ordering of name parts to account for their user's customary ordering
of name parts. The approach is similar to HTML or XML markup of text
(but it is not technically limited to XML representations.)
Entity names are essentially sequences of entity name parts, but add a
"use" code and a valid time range for information about when the name
was used and how to choose between multiple aliases that may be valid
at the same point in time.
Three restrictions to Entity Name are defined in order to allow making
specific constraints for certain kinds of entities, trivial name
( ), person name ( ), and
organization name ( ).
A very simple encoding of "Adam A. Everyman" would be:
Adam
A.
Everyman
None of the special qualifiers need to be mentioned if they are
unknown or irrelevant. The next example shows extensive use of
multiple given names, prefixes, suffixes, for academic degrees,
nobility titles, vorvoegsels ("van"), and professional
designations.
Dr. phil.
Regina
Johanna
Maria
Graefin
Hochheim-Weilenfels
NCFSA
The next example is an organization name, "Health Level Seven, Inc."
in simple string form:
Health Level Seven, Inc.
and as a fully parsed name
Health Level Seven, Inc.
The following example shows a Japanese name in the three forms:
ideographic (Kanji), syllabic (Hiragana), and alphabetic (Romaji).
??
??
???
???
KIMURA
MICHIO
type EntityName alias EN specializes LIST<ENXP> {
SET<CS> use;
IVL<TS> validTime;
ST formatted;
};
A name for a person, organization, place or thing. A sequence of name
parts, such as given name or family name, prefix, suffix, etc.
Examples for entity name values are "Jim Bob Walton, Jr.", "Health
Level Seven, Inc.", "Lake Tahoe", etc. An entity name may be as simple
as a character string or may consist of several entity name parts,
such as, "Jim", "Bob", "Walton", and "Jr.", "Health Level Seven" and
"Inc.", "Lake" and "Tahoe".
Entity names are conceptualized as text with added logical mark-up.
Name parts occur in a natural order in which they would be displayed,
as opposed to in a order detemined by name part. The ordeing of the
name parts is significant a feature that replaces the need for a
separate "display name" property. Applications may change that
ordering of name parts to account for their user's customary ordering
of name parts. The approach is similar to HTML or XML markup of text
(but it is not technically limited to XML representations.)
Entity names are essentially sequences of entity name parts, but add a
"use" code and a valid time range for information about when the name
was used and how to choose between multiple aliases that may be valid
at the same point in time.
Three restrictions to Entity Name are defined in order to allow making
specific constraints for certain kinds of entities, trivial name
( ), person name ( ), and
organization name ( ).
A very simple encoding of "Adam A. Everyman" would be:
Adam
A.
Everyman
None of the special qualifiers need to be mentioned if they are
unknown or irrelevant. The next example shows extensive use of
multiple given names, prefixes, suffixes, for academic degrees,
nobility titles, vorvoegsels ("van"), and professional
designations.
Dr. phil.
Regina
Johanna
Maria
Graefin
Hochheim-Weilenfels
NCFSA
The next example is an organization name, "Health Level Seven, Inc."
in simple string form:
Health Level Seven, Inc.
and as a fully parsed name
Health Level Seven, Inc.
The following example shows a Japanese name in the three forms:
ideographic (Kanji), syllabic (Hiragana), and alphabetic (Romaji).
??
??
???
???
KIMURA
MICHIO
type EntityName alias EN specializes LIST<ENXP> {
SET<CS> use;
IVL<TS> validTime;
ST formatted;
};
TN (TrivialName)
A restriction of entity name that is effectively a simple string used
for a simple name for things and places.
The is a that consists of only one name
part without any name part type or qualifier. The , and its
single name part are therefore equivalent to a simple character
string. This equivalence is expressed by a defined demotion to
and promotion from .
Trivial names are typically used for places and things, such as
Lake Erie or Reagan National Airport:
type TrivialName alias TN specializes EN {
demotion ST;
promotion TN (ST x);
};
A restriction of entity name that is effectively a simple string used
for a simple name for things and places.
The is a that consists of only one name
part without any name part type or qualifier. The , and its
single name part are therefore equivalent to a simple character
string. This equivalence is expressed by a defined demotion to
and promotion from .
Trivial names are typically used for places and things, such as
Lake Erie or Reagan National Airport:
type TrivialName alias TN specializes EN {
demotion ST;
promotion TN (ST x);
};
A restriction of entity name that is effectively a simple string used
for a simple name for things and places.
The is a that consists of only one name
part without any name part type or qualifier. The , and its
single name part are therefore equivalent to a simple character
string. This equivalence is expressed by a defined demotion to
and promotion from .
Trivial names are typically used for places and things, such as
Lake Erie or Reagan National Airport:
type TrivialName alias TN specializes EN {
demotion ST;
promotion TN (ST x);
};
PN (PersonName)
An used when the named Entity
is a Person. A sequence of name parts, such as given name or
family name, prefix, suffix, etc. A name part is a restriction of
entity name part that only allows those entity name parts qualifiers
applicable to person names. Since the structure of entity name is
mostly determined by the requirements of person name, the restriction
is very minor.
Since most of the functionality of entity name is in support of person
names, the person name ( ) is only a very minor
restriction on the entity name part qualifier.
type PersonName alias PN specializes EN;
ON (OrganizationName)
An used when the named Entity
is an Organization. A sequence of name parts.
A name for an organization, such as "Health Level Seven, Inc." An
organization name consists only of untyped name parts, prefixes,
suffixes, and delimiters.
The following is the organization name, "Health Level Seven, Inc." in
a simple string form:
Health Level Seven, Inc.;
And with the legal status "Inc." as a distinguished name part:
Health Level Seven, Inc.
type OrganizationName alias ON specializes EN;
QTY (Quantity)
The quantity data type is an abstract generalization for all data
types (1) whose value set has an order relation (less-or-equal) and
(2) where difference is defined in all of the data type's totally
ordered value subsets. The quantity type abstraction is needed in
defining certain other types, such as the interval and the probability
distribution.
abstract type Quantity alias QTY specializes ANY {
BL lessOrEqual(QTY x);
BL compares(QTY x);
TYPE diffType;
QTY minus(QTY x);
QTY plus(QTY x);
BL isZero;
BL lessThan(QTY x);
BL greaterOrEqual(QTY x);
BL greaterThan(QTY x);
};
The quantity data type is an abstract generalization for all data
types (1) whose value set has an order relation (less-or-equal) and
(2) where difference is defined in all of the data type's totally
ordered value subsets. The quantity type abstraction is needed in
defining certain other types, such as the interval and the probability
distribution.
abstract type Quantity alias QTY specializes ANY {
BL lessOrEqual(QTY x);
BL compares(QTY x);
TYPE diffType;
QTY minus(QTY x);
QTY plus(QTY x);
BL isZero;
BL lessThan(QTY x);
BL greaterOrEqual(QTY x);
BL greaterThan(QTY x);
};
The quantity data type is an abstract generalization for all data
types (1) whose value set has an order relation (less-or-equal) and
(2) where difference is defined in all of the data type's totally
ordered value subsets. The quantity type abstraction is needed in
defining certain other types, such as the interval and the probability
distribution.
abstract type Quantity alias QTY specializes ANY {
BL lessOrEqual(QTY x);
BL compares(QTY x);
TYPE diffType;
QTY minus(QTY x);
QTY plus(QTY x);
BL isZero;
BL lessThan(QTY x);
BL greaterOrEqual(QTY x);
BL greaterThan(QTY x);
};
The quantity data type is an abstract generalization for all data
types (1) whose value set has an order relation (less-or-equal) and
(2) where difference is defined in all of the data type's totally
ordered value subsets. The quantity type abstraction is needed in
defining certain other types, such as the interval and the probability
distribution.
abstract type Quantity alias QTY specializes ANY {
BL lessOrEqual(QTY x);
BL compares(QTY x);
TYPE diffType;
QTY minus(QTY x);
QTY plus(QTY x);
BL isZero;
BL lessThan(QTY x);
BL greaterOrEqual(QTY x);
BL greaterThan(QTY x);
};
The quantity data type is an abstract generalization for all data
types (1) whose value set has an order relation (less-or-equal) and
(2) where difference is defined in all of the data type's totally
ordered value subsets. The quantity type abstraction is needed in
defining certain other types, such as the interval and the probability
distribution.
abstract type Quantity alias QTY specializes ANY {
BL lessOrEqual(QTY x);
BL compares(QTY x);
TYPE diffType;
QTY minus(QTY x);
QTY plus(QTY x);
BL isZero;
BL lessThan(QTY x);
BL greaterOrEqual(QTY x);
BL greaterThan(QTY x);
};
The quantity data type is an abstract generalization for all data
types (1) whose value set has an order relation (less-or-equal) and
(2) where difference is defined in all of the data type's totally
ordered value subsets. The quantity type abstraction is needed in
defining certain other types, such as the interval and the probability
distribution.
abstract type Quantity alias QTY specializes ANY {
BL lessOrEqual(QTY x);
BL compares(QTY x);
TYPE diffType;
QTY minus(QTY x);
QTY plus(QTY x);
BL isZero;
BL lessThan(QTY x);
BL greaterOrEqual(QTY x);
BL greaterThan(QTY x);
};
The quantity data type is an abstract generalization for all data
types (1) whose value set has an order relation (less-or-equal) and
(2) where difference is defined in all of the data type's totally
ordered value subsets. The quantity type abstraction is needed in
defining certain other types, such as the interval and the probability
distribution.
abstract type Quantity alias QTY specializes ANY {
BL lessOrEqual(QTY x);
BL compares(QTY x);
TYPE diffType;
QTY minus(QTY x);
QTY plus(QTY x);
BL isZero;
BL lessThan(QTY x);
BL greaterOrEqual(QTY x);
BL greaterThan(QTY x);
};
The quantity data type is an abstract generalization for all data
types (1) whose value set has an order relation (less-or-equal) and
(2) where difference is defined in all of the data type's totally
ordered value subsets. The quantity type abstraction is needed in
defining certain other types, such as the interval and the probability
distribution.
abstract type Quantity alias QTY specializes ANY {
BL lessOrEqual(QTY x);
BL compares(QTY x);
TYPE diffType;
QTY minus(QTY x);
QTY plus(QTY x);
BL isZero;
BL lessThan(QTY x);
BL greaterOrEqual(QTY x);
BL greaterThan(QTY x);
};
The quantity data type is an abstract generalization for all data
types (1) whose value set has an order relation (less-or-equal) and
(2) where difference is defined in all of the data type's totally
ordered value subsets. The quantity type abstraction is needed in
defining certain other types, such as the interval and the probability
distribution.
abstract type Quantity alias QTY specializes ANY {
BL lessOrEqual(QTY x);
BL compares(QTY x);
TYPE diffType;
QTY minus(QTY x);
QTY plus(QTY x);
BL isZero;
BL lessThan(QTY x);
BL greaterOrEqual(QTY x);
BL greaterThan(QTY x);
};
The quantity data type is an abstract generalization for all data
types (1) whose value set has an order relation (less-or-equal) and
(2) where difference is defined in all of the data type's totally
ordered value subsets. The quantity type abstraction is needed in
defining certain other types, such as the interval and the probability
distribution.
abstract type Quantity alias QTY specializes ANY {
BL lessOrEqual(QTY x);
BL compares(QTY x);
TYPE diffType;
QTY minus(QTY x);
QTY plus(QTY x);
BL isZero;
BL lessThan(QTY x);
BL greaterOrEqual(QTY x);
BL greaterThan(QTY x);
};
The quantity data type is an abstract generalization for all data
types (1) whose value set has an order relation (less-or-equal) and
(2) where difference is defined in all of the data type's totally
ordered value subsets. The quantity type abstraction is needed in
defining certain other types, such as the interval and the probability
distribution.
abstract type Quantity alias QTY specializes ANY {
BL lessOrEqual(QTY x);
BL compares(QTY x);
TYPE diffType;
QTY minus(QTY x);
QTY plus(QTY x);
BL isZero;
BL lessThan(QTY x);
BL greaterOrEqual(QTY x);
BL greaterThan(QTY x);
};
INT (IntegerNumber)
Integer numbers (-1,0,1,2, 100, 3398129, etc.) are precise numbers
that are results of counting and enumerating. Integer numbers are
discrete, the set of integers is infinite but countable. No arbitrary
limit is imposed on the range of integer numbers. Two NULL flavors are
defined for the positive and negative infinity.
Since the integer number data type includes all of the semantics of
the mathematical integer number concept, the basic operations plus
(addition) and times (multiplication) are defined. These operations
are defined here as characterizing operations in the sense of ISO
11404, and because these operations are needed in other parts of this
specification, namely the semantics of the literal form.
The traditional recursive definitions of addition and multiplication
are due to Grassmann, and use the notion of .
H. Grassman. Lehrbuch der Arithmetik. 1861. We prefer
Grassman's original axioms to the Peano axioms, because Grassman's
axioms work for all integers, not just for natural numbers. Also, "it
is rather well-known, through Peano's own acknowledgment, that Peano
borrowed his axioms from Dedekind and made extensive use of
Grassmann's work in his development of the axioms." (Hao Wang. The
Axiomatization of Arithmetic. J. Symb. Logic; 1957:22(2); p. 145.)
type IntegerNumber alias INT specializes QTY {
INT successor;
INT plus(QTY x);
INT times(INT x);
INT predecessor;
INT negated;
BL nonNegative;
BL isNegative;
INT dividedBy(INT x);
INT remainder(INT x);
BL isOne;
literal ST;
};
Integer numbers (-1,0,1,2, 100, 3398129, etc.) are precise numbers
that are results of counting and enumerating. Integer numbers are
discrete, the set of integers is infinite but countable. No arbitrary
limit is imposed on the range of integer numbers. Two NULL flavors are
defined for the positive and negative infinity.
Since the integer number data type includes all of the semantics of
the mathematical integer number concept, the basic operations plus
(addition) and times (multiplication) are defined. These operations
are defined here as characterizing operations in the sense of ISO
11404, and because these operations are needed in other parts of this
specification, namely the semantics of the literal form.
The traditional recursive definitions of addition and multiplication
are due to Grassmann, and use the notion of .
H. Grassman. Lehrbuch der Arithmetik. 1861. We prefer
Grassman's original axioms to the Peano axioms, because Grassman's
axioms work for all integers, not just for natural numbers. Also, "it
is rather well-known, through Peano's own acknowledgment, that Peano
borrowed his axioms from Dedekind and made extensive use of
Grassmann's work in his development of the axioms." (Hao Wang. The
Axiomatization of Arithmetic. J. Symb. Logic; 1957:22(2); p. 145.)
type IntegerNumber alias INT specializes QTY {
INT successor;
INT plus(QTY x);
INT times(INT x);
INT predecessor;
INT negated;
BL nonNegative;
BL isNegative;
INT dividedBy(INT x);
INT remainder(INT x);
BL isOne;
literal ST;
};
Integer numbers (-1,0,1,2, 100, 3398129, etc.) are precise numbers
that are results of counting and enumerating. Integer numbers are
discrete, the set of integers is infinite but countable. No arbitrary
limit is imposed on the range of integer numbers. Two NULL flavors are
defined for the positive and negative infinity.
Since the integer number data type includes all of the semantics of
the mathematical integer number concept, the basic operations plus
(addition) and times (multiplication) are defined. These operations
are defined here as characterizing operations in the sense of ISO
11404, and because these operations are needed in other parts of this
specification, namely the semantics of the literal form.
The traditional recursive definitions of addition and multiplication
are due to Grassmann, and use the notion of .
H. Grassman. Lehrbuch der Arithmetik. 1861. We prefer
Grassman's original axioms to the Peano axioms, because Grassman's
axioms work for all integers, not just for natural numbers. Also, "it
is rather well-known, through Peano's own acknowledgment, that Peano
borrowed his axioms from Dedekind and made extensive use of
Grassmann's work in his development of the axioms." (Hao Wang. The
Axiomatization of Arithmetic. J. Symb. Logic; 1957:22(2); p. 145.)
type IntegerNumber alias INT specializes QTY {
INT successor;
INT plus(QTY x);
INT times(INT x);
INT predecessor;
INT negated;
BL nonNegative;
BL isNegative;
INT dividedBy(INT x);
INT remainder(INT x);
BL isOne;
literal ST;
};
Integer numbers (-1,0,1,2, 100, 3398129, etc.) are precise numbers
that are results of counting and enumerating. Integer numbers are
discrete, the set of integers is infinite but countable. No arbitrary
limit is imposed on the range of integer numbers. Two NULL flavors are
defined for the positive and negative infinity.
Since the integer number data type includes all of the semantics of
the mathematical integer number concept, the basic operations plus
(addition) and times (multiplication) are defined. These operations
are defined here as characterizing operations in the sense of ISO
11404, and because these operations are needed in other parts of this
specification, namely the semantics of the literal form.
The traditional recursive definitions of addition and multiplication
are due to Grassmann, and use the notion of .
H. Grassman. Lehrbuch der Arithmetik. 1861. We prefer
Grassman's original axioms to the Peano axioms, because Grassman's
axioms work for all integers, not just for natural numbers. Also, "it
is rather well-known, through Peano's own acknowledgment, that Peano
borrowed his axioms from Dedekind and made extensive use of
Grassmann's work in his development of the axioms." (Hao Wang. The
Axiomatization of Arithmetic. J. Symb. Logic; 1957:22(2); p. 145.)
type IntegerNumber alias INT specializes QTY {
INT successor;
INT plus(QTY x);
INT times(INT x);
INT predecessor;
INT negated;
BL nonNegative;
BL isNegative;
INT dividedBy(INT x);
INT remainder(INT x);
BL isOne;
literal ST;
};
Integer numbers (-1,0,1,2, 100, 3398129, etc.) are precise numbers
that are results of counting and enumerating. Integer numbers are
discrete, the set of integers is infinite but countable. No arbitrary
limit is imposed on the range of integer numbers. Two NULL flavors are
defined for the positive and negative infinity.
Since the integer number data type includes all of the semantics of
the mathematical integer number concept, the basic operations plus
(addition) and times (multiplication) are defined. These operations
are defined here as characterizing operations in the sense of ISO
11404, and because these operations are needed in other parts of this
specification, namely the semantics of the literal form.
The traditional recursive definitions of addition and multiplication
are due to Grassmann, and use the notion of .
H. Grassman. Lehrbuch der Arithmetik. 1861. We prefer
Grassman's original axioms to the Peano axioms, because Grassman's
axioms work for all integers, not just for natural numbers. Also, "it
is rather well-known, through Peano's own acknowledgment, that Peano
borrowed his axioms from Dedekind and made extensive use of
Grassmann's work in his development of the axioms." (Hao Wang. The
Axiomatization of Arithmetic. J. Symb. Logic; 1957:22(2); p. 145.)
type IntegerNumber alias INT specializes QTY {
INT successor;
INT plus(QTY x);
INT times(INT x);
INT predecessor;
INT negated;
BL nonNegative;
BL isNegative;
INT dividedBy(INT x);
INT remainder(INT x);
BL isOne;
literal ST;
};
Integer numbers (-1,0,1,2, 100, 3398129, etc.) are precise numbers
that are results of counting and enumerating. Integer numbers are
discrete, the set of integers is infinite but countable. No arbitrary
limit is imposed on the range of integer numbers. Two NULL flavors are
defined for the positive and negative infinity.
Since the integer number data type includes all of the semantics of
the mathematical integer number concept, the basic operations plus
(addition) and times (multiplication) are defined. These operations
are defined here as characterizing operations in the sense of ISO
11404, and because these operations are needed in other parts of this
specification, namely the semantics of the literal form.
The traditional recursive definitions of addition and multiplication
are due to Grassmann, and use the notion of .
H. Grassman. Lehrbuch der Arithmetik. 1861. We prefer
Grassman's original axioms to the Peano axioms, because Grassman's
axioms work for all integers, not just for natural numbers. Also, "it
is rather well-known, through Peano's own acknowledgment, that Peano
borrowed his axioms from Dedekind and made extensive use of
Grassmann's work in his development of the axioms." (Hao Wang. The
Axiomatization of Arithmetic. J. Symb. Logic; 1957:22(2); p. 145.)
type IntegerNumber alias INT specializes QTY {
INT successor;
INT plus(QTY x);
INT times(INT x);
INT predecessor;
INT negated;
BL nonNegative;
BL isNegative;
INT dividedBy(INT x);
INT remainder(INT x);
BL isOne;
literal ST;
};
Integer numbers (-1,0,1,2, 100, 3398129, etc.) are precise numbers
that are results of counting and enumerating. Integer numbers are
discrete, the set of integers is infinite but countable. No arbitrary
limit is imposed on the range of integer numbers. Two NULL flavors are
defined for the positive and negative infinity.
Since the integer number data type includes all of the semantics of
the mathematical integer number concept, the basic operations plus
(addition) and times (multiplication) are defined. These operations
are defined here as characterizing operations in the sense of ISO
11404, and because these operations are needed in other parts of this
specification, namely the semantics of the literal form.
The traditional recursive definitions of addition and multiplication
are due to Grassmann, and use the notion of .
H. Grassman. Lehrbuch der Arithmetik. 1861. We prefer
Grassman's original axioms to the Peano axioms, because Grassman's
axioms work for all integers, not just for natural numbers. Also, "it
is rather well-known, through Peano's own acknowledgment, that Peano
borrowed his axioms from Dedekind and made extensive use of
Grassmann's work in his development of the axioms." (Hao Wang. The
Axiomatization of Arithmetic. J. Symb. Logic; 1957:22(2); p. 145.)
type IntegerNumber alias INT specializes QTY {
INT successor;
INT plus(QTY x);
INT times(INT x);
INT predecessor;
INT negated;
BL nonNegative;
BL isNegative;
INT dividedBy(INT x);
INT remainder(INT x);
BL isOne;
literal ST;
};
Integer numbers (-1,0,1,2, 100, 3398129, etc.) are precise numbers
that are results of counting and enumerating. Integer numbers are
discrete, the set of integers is infinite but countable. No arbitrary
limit is imposed on the range of integer numbers. Two NULL flavors are
defined for the positive and negative infinity.
Since the integer number data type includes all of the semantics of
the mathematical integer number concept, the basic operations plus
(addition) and times (multiplication) are defined. These operations
are defined here as characterizing operations in the sense of ISO
11404, and because these operations are needed in other parts of this
specification, namely the semantics of the literal form.
The traditional recursive definitions of addition and multiplication
are due to Grassmann, and use the notion of .
H. Grassman. Lehrbuch der Arithmetik. 1861. We prefer
Grassman's original axioms to the Peano axioms, because Grassman's
axioms work for all integers, not just for natural numbers. Also, "it
is rather well-known, through Peano's own acknowledgment, that Peano
borrowed his axioms from Dedekind and made extensive use of
Grassmann's work in his development of the axioms." (Hao Wang. The
Axiomatization of Arithmetic. J. Symb. Logic; 1957:22(2); p. 145.)
type IntegerNumber alias INT specializes QTY {
INT successor;
INT plus(QTY x);
INT times(INT x);
INT predecessor;
INT negated;
BL nonNegative;
BL isNegative;
INT dividedBy(INT x);
INT remainder(INT x);
BL isOne;
literal ST;
};
Integer numbers (-1,0,1,2, 100, 3398129, etc.) are precise numbers
that are results of counting and enumerating. Integer numbers are
discrete, the set of integers is infinite but countable. No arbitrary
limit is imposed on the range of integer numbers. Two NULL flavors are
defined for the positive and negative infinity.
Since the integer number data type includes all of the semantics of
the mathematical integer number concept, the basic operations plus
(addition) and times (multiplication) are defined. These operations
are defined here as characterizing operations in the sense of ISO
11404, and because these operations are needed in other parts of this
specification, namely the semantics of the literal form.
The traditional recursive definitions of addition and multiplication
are due to Grassmann, and use the notion of .
H. Grassman. Lehrbuch der Arithmetik. 1861. We prefer
Grassman's original axioms to the Peano axioms, because Grassman's
axioms work for all integers, not just for natural numbers. Also, "it
is rather well-known, through Peano's own acknowledgment, that Peano
borrowed his axioms from Dedekind and made extensive use of
Grassmann's work in his development of the axioms." (Hao Wang. The
Axiomatization of Arithmetic. J. Symb. Logic; 1957:22(2); p. 145.)
type IntegerNumber alias INT specializes QTY {
INT successor;
INT plus(QTY x);
INT times(INT x);
INT predecessor;
INT negated;
BL nonNegative;
BL isNegative;
INT dividedBy(INT x);
INT remainder(INT x);
BL isOne;
literal ST;
};
Integer numbers (-1,0,1,2, 100, 3398129, etc.) are precise numbers
that are results of counting and enumerating. Integer numbers are
discrete, the set of integers is infinite but countable. No arbitrary
limit is imposed on the range of integer numbers. Two NULL flavors are
defined for the positive and negative infinity.
Since the integer number data type includes all of the semantics of
the mathematical integer number concept, the basic operations plus
(addition) and times (multiplication) are defined. These operations
are defined here as characterizing operations in the sense of ISO
11404, and because these operations are needed in other parts of this
specification, namely the semantics of the literal form.
The traditional recursive definitions of addition and multiplication
are due to Grassmann, and use the notion of .
H. Grassman. Lehrbuch der Arithmetik. 1861. We prefer
Grassman's original axioms to the Peano axioms, because Grassman's
axioms work for all integers, not just for natural numbers. Also, "it
is rather well-known, through Peano's own acknowledgment, that Peano
borrowed his axioms from Dedekind and made extensive use of
Grassmann's work in his development of the axioms." (Hao Wang. The
Axiomatization of Arithmetic. J. Symb. Logic; 1957:22(2); p. 145.)
type IntegerNumber alias INT specializes QTY {
INT successor;
INT plus(QTY x);
INT times(INT x);
INT predecessor;
INT negated;
BL nonNegative;
BL isNegative;
INT dividedBy(INT x);
INT remainder(INT x);
BL isOne;
literal ST;
};
Integer numbers (-1,0,1,2, 100, 3398129, etc.) are precise numbers
that are results of counting and enumerating. Integer numbers are
discrete, the set of integers is infinite but countable. No arbitrary
limit is imposed on the range of integer numbers. Two NULL flavors are
defined for the positive and negative infinity.
Since the integer number data type includes all of the semantics of
the mathematical integer number concept, the basic operations plus
(addition) and times (multiplication) are defined. These operations
are defined here as characterizing operations in the sense of ISO
11404, and because these operations are needed in other parts of this
specification, namely the semantics of the literal form.
The traditional recursive definitions of addition and multiplication
are due to Grassmann, and use the notion of .
H. Grassman. Lehrbuch der Arithmetik. 1861. We prefer
Grassman's original axioms to the Peano axioms, because Grassman's
axioms work for all integers, not just for natural numbers. Also, "it
is rather well-known, through Peano's own acknowledgment, that Peano
borrowed his axioms from Dedekind and made extensive use of
Grassmann's work in his development of the axioms." (Hao Wang. The
Axiomatization of Arithmetic. J. Symb. Logic; 1957:22(2); p. 145.)
type IntegerNumber alias INT specializes QTY {
INT successor;
INT plus(QTY x);
INT times(INT x);
INT predecessor;
INT negated;
BL nonNegative;
BL isNegative;
INT dividedBy(INT x);
INT remainder(INT x);
BL isOne;
literal ST;
};
Integer numbers (-1,0,1,2, 100, 3398129, etc.) are precise numbers
that are results of counting and enumerating. Integer numbers are
discrete, the set of integers is infinite but countable. No arbitrary
limit is imposed on the range of integer numbers. Two NULL flavors are
defined for the positive and negative infinity.
Since the integer number data type includes all of the semantics of
the mathematical integer number concept, the basic operations plus
(addition) and times (multiplication) are defined. These operations
are defined here as characterizing operations in the sense of ISO
11404, and because these operations are needed in other parts of this
specification, namely the semantics of the literal form.
The traditional recursive definitions of addition and multiplication
are due to Grassmann, and use the notion of .
H. Grassman. Lehrbuch der Arithmetik. 1861. We prefer
Grassman's original axioms to the Peano axioms, because Grassman's
axioms work for all integers, not just for natural numbers. Also, "it
is rather well-known, through Peano's own acknowledgment, that Peano
borrowed his axioms from Dedekind and made extensive use of
Grassmann's work in his development of the axioms." (Hao Wang. The
Axiomatization of Arithmetic. J. Symb. Logic; 1957:22(2); p. 145.)
type IntegerNumber alias INT specializes QTY {
INT successor;
INT plus(QTY x);
INT times(INT x);
INT predecessor;
INT negated;
BL nonNegative;
BL isNegative;
INT dividedBy(INT x);
INT remainder(INT x);
BL isOne;
literal ST;
};
Integer numbers (-1,0,1,2, 100, 3398129, etc.) are precise numbers
that are results of counting and enumerating. Integer numbers are
discrete, the set of integers is infinite but countable. No arbitrary
limit is imposed on the range of integer numbers. Two NULL flavors are
defined for the positive and negative infinity.
Since the integer number data type includes all of the semantics of
the mathematical integer number concept, the basic operations plus
(addition) and times (multiplication) are defined. These operations
are defined here as characterizing operations in the sense of ISO
11404, and because these operations are needed in other parts of this
specification, namely the semantics of the literal form.
The traditional recursive definitions of addition and multiplication
are due to Grassmann, and use the notion of .
H. Grassman. Lehrbuch der Arithmetik. 1861. We prefer
Grassman's original axioms to the Peano axioms, because Grassman's
axioms work for all integers, not just for natural numbers. Also, "it
is rather well-known, through Peano's own acknowledgment, that Peano
borrowed his axioms from Dedekind and made extensive use of
Grassmann's work in his development of the axioms." (Hao Wang. The
Axiomatization of Arithmetic. J. Symb. Logic; 1957:22(2); p. 145.)
type IntegerNumber alias INT specializes QTY {
INT successor;
INT plus(QTY x);
INT times(INT x);
INT predecessor;
INT negated;
BL nonNegative;
BL isNegative;
INT dividedBy(INT x);
INT remainder(INT x);
BL isOne;
literal ST;
};
REAL (RealNumber)
Fractional numbers. Typically used whenever quantities are measured,
estimated, or computed from other real numbers. The typical
representation is decimal, where the number of significant decimal
digits is known as the precision.
The term "Real number" in this specification is used to mean that
fractional values are covered without necessarily implying the full
set of the mathematical real numbers that would include irrational
numbers such as ?, Euler's number, etc.
The term "Real" for a fractional number data type originates and is
well established in the Algol, Pascal tradition of programming
languages.
This specification offers two choices for a number data type. The
choice is made as follows: Any number attribute is a real if it is not
known for sure that it is an integer. A number is an integer if it is
always counted, typically representing an ordinal
number. If there are conceivable use cases where such a number would
be estimated or averaged, it is not always an integer and thus should
use the Real data type.
The algebraic operations are specified here as characterizing
operations in the sense of ISO 11404, and because these operations are
needed in other parts of this specification.
Unlike the integer numbers, the real numbers semantics are not
inductively constructed but only intuitively described by their axioms
of their algebraic properties. The completeness axioms are
intentionally left out so as to make no statement about irrational
numbers.
type RealNumber alias REAL specializes QTY {
REAL negated;
BL isOne;
REAL times(REAL x);
REAL inverted;
REAL power(REAL x);
literal ST;
INT precision;
demotion INT;
promotion REAL (INT x);
};
Fractional numbers. Typically used whenever quantities are measured,
estimated, or computed from other real numbers. The typical
representation is decimal, where the number of significant decimal
digits is known as the precision.
The term "Real number" in this specification is used to mean that
fractional values are covered without necessarily implying the full
set of the mathematical real numbers that would include irrational
numbers such as ?, Euler's number, etc.
The term "Real" for a fractional number data type originates and is
well established in the Algol, Pascal tradition of programming
languages.
This specification offers two choices for a number data type. The
choice is made as follows: Any number attribute is a real if it is not
known for sure that it is an integer. A number is an integer if it is
always counted, typically representing an ordinal
number. If there are conceivable use cases where such a number would
be estimated or averaged, it is not always an integer and thus should
use the Real data type.
The algebraic operations are specified here as characterizing
operations in the sense of ISO 11404, and because these operations are
needed in other parts of this specification.
Unlike the integer numbers, the real numbers semantics are not
inductively constructed but only intuitively described by their axioms
of their algebraic properties. The completeness axioms are
intentionally left out so as to make no statement about irrational
numbers.
type RealNumber alias REAL specializes QTY {
REAL negated;
BL isOne;
REAL times(REAL x);
REAL inverted;
REAL power(REAL x);
literal ST;
INT precision;
demotion INT;
promotion REAL (INT x);
};
Fractional numbers. Typically used whenever quantities are measured,
estimated, or computed from other real numbers. The typical
representation is decimal, where the number of significant decimal
digits is known as the precision.
The term "Real number" in this specification is used to mean that
fractional values are covered without necessarily implying the full
set of the mathematical real numbers that would include irrational
numbers such as ?, Euler's number, etc.
The term "Real" for a fractional number data type originates and is
well established in the Algol, Pascal tradition of programming
languages.
This specification offers two choices for a number data type. The
choice is made as follows: Any number attribute is a real if it is not
known for sure that it is an integer. A number is an integer if it is
always counted, typically representing an ordinal
number. If there are conceivable use cases where such a number would
be estimated or averaged, it is not always an integer and thus should
use the Real data type.
The algebraic operations are specified here as characterizing
operations in the sense of ISO 11404, and because these operations are
needed in other parts of this specification.
Unlike the integer numbers, the real numbers semantics are not
inductively constructed but only intuitively described by their axioms
of their algebraic properties. The completeness axioms are
intentionally left out so as to make no statement about irrational
numbers.
type RealNumber alias REAL specializes QTY {
REAL negated;
BL isOne;
REAL times(REAL x);
REAL inverted;
REAL power(REAL x);
literal ST;
INT precision;
demotion INT;
promotion REAL (INT x);
};
Fractional numbers. Typically used whenever quantities are measured,
estimated, or computed from other real numbers. The typical
representation is decimal, where the number of significant decimal
digits is known as the precision.
The term "Real number" in this specification is used to mean that
fractional values are covered without necessarily implying the full
set of the mathematical real numbers that would include irrational
numbers such as ?, Euler's number, etc.
The term "Real" for a fractional number data type originates and is
well established in the Algol, Pascal tradition of programming
languages.
This specification offers two choices for a number data type. The
choice is made as follows: Any number attribute is a real if it is not
known for sure that it is an integer. A number is an integer if it is
always counted, typically representing an ordinal
number. If there are conceivable use cases where such a number would
be estimated or averaged, it is not always an integer and thus should
use the Real data type.
The algebraic operations are specified here as characterizing
operations in the sense of ISO 11404, and because these operations are
needed in other parts of this specification.
Unlike the integer numbers, the real numbers semantics are not
inductively constructed but only intuitively described by their axioms
of their algebraic properties. The completeness axioms are
intentionally left out so as to make no statement about irrational
numbers.
type RealNumber alias REAL specializes QTY {
REAL negated;
BL isOne;
REAL times(REAL x);
REAL inverted;
REAL power(REAL x);
literal ST;
INT precision;
demotion INT;
promotion REAL (INT x);
};
Fractional numbers. Typically used whenever quantities are measured,
estimated, or computed from other real numbers. The typical
representation is decimal, where the number of significant decimal
digits is known as the precision.
The term "Real number" in this specification is used to mean that
fractional values are covered without necessarily implying the full
set of the mathematical real numbers that would include irrational
numbers such as ?, Euler's number, etc.
The term "Real" for a fractional number data type originates and is
well established in the Algol, Pascal tradition of programming
languages.
This specification offers two choices for a number data type. The
choice is made as follows: Any number attribute is a real if it is not
known for sure that it is an integer. A number is an integer if it is
always counted, typically representing an ordinal
number. If there are conceivable use cases where such a number would
be estimated or averaged, it is not always an integer and thus should
use the Real data type.
The algebraic operations are specified here as characterizing
operations in the sense of ISO 11404, and because these operations are
needed in other parts of this specification.
Unlike the integer numbers, the real numbers semantics are not
inductively constructed but only intuitively described by their axioms
of their algebraic properties. The completeness axioms are
intentionally left out so as to make no statement about irrational
numbers.
type RealNumber alias REAL specializes QTY {
REAL negated;
BL isOne;
REAL times(REAL x);
REAL inverted;
REAL power(REAL x);
literal ST;
INT precision;
demotion INT;
promotion REAL (INT x);
};
Fractional numbers. Typically used whenever quantities are measured,
estimated, or computed from other real numbers. The typical
representation is decimal, where the number of significant decimal
digits is known as the precision.
The term "Real number" in this specification is used to mean that
fractional values are covered without necessarily implying the full
set of the mathematical real numbers that would include irrational
numbers such as ?, Euler's number, etc.
The term "Real" for a fractional number data type originates and is
well established in the Algol, Pascal tradition of programming
languages.
This specification offers two choices for a number data type. The
choice is made as follows: Any number attribute is a real if it is not
known for sure that it is an integer. A number is an integer if it is
always counted, typically representing an ordinal
number. If there are conceivable use cases where such a number would
be estimated or averaged, it is not always an integer and thus should
use the Real data type.
The algebraic operations are specified here as characterizing
operations in the sense of ISO 11404, and because these operations are
needed in other parts of this specification.
Unlike the integer numbers, the real numbers semantics are not
inductively constructed but only intuitively described by their axioms
of their algebraic properties. The completeness axioms are
intentionally left out so as to make no statement about irrational
numbers.
type RealNumber alias REAL specializes QTY {
REAL negated;
BL isOne;
REAL times(REAL x);
REAL inverted;
REAL power(REAL x);
literal ST;
INT precision;
demotion INT;
promotion REAL (INT x);
};
Fractional numbers. Typically used whenever quantities are measured,
estimated, or computed from other real numbers. The typical
representation is decimal, where the number of significant decimal
digits is known as the precision.
The term "Real number" in this specification is used to mean that
fractional values are covered without necessarily implying the full
set of the mathematical real numbers that would include irrational
numbers such as ?, Euler's number, etc.
The term "Real" for a fractional number data type originates and is
well established in the Algol, Pascal tradition of programming
languages.
This specification offers two choices for a number data type. The
choice is made as follows: Any number attribute is a real if it is not
known for sure that it is an integer. A number is an integer if it is
always counted, typically representing an ordinal
number. If there are conceivable use cases where such a number would
be estimated or averaged, it is not always an integer and thus should
use the Real data type.
The algebraic operations are specified here as characterizing
operations in the sense of ISO 11404, and because these operations are
needed in other parts of this specification.
Unlike the integer numbers, the real numbers semantics are not
inductively constructed but only intuitively described by their axioms
of their algebraic properties. The completeness axioms are
intentionally left out so as to make no statement about irrational
numbers.
type RealNumber alias REAL specializes QTY {
REAL negated;
BL isOne;
REAL times(REAL x);
REAL inverted;
REAL power(REAL x);
literal ST;
INT precision;
demotion INT;
promotion REAL (INT x);
};
Fractional numbers. Typically used whenever quantities are measured,
estimated, or computed from other real numbers. The typical
representation is decimal, where the number of significant decimal
digits is known as the precision.
The term "Real number" in this specification is used to mean that
fractional values are covered without necessarily implying the full
set of the mathematical real numbers that would include irrational
numbers such as ?, Euler's number, etc.
The term "Real" for a fractional number data type originates and is
well established in the Algol, Pascal tradition of programming
languages.
This specification offers two choices for a number data type. The
choice is made as follows: Any number attribute is a real if it is not
known for sure that it is an integer. A number is an integer if it is
always counted, typically representing an ordinal
number. If there are conceivable use cases where such a number would
be estimated or averaged, it is not always an integer and thus should
use the Real data type.
The algebraic operations are specified here as characterizing
operations in the sense of ISO 11404, and because these operations are
needed in other parts of this specification.
Unlike the integer numbers, the real numbers semantics are not
inductively constructed but only intuitively described by their axioms
of their algebraic properties. The completeness axioms are
intentionally left out so as to make no statement about irrational
numbers.
type RealNumber alias REAL specializes QTY {
REAL negated;
BL isOne;
REAL times(REAL x);
REAL inverted;
REAL power(REAL x);
literal ST;
INT precision;
demotion INT;
promotion REAL (INT x);
};
Fractional numbers. Typically used whenever quantities are measured,
estimated, or computed from other real numbers. The typical
representation is decimal, where the number of significant decimal
digits is known as the precision.
The term "Real number" in this specification is used to mean that
fractional values are covered without necessarily implying the full
set of the mathematical real numbers that would include irrational
numbers such as ?, Euler's number, etc.
The term "Real" for a fractional number data type originates and is
well established in the Algol, Pascal tradition of programming
languages.
This specification offers two choices for a number data type. The
choice is made as follows: Any number attribute is a real if it is not
known for sure that it is an integer. A number is an integer if it is
always counted, typically representing an ordinal
number. If there are conceivable use cases where such a number would
be estimated or averaged, it is not always an integer and thus should
use the Real data type.
The algebraic operations are specified here as characterizing
operations in the sense of ISO 11404, and because these operations are
needed in other parts of this specification.
Unlike the integer numbers, the real numbers semantics are not
inductively constructed but only intuitively described by their axioms
of their algebraic properties. The completeness axioms are
intentionally left out so as to make no statement about irrational
numbers.
type RealNumber alias REAL specializes QTY {
REAL negated;
BL isOne;
REAL times(REAL x);
REAL inverted;
REAL power(REAL x);
literal ST;
INT precision;
demotion INT;
promotion REAL (INT x);
};
Fractional numbers. Typically used whenever quantities are measured,
estimated, or computed from other real numbers. The typical
representation is decimal, where the number of significant decimal
digits is known as the precision.
The term "Real number" in this specification is used to mean that
fractional values are covered without necessarily implying the full
set of the mathematical real numbers that would include irrational
numbers such as ?, Euler's number, etc.
The term "Real" for a fractional number data type originates and is
well established in the Algol, Pascal tradition of programming
languages.
This specification offers two choices for a number data type. The
choice is made as follows: Any number attribute is a real if it is not
known for sure that it is an integer. A number is an integer if it is
always counted, typically representing an ordinal
number. If there are conceivable use cases where such a number would
be estimated or averaged, it is not always an integer and thus should
use the Real data type.
The algebraic operations are specified here as characterizing
operations in the sense of ISO 11404, and because these operations are
needed in other parts of this specification.
Unlike the integer numbers, the real numbers semantics are not
inductively constructed but only intuitively described by their axioms
of their algebraic properties. The completeness axioms are
intentionally left out so as to make no statement about irrational
numbers.
type RealNumber alias REAL specializes QTY {
REAL negated;
BL isOne;
REAL times(REAL x);
REAL inverted;
REAL power(REAL x);
literal ST;
INT precision;
demotion INT;
promotion REAL (INT x);
};
Fractional numbers. Typically used whenever quantities are measured,
estimated, or computed from other real numbers. The typical
representation is decimal, where the number of significant decimal
digits is known as the precision.
The term "Real number" in this specification is used to mean that
fractional values are covered without necessarily implying the full
set of the mathematical real numbers that would include irrational
numbers such as ?, Euler's number, etc.
The term "Real" for a fractional number data type originates and is
well established in the Algol, Pascal tradition of programming
languages.
This specification offers two choices for a number data type. The
choice is made as follows: Any number attribute is a real if it is not
known for sure that it is an integer. A number is an integer if it is
always counted, typically representing an ordinal
number. If there are conceivable use cases where such a number would
be estimated or averaged, it is not always an integer and thus should
use the Real data type.
The algebraic operations are specified here as characterizing
operations in the sense of ISO 11404, and because these operations are
needed in other parts of this specification.
Unlike the integer numbers, the real numbers semantics are not
inductively constructed but only intuitively described by their axioms
of their algebraic properties. The completeness axioms are
intentionally left out so as to make no statement about irrational
numbers.
type RealNumber alias REAL specializes QTY {
REAL negated;
BL isOne;
REAL times(REAL x);
REAL inverted;
REAL power(REAL x);
literal ST;
INT precision;
demotion INT;
promotion REAL (INT x);
};
Fractional numbers. Typically used whenever quantities are measured,
estimated, or computed from other real numbers. The typical
representation is decimal, where the number of significant decimal
digits is known as the precision.
The term "Real number" in this specification is used to mean that
fractional values are covered without necessarily implying the full
set of the mathematical real numbers that would include irrational
numbers such as ?, Euler's number, etc.
The term "Real" for a fractional number data type originates and is
well established in the Algol, Pascal tradition of programming
languages.
This specification offers two choices for a number data type. The
choice is made as follows: Any number attribute is a real if it is not
known for sure that it is an integer. A number is an integer if it is
always counted, typically representing an ordinal
number. If there are conceivable use cases where such a number would
be estimated or averaged, it is not always an integer and thus should
use the Real data type.
The algebraic operations are specified here as characterizing
operations in the sense of ISO 11404, and because these operations are
needed in other parts of this specification.
Unlike the integer numbers, the real numbers semantics are not
inductively constructed but only intuitively described by their axioms
of their algebraic properties. The completeness axioms are
intentionally left out so as to make no statement about irrational
numbers.
type RealNumber alias REAL specializes QTY {
REAL negated;
BL isOne;
REAL times(REAL x);
REAL inverted;
REAL power(REAL x);
literal ST;
INT precision;
demotion INT;
promotion REAL (INT x);
};
Fractional numbers. Typically used whenever quantities are measured,
estimated, or computed from other real numbers. The typical
representation is decimal, where the number of significant decimal
digits is known as the precision.
The term "Real number" in this specification is used to mean that
fractional values are covered without necessarily implying the full
set of the mathematical real numbers that would include irrational
numbers such as ?, Euler's number, etc.
The term "Real" for a fractional number data type originates and is
well established in the Algol, Pascal tradition of programming
languages.
This specification offers two choices for a number data type. The
choice is made as follows: Any number attribute is a real if it is not
known for sure that it is an integer. A number is an integer if it is
always counted, typically representing an ordinal
number. If there are conceivable use cases where such a number would
be estimated or averaged, it is not always an integer and thus should
use the Real data type.
The algebraic operations are specified here as characterizing
operations in the sense of ISO 11404, and because these operations are
needed in other parts of this specification.
Unlike the integer numbers, the real numbers semantics are not
inductively constructed but only intuitively described by their axioms
of their algebraic properties. The completeness axioms are
intentionally left out so as to make no statement about irrational
numbers.
type RealNumber alias REAL specializes QTY {
REAL negated;
BL isOne;
REAL times(REAL x);
REAL inverted;
REAL power(REAL x);
literal ST;
INT precision;
demotion INT;
promotion REAL (INT x);
};
RTO (Ratio)
A quantity constructed as the quotient of a numerator quantity divided
by a denominator quantity. Common factors in the numerator and
denominator are not automatically cancelled out. The data
type supports titers (e.g., "1:128") and other quantities produced by
laboratories that truly represent ratios. Ratios are not simply
"structured numerics", particularly blood pressure measurements
(e.g. "120/60") are not ratios. In many cases the
should be used instead of the .
Ratios are different from rational numbers, i.e., in ratios common
factors in the numerator and denominator never cancel out. A ratio of
two real or integer numbers is not automatically reduced to a real
number.
The default value for both numerator and denominator is the integer
number 1 (one.) The denominator may not be zero.
template<QTY N, QTY D>
type Ratio<N, D> alias RTO<N, D> specializes QTY {
N numerator;
D denominator;
literal ST;
};
A quantity constructed as the quotient of a numerator quantity divided
by a denominator quantity. Common factors in the numerator and
denominator are not automatically cancelled out. The data
type supports titers (e.g., "1:128") and other quantities produced by
laboratories that truly represent ratios. Ratios are not simply
"structured numerics", particularly blood pressure measurements
(e.g. "120/60") are not ratios. In many cases the
should be used instead of the .
Ratios are different from rational numbers, i.e., in ratios common
factors in the numerator and denominator never cancel out. A ratio of
two real or integer numbers is not automatically reduced to a real
number.
The default value for both numerator and denominator is the integer
number 1 (one.) The denominator may not be zero.
template<QTY N, QTY D>
type Ratio<N, D> alias RTO<N, D> specializes QTY {
N numerator;
D denominator;
literal ST;
};
A quantity constructed as the quotient of a numerator quantity divided
by a denominator quantity. Common factors in the numerator and
denominator are not automatically cancelled out. The data
type supports titers (e.g., "1:128") and other quantities produced by
laboratories that truly represent ratios. Ratios are not simply
"structured numerics", particularly blood pressure measurements
(e.g. "120/60") are not ratios. In many cases the
should be used instead of the .
Ratios are different from rational numbers, i.e., in ratios common
factors in the numerator and denominator never cancel out. A ratio of
two real or integer numbers is not automatically reduced to a real
number.
The default value for both numerator and denominator is the integer
number 1 (one.) The denominator may not be zero.
template<QTY N, QTY D>
type Ratio<N, D> alias RTO<N, D> specializes QTY {
N numerator;
D denominator;
literal ST;
};
A quantity constructed as the quotient of a numerator quantity divided
by a denominator quantity. Common factors in the numerator and
denominator are not automatically cancelled out. The data
type supports titers (e.g., "1:128") and other quantities produced by
laboratories that truly represent ratios. Ratios are not simply
"structured numerics", particularly blood pressure measurements
(e.g. "120/60") are not ratios. In many cases the
should be used instead of the .
Ratios are different from rational numbers, i.e., in ratios common
factors in the numerator and denominator never cancel out. A ratio of
two real or integer numbers is not automatically reduced to a real
number.
The default value for both numerator and denominator is the integer
number 1 (one.) The denominator may not be zero.
template<QTY N, QTY D>
type Ratio<N, D> alias RTO<N, D> specializes QTY {
N numerator;
D denominator;
literal ST;
};
PQ (PhysicalQuantity)
A dimensioned quantity expressing the result of measuring.
type PhysicalQuantity alias PQ specializes QTY {
REAL value;
CS unit;
SET<PQR> translation;
PQ canonical;
BL isOne;
PQ times(PQ x);
PQ times(REAL x);
PQ inverted;
PQ power(INT x);
PQ plus(QTY x);
literal ST;
demotion REAL;
};
A dimensioned quantity expressing the result of measuring.
type PhysicalQuantity alias PQ specializes QTY {
REAL value;
CS unit;
SET<PQR> translation;
PQ canonical;
BL isOne;
PQ times(PQ x);
PQ times(REAL x);
PQ inverted;
PQ power(INT x);
PQ plus(QTY x);
literal ST;
demotion REAL;
};
A dimensioned quantity expressing the result of measuring.
type PhysicalQuantity alias PQ specializes QTY {
REAL value;
CS unit;
SET<PQR> translation;
PQ canonical;
BL isOne;
PQ times(PQ x);
PQ times(REAL x);
PQ inverted;
PQ power(INT x);
PQ plus(QTY x);
literal ST;
demotion REAL;
};
A dimensioned quantity expressing the result of measuring.
type PhysicalQuantity alias PQ specializes QTY {
REAL value;
CS unit;
SET<PQR> translation;
PQ canonical;
BL isOne;
PQ times(PQ x);
PQ times(REAL x);
PQ inverted;
PQ power(INT x);
PQ plus(QTY x);
literal ST;
demotion REAL;
};
A dimensioned quantity expressing the result of measuring.
type PhysicalQuantity alias PQ specializes QTY {
REAL value;
CS unit;
SET<PQR> translation;
PQ canonical;
BL isOne;
PQ times(PQ x);
PQ times(REAL x);
PQ inverted;
PQ power(INT x);
PQ plus(QTY x);
literal ST;
demotion REAL;
};
A dimensioned quantity expressing the result of measuring.
type PhysicalQuantity alias PQ specializes QTY {
REAL value;
CS unit;
SET<PQR> translation;
PQ canonical;
BL isOne;
PQ times(PQ x);
PQ times(REAL x);
PQ inverted;
PQ power(INT x);
PQ plus(QTY x);
literal ST;
demotion REAL;
};
A dimensioned quantity expressing the result of measuring.
type PhysicalQuantity alias PQ specializes QTY {
REAL value;
CS unit;
SET<PQR> translation;
PQ canonical;
BL isOne;
PQ times(PQ x);
PQ times(REAL x);
PQ inverted;
PQ power(INT x);
PQ plus(QTY x);
literal ST;
demotion REAL;
};
A dimensioned quantity expressing the result of measuring.
type PhysicalQuantity alias PQ specializes QTY {
REAL value;
CS unit;
SET<PQR> translation;
PQ canonical;
BL isOne;
PQ times(PQ x);
PQ times(REAL x);
PQ inverted;
PQ power(INT x);
PQ plus(QTY x);
literal ST;
demotion REAL;
};
A dimensioned quantity expressing the result of measuring.
type PhysicalQuantity alias PQ specializes QTY {
REAL value;
CS unit;
SET<PQR> translation;
PQ canonical;
BL isOne;
PQ times(PQ x);
PQ times(REAL x);
PQ inverted;
PQ power(INT x);
PQ plus(QTY x);
literal ST;
demotion REAL;
};
A dimensioned quantity expressing the result of measuring.
type PhysicalQuantity alias PQ specializes QTY {
REAL value;
CS unit;
SET<PQR> translation;
PQ canonical;
BL isOne;
PQ times(PQ x);
PQ times(REAL x);
PQ inverted;
PQ power(INT x);
PQ plus(QTY x);
literal ST;
demotion REAL;
};
A dimensioned quantity expressing the result of measuring.
type PhysicalQuantity alias PQ specializes QTY {
REAL value;
CS unit;
SET<PQR> translation;
PQ canonical;
BL isOne;
PQ times(PQ x);
PQ times(REAL x);
PQ inverted;
PQ power(INT x);
PQ plus(QTY x);
literal ST;
demotion REAL;
};
A dimensioned quantity expressing the result of measuring.
type PhysicalQuantity alias PQ specializes QTY {
REAL value;
CS unit;
SET<PQR> translation;
PQ canonical;
BL isOne;
PQ times(PQ x);
PQ times(REAL x);
PQ inverted;
PQ power(INT x);
PQ plus(QTY x);
literal ST;
demotion REAL;
};
A dimensioned quantity expressing the result of measuring.
type PhysicalQuantity alias PQ specializes QTY {
REAL value;
CS unit;
SET<PQR> translation;
PQ canonical;
BL isOne;
PQ times(PQ x);
PQ times(REAL x);
PQ inverted;
PQ power(INT x);
PQ plus(QTY x);
literal ST;
demotion REAL;
};
A dimensioned quantity expressing the result of measuring.
type PhysicalQuantity alias PQ specializes QTY {
REAL value;
CS unit;
SET<PQR> translation;
PQ canonical;
BL isOne;
PQ times(PQ x);
PQ times(REAL x);
PQ inverted;
PQ power(INT x);
PQ plus(QTY x);
literal ST;
demotion REAL;
};
A dimensioned quantity expressing the result of measuring.
type PhysicalQuantity alias PQ specializes QTY {
REAL value;
CS unit;
SET<PQR> translation;
PQ canonical;
BL isOne;
PQ times(PQ x);
PQ times(REAL x);
PQ inverted;
PQ power(INT x);
PQ plus(QTY x);
literal ST;
demotion REAL;
};
A dimensioned quantity expressing the result of measuring.
type PhysicalQuantity alias PQ specializes QTY {
REAL value;
CS unit;
SET<PQR> translation;
PQ canonical;
BL isOne;
PQ times(PQ x);
PQ times(REAL x);
PQ inverted;
PQ power(INT x);
PQ plus(QTY x);
literal ST;
demotion REAL;
};
PQR (PhysicalQuantityRepresentation)
An extension of the coded value data type representating a physical
quantity using a unit from any code system. Used to show alternative
representation for a physical quantity.
protected type PhysicalQuantityRepresentation alias PQR specializes CV {
REAL value;
};
An extension of the coded value data type representating a physical
quantity using a unit from any code system. Used to show alternative
representation for a physical quantity.
protected type PhysicalQuantityRepresentation alias PQR specializes CV {
REAL value;
};
An extension of the coded value data type representating a physical
quantity using a unit from any code system. Used to show alternative
representation for a physical quantity.
protected type PhysicalQuantityRepresentation alias PQR specializes CV {
REAL value;
};
An extension of the coded value data type representating a physical
quantity using a unit from any code system. Used to show alternative
representation for a physical quantity.
protected type PhysicalQuantityRepresentation alias PQR specializes CV {
REAL value;
};
An extension of the coded value data type representating a physical
quantity using a unit from any code system. Used to show alternative
representation for a physical quantity.
protected type PhysicalQuantityRepresentation alias PQR specializes CV {
REAL value;
};
An extension of the coded value data type representating a physical
quantity using a unit from any code system. Used to show alternative
representation for a physical quantity.
protected type PhysicalQuantityRepresentation alias PQR specializes CV {
REAL value;
};
An extension of the coded value data type representating a physical
quantity using a unit from any code system. Used to show alternative
representation for a physical quantity.
protected type PhysicalQuantityRepresentation alias PQR specializes CV {
REAL value;
};
An extension of the coded value data type representating a physical
quantity using a unit from any code system. Used to show alternative
representation for a physical quantity.
protected type PhysicalQuantityRepresentation alias PQR specializes CV {
REAL value;
};
MO (MonetaryAmount)
A monetary amount is a quantity expressing the amount of money in some
currency. Currencies are the units in which monetary amounts are
denominated in different economic regions. While the monetary amount
is a single kind of quantity (money) the exchange rates between the
different units are variable. This is the principle difference
between physical quantity and monetary amounts, and the reason why
currency units are not physical units.
type MonetaryAmount alias MO specializes QTY {
REAL value;
CS currency;
MO plus(MO x);
MO times(REAL x);
literal ST;
};
A monetary amount is a quantity expressing the amount of money in some
currency. Currencies are the units in which monetary amounts are
denominated in different economic regions. While the monetary amount
is a single kind of quantity (money) the exchange rates between the
different units are variable. This is the principle difference
between physical quantity and monetary amounts, and the reason why
currency units are not physical units.
type MonetaryAmount alias MO specializes QTY {
REAL value;
CS currency;
MO plus(MO x);
MO times(REAL x);
literal ST;
};
A monetary amount is a quantity expressing the amount of money in some
currency. Currencies are the units in which monetary amounts are
denominated in different economic regions. While the monetary amount
is a single kind of quantity (money) the exchange rates between the
different units are variable. This is the principle difference
between physical quantity and monetary amounts, and the reason why
currency units are not physical units.
type MonetaryAmount alias MO specializes QTY {
REAL value;
CS currency;
MO plus(MO x);
MO times(REAL x);
literal ST;
};
A monetary amount is a quantity expressing the amount of money in some
currency. Currencies are the units in which monetary amounts are
denominated in different economic regions. While the monetary amount
is a single kind of quantity (money) the exchange rates between the
different units are variable. This is the principle difference
between physical quantity and monetary amounts, and the reason why
currency units are not physical units.
type MonetaryAmount alias MO specializes QTY {
REAL value;
CS currency;
MO plus(MO x);
MO times(REAL x);
literal ST;
};
A monetary amount is a quantity expressing the amount of money in some
currency. Currencies are the units in which monetary amounts are
denominated in different economic regions. While the monetary amount
is a single kind of quantity (money) the exchange rates between the
different units are variable. This is the principle difference
between physical quantity and monetary amounts, and the reason why
currency units are not physical units.
type MonetaryAmount alias MO specializes QTY {
REAL value;
CS currency;
MO plus(MO x);
MO times(REAL x);
literal ST;
};
A monetary amount is a quantity expressing the amount of money in some
currency. Currencies are the units in which monetary amounts are
denominated in different economic regions. While the monetary amount
is a single kind of quantity (money) the exchange rates between the
different units are variable. This is the principle difference
between physical quantity and monetary amounts, and the reason why
currency units are not physical units.
type MonetaryAmount alias MO specializes QTY {
REAL value;
CS currency;
MO plus(MO x);
MO times(REAL x);
literal ST;
};
A monetary amount is a quantity expressing the amount of money in some
currency. Currencies are the units in which monetary amounts are
denominated in different economic regions. While the monetary amount
is a single kind of quantity (money) the exchange rates between the
different units are variable. This is the principle difference
between physical quantity and monetary amounts, and the reason why
currency units are not physical units.
type MonetaryAmount alias MO specializes QTY {
REAL value;
CS currency;
MO plus(MO x);
MO times(REAL x);
literal ST;
};
A monetary amount is a quantity expressing the amount of money in some
currency. Currencies are the units in which monetary amounts are
denominated in different economic regions. While the monetary amount
is a single kind of quantity (money) the exchange rates between the
different units are variable. This is the principle difference
between physical quantity and monetary amounts, and the reason why
currency units are not physical units.
type MonetaryAmount alias MO specializes QTY {
REAL value;
CS currency;
MO plus(MO x);
MO times(REAL x);
literal ST;
};
A monetary amount is a quantity expressing the amount of money in some
currency. Currencies are the units in which monetary amounts are
denominated in different economic regions. While the monetary amount
is a single kind of quantity (money) the exchange rates between the
different units are variable. This is the principle difference
between physical quantity and monetary amounts, and the reason why
currency units are not physical units.
type MonetaryAmount alias MO specializes QTY {
REAL value;
CS currency;
MO plus(MO x);
MO times(REAL x);
literal ST;
};
CAL (Calendar)
A calendar is a concept of measuring time in various cycles. Such
cycles are years, months, days, hours, minutes, seconds, and
weeks. Some of these cycles are synchronized and some are not (e.g.,
weeks and months are not synchronized.)
After "rolling the time axis" into these cycles (See the figure)
a calendar expresses a point in time as a sequence
of integer counts of cycles, e.g., for year, month, day, hour,
etc. The calendar is rooted in some conventional start point, called
the "epoch."
A calendar "rolls" the time axis into a complex convolute according to
the calendar periods year (blue), month (yellow), day (green), hour
(red), etc. The cycles need not be aligned, for example, the week (not
shown) is not aligned to the month.
Imagine a special clock that measures those cycles, where the pointers
are not all stacked on a common axis but each pointer is attached to
the end of the pointer measuring the next larger cycle.
Calendar is defined as a set of calendar cycles, and has a name and a
code. The head of the Calendar is the largest CalendarCycle appearing
right most in the calendar expression. The epoch is the beginning of
that calendar, i.e., the point in time where all calendar cycles are
zero.
The calendar definition can be shown as in
for the modern Gregorian calendar. The calendar definition table lists a
calendar cycle in each row. The calendar units are dependent on each other and
defined in the value column. The sequence column shows the relationship through
the next property. The other columns are as in the formal calendar cycle
definition.
At present, the CalendarCycle properties sum and value are not
formally defined. The computation of calendar digits involves some
complex computation which to specify here would be hard to understand
and evaluate for correctness. Unfortunately, no standard exists that
would formally define the relationship between calendar expressions
and elapsed time since an epoch. ASN.1, the XML Schema Data Type
specification and SQL92 all refer to ISO 8601, however, ISO 8601 does
only specify the syntax of Gregorian calendar expressions, but not
their semantics. In this standard, we define the syntax and semantics
formally, however, we presume the semantics of the sum-, and
value-properties to be defined elsewhere.
private type Calendar alias CAL specializes SET<CLCY> {
CS name;
CLCY head;
TS epoch;
};
A calendar is a concept of measuring time in various cycles. Such
cycles are years, months, days, hours, minutes, seconds, and
weeks. Some of these cycles are synchronized and some are not (e.g.,
weeks and months are not synchronized.)
After "rolling the time axis" into these cycles (See the figure)
a calendar expresses a point in time as a sequence
of integer counts of cycles, e.g., for year, month, day, hour,
etc. The calendar is rooted in some conventional start point, called
the "epoch."
A calendar "rolls" the time axis into a complex convolute according to
the calendar periods year (blue), month (yellow), day (green), hour
(red), etc. The cycles need not be aligned, for example, the week (not
shown) is not aligned to the month.
Imagine a special clock that measures those cycles, where the pointers
are not all stacked on a common axis but each pointer is attached to
the end of the pointer measuring the next larger cycle.
Calendar is defined as a set of calendar cycles, and has a name and a
code. The head of the Calendar is the largest CalendarCycle appearing
right most in the calendar expression. The epoch is the beginning of
that calendar, i.e., the point in time where all calendar cycles are
zero.
The calendar definition can be shown as in
for the modern Gregorian calendar. The calendar definition table lists a
calendar cycle in each row. The calendar units are dependent on each other and
defined in the value column. The sequence column shows the relationship through
the next property. The other columns are as in the formal calendar cycle
definition.
At present, the CalendarCycle properties sum and value are not
formally defined. The computation of calendar digits involves some
complex computation which to specify here would be hard to understand
and evaluate for correctness. Unfortunately, no standard exists that
would formally define the relationship between calendar expressions
and elapsed time since an epoch. ASN.1, the XML Schema Data Type
specification and SQL92 all refer to ISO 8601, however, ISO 8601 does
only specify the syntax of Gregorian calendar expressions, but not
their semantics. In this standard, we define the syntax and semantics
formally, however, we presume the semantics of the sum-, and
value-properties to be defined elsewhere.
private type Calendar alias CAL specializes SET<CLCY> {
CS name;
CLCY head;
TS epoch;
};
A calendar is a concept of measuring time in various cycles. Such
cycles are years, months, days, hours, minutes, seconds, and
weeks. Some of these cycles are synchronized and some are not (e.g.,
weeks and months are not synchronized.)
After "rolling the time axis" into these cycles (See the figure)
a calendar expresses a point in time as a sequence
of integer counts of cycles, e.g., for year, month, day, hour,
etc. The calendar is rooted in some conventional start point, called
the "epoch."
A calendar "rolls" the time axis into a complex convolute according to
the calendar periods year (blue), month (yellow), day (green), hour
(red), etc. The cycles need not be aligned, for example, the week (not
shown) is not aligned to the month.
Imagine a special clock that measures those cycles, where the pointers
are not all stacked on a common axis but each pointer is attached to
the end of the pointer measuring the next larger cycle.
Calendar is defined as a set of calendar cycles, and has a name and a
code. The head of the Calendar is the largest CalendarCycle appearing
right most in the calendar expression. The epoch is the beginning of
that calendar, i.e., the point in time where all calendar cycles are
zero.
The calendar definition can be shown as in
for the modern Gregorian calendar. The calendar definition table lists a
calendar cycle in each row. The calendar units are dependent on each other and
defined in the value column. The sequence column shows the relationship through
the next property. The other columns are as in the formal calendar cycle
definition.
At present, the CalendarCycle properties sum and value are not
formally defined. The computation of calendar digits involves some
complex computation which to specify here would be hard to understand
and evaluate for correctness. Unfortunately, no standard exists that
would formally define the relationship between calendar expressions
and elapsed time since an epoch. ASN.1, the XML Schema Data Type
specification and SQL92 all refer to ISO 8601, however, ISO 8601 does
only specify the syntax of Gregorian calendar expressions, but not
their semantics. In this standard, we define the syntax and semantics
formally, however, we presume the semantics of the sum-, and
value-properties to be defined elsewhere.
private type Calendar alias CAL specializes SET<CLCY> {
CS name;
CLCY head;
TS epoch;
};
A calendar is a concept of measuring time in various cycles. Such
cycles are years, months, days, hours, minutes, seconds, and
weeks. Some of these cycles are synchronized and some are not (e.g.,
weeks and months are not synchronized.)
After "rolling the time axis" into these cycles (See the figure)
a calendar expresses a point in time as a sequence
of integer counts of cycles, e.g., for year, month, day, hour,
etc. The calendar is rooted in some conventional start point, called
the "epoch."
A calendar "rolls" the time axis into a complex convolute according to
the calendar periods year (blue), month (yellow), day (green), hour
(red), etc. The cycles need not be aligned, for example, the week (not
shown) is not aligned to the month.
Imagine a special clock that measures those cycles, where the pointers
are not all stacked on a common axis but each pointer is attached to
the end of the pointer measuring the next larger cycle.
Calendar is defined as a set of calendar cycles, and has a name and a
code. The head of the Calendar is the largest CalendarCycle appearing
right most in the calendar expression. The epoch is the beginning of
that calendar, i.e., the point in time where all calendar cycles are
zero.
The calendar definition can be shown as in
for the modern Gregorian calendar. The calendar definition table lists a
calendar cycle in each row. The calendar units are dependent on each other and
defined in the value column. The sequence column shows the relationship through
the next property. The other columns are as in the formal calendar cycle
definition.
At present, the CalendarCycle properties sum and value are not
formally defined. The computation of calendar digits involves some
complex computation which to specify here would be hard to understand
and evaluate for correctness. Unfortunately, no standard exists that
would formally define the relationship between calendar expressions
and elapsed time since an epoch. ASN.1, the XML Schema Data Type
specification and SQL92 all refer to ISO 8601, however, ISO 8601 does
only specify the syntax of Gregorian calendar expressions, but not
their semantics. In this standard, we define the syntax and semantics
formally, however, we presume the semantics of the sum-, and
value-properties to be defined elsewhere.
private type Calendar alias CAL specializes SET<CLCY> {
CS name;
CLCY head;
TS epoch;
};
A calendar is a concept of measuring time in various cycles. Such
cycles are years, months, days, hours, minutes, seconds, and
weeks. Some of these cycles are synchronized and some are not (e.g.,
weeks and months are not synchronized.)
After "rolling the time axis" into these cycles (See the figure)
a calendar expresses a point in time as a sequence
of integer counts of cycles, e.g., for year, month, day, hour,
etc. The calendar is rooted in some conventional start point, called
the "epoch."
A calendar "rolls" the time axis into a complex convolute according to
the calendar periods year (blue), month (yellow), day (green), hour
(red), etc. The cycles need not be aligned, for example, the week (not
shown) is not aligned to the month.
Imagine a special clock that measures those cycles, where the pointers
are not all stacked on a common axis but each pointer is attached to
the end of the pointer measuring the next larger cycle.
Calendar is defined as a set of calendar cycles, and has a name and a
code. The head of the Calendar is the largest CalendarCycle appearing
right most in the calendar expression. The epoch is the beginning of
that calendar, i.e., the point in time where all calendar cycles are
zero.
The calendar definition can be shown as in
for the modern Gregorian calendar. The calendar definition table lists a
calendar cycle in each row. The calendar units are dependent on each other and
defined in the value column. The sequence column shows the relationship through
the next property. The other columns are as in the formal calendar cycle
definition.
At present, the CalendarCycle properties sum and value are not
formally defined. The computation of calendar digits involves some
complex computation which to specify here would be hard to understand
and evaluate for correctness. Unfortunately, no standard exists that
would formally define the relationship between calendar expressions
and elapsed time since an epoch. ASN.1, the XML Schema Data Type
specification and SQL92 all refer to ISO 8601, however, ISO 8601 does
only specify the syntax of Gregorian calendar expressions, but not
their semantics. In this standard, we define the syntax and semantics
formally, however, we presume the semantics of the sum-, and
value-properties to be defined elsewhere.
private type Calendar alias CAL specializes SET<CLCY> {
CS name;
CLCY head;
TS epoch;
};
CLCY (CalendarCycle)
A calendar cycle defines one group of decimal digits in the calendar
expression. Examples for calendar cycles are year, month, day, hour,
minute, second, and week.
A calendar cycle has a name and two codes, a one-letter code and a
two-letter code. The property ndigits is the number of
decimal digits occupied in the calendar expression. The property
start specifies where counting starts (i.e., at 0 or 1.)
The next property is the next lower cycle in the order of
the calendar expression. The max(t) property is the
maximum number of cycles at time t (max depends on the
time t to account for leap years and leap seconds.) The
property value(t) is the integer number of cycles shown
in the calendar expression of time t. The property
sum(t, n) is the sum of n
calendar cycles added to the time t.
private type CalendarCycle alias CLCY specializes ANY {
CE name;
INT ndigits;
INT start;
CLCY next;
INT max(TS t);
TS sum(TS t, REAL r);
INT value(TS t);
};
A calendar cycle defines one group of decimal digits in the calendar
expression. Examples for calendar cycles are year, month, day, hour,
minute, second, and week.
A calendar cycle has a name and two codes, a one-letter code and a
two-letter code. The property ndigits is the number of
decimal digits occupied in the calendar expression. The property
start specifies where counting starts (i.e., at 0 or 1.)
The next property is the next lower cycle in the order of
the calendar expression. The max(t) property is the
maximum number of cycles at time t (max depends on the
time t to account for leap years and leap seconds.) The
property value(t) is the integer number of cycles shown
in the calendar expression of time t. The property
sum(t, n) is the sum of n
calendar cycles added to the time t.
private type CalendarCycle alias CLCY specializes ANY {
CE name;
INT ndigits;
INT start;
CLCY next;
INT max(TS t);
TS sum(TS t, REAL r);
INT value(TS t);
};
A calendar cycle defines one group of decimal digits in the calendar
expression. Examples for calendar cycles are year, month, day, hour,
minute, second, and week.
A calendar cycle has a name and two codes, a one-letter code and a
two-letter code. The property ndigits is the number of
decimal digits occupied in the calendar expression. The property
start specifies where counting starts (i.e., at 0 or 1.)
The next property is the next lower cycle in the order of
the calendar expression. The max(t) property is the
maximum number of cycles at time t (max depends on the
time t to account for leap years and leap seconds.) The
property value(t) is the integer number of cycles shown
in the calendar expression of time t. The property
sum(t, n) is the sum of n
calendar cycles added to the time t.
private type CalendarCycle alias CLCY specializes ANY {
CE name;
INT ndigits;
INT start;
CLCY next;
INT max(TS t);
TS sum(TS t, REAL r);
INT value(TS t);
};
A calendar cycle defines one group of decimal digits in the calendar
expression. Examples for calendar cycles are year, month, day, hour,
minute, second, and week.
A calendar cycle has a name and two codes, a one-letter code and a
two-letter code. The property ndigits is the number of
decimal digits occupied in the calendar expression. The property
start specifies where counting starts (i.e., at 0 or 1.)
The next property is the next lower cycle in the order of
the calendar expression. The max(t) property is the
maximum number of cycles at time t (max depends on the
time t to account for leap years and leap seconds.) The
property value(t) is the integer number of cycles shown
in the calendar expression of time t. The property
sum(t, n) is the sum of n
calendar cycles added to the time t.
private type CalendarCycle alias CLCY specializes ANY {
CE name;
INT ndigits;
INT start;
CLCY next;
INT max(TS t);
TS sum(TS t, REAL r);
INT value(TS t);
};
A calendar cycle defines one group of decimal digits in the calendar
expression. Examples for calendar cycles are year, month, day, hour,
minute, second, and week.
A calendar cycle has a name and two codes, a one-letter code and a
two-letter code. The property ndigits is the number of
decimal digits occupied in the calendar expression. The property
start specifies where counting starts (i.e., at 0 or 1.)
The next property is the next lower cycle in the order of
the calendar expression. The max(t) property is the
maximum number of cycles at time t (max depends on the
time t to account for leap years and leap seconds.) The
property value(t) is the integer number of cycles shown
in the calendar expression of time t. The property
sum(t, n) is the sum of n
calendar cycles added to the time t.
private type CalendarCycle alias CLCY specializes ANY {
CE name;
INT ndigits;
INT start;
CLCY next;
INT max(TS t);
TS sum(TS t, REAL r);
INT value(TS t);
};
A calendar cycle defines one group of decimal digits in the calendar
expression. Examples for calendar cycles are year, month, day, hour,
minute, second, and week.
A calendar cycle has a name and two codes, a one-letter code and a
two-letter code. The property ndigits is the number of
decimal digits occupied in the calendar expression. The property
start specifies where counting starts (i.e., at 0 or 1.)
The next property is the next lower cycle in the order of
the calendar expression. The max(t) property is the
maximum number of cycles at time t (max depends on the
time t to account for leap years and leap seconds.) The
property value(t) is the integer number of cycles shown
in the calendar expression of time t. The property
sum(t, n) is the sum of n
calendar cycles added to the time t.
private type CalendarCycle alias CLCY specializes ANY {
CE name;
INT ndigits;
INT start;
CLCY next;
INT max(TS t);
TS sum(TS t, REAL r);
INT value(TS t);
};
A calendar cycle defines one group of decimal digits in the calendar
expression. Examples for calendar cycles are year, month, day, hour,
minute, second, and week.
A calendar cycle has a name and two codes, a one-letter code and a
two-letter code. The property ndigits is the number of
decimal digits occupied in the calendar expression. The property
start specifies where counting starts (i.e., at 0 or 1.)
The next property is the next lower cycle in the order of
the calendar expression. The max(t) property is the
maximum number of cycles at time t (max depends on the
time t to account for leap years and leap seconds.) The
property value(t) is the integer number of cycles shown
in the calendar expression of time t. The property
sum(t, n) is the sum of n
calendar cycles added to the time t.
private type CalendarCycle alias CLCY specializes ANY {
CE name;
INT ndigits;
INT start;
CLCY next;
INT max(TS t);
TS sum(TS t, REAL r);
INT value(TS t);
};
A calendar cycle defines one group of decimal digits in the calendar
expression. Examples for calendar cycles are year, month, day, hour,
minute, second, and week.
A calendar cycle has a name and two codes, a one-letter code and a
two-letter code. The property ndigits is the number of
decimal digits occupied in the calendar expression. The property
start specifies where counting starts (i.e., at 0 or 1.)
The next property is the next lower cycle in the order of
the calendar expression. The max(t) property is the
maximum number of cycles at time t (max depends on the
time t to account for leap years and leap seconds.) The
property value(t) is the integer number of cycles shown
in the calendar expression of time t. The property
sum(t, n) is the sum of n
calendar cycles added to the time t.
private type CalendarCycle alias CLCY specializes ANY {
CE name;
INT ndigits;
INT start;
CLCY next;
INT max(TS t);
TS sum(TS t, REAL r);
INT value(TS t);
};
A calendar cycle defines one group of decimal digits in the calendar
expression. Examples for calendar cycles are year, month, day, hour,
minute, second, and week.
A calendar cycle has a name and two codes, a one-letter code and a
two-letter code. The property ndigits is the number of
decimal digits occupied in the calendar expression. The property
start specifies where counting starts (i.e., at 0 or 1.)
The next property is the next lower cycle in the order of
the calendar expression. The max(t) property is the
maximum number of cycles at time t (max depends on the
time t to account for leap years and leap seconds.) The
property value(t) is the integer number of cycles shown
in the calendar expression of time t. The property
sum(t, n) is the sum of n
calendar cycles added to the time t.
private type CalendarCycle alias CLCY specializes ANY {
CE name;
INT ndigits;
INT start;
CLCY next;
INT max(TS t);
TS sum(TS t, REAL r);
INT value(TS t);
};
TS (PointInTime)
A quantity specifying a point on the axis of natural time. A point
in time is most often represented as a calendar expression.
Semantically, however, time is independent from calendars and best
described by its relationship to elapsed time (measured as a physical
quantity in the dimension of time.) A point in time plus an elapsed
time yields another point in time. Inversely, a point in time minus
another point in time yields an elapsed time.
As nobody knows when time began, a point in time is conceptualized as
the amount of time that has elapsed from some arbitrary zero-point,
called an epoch. Because there is no absolute zero-point on the time
axis natural time is a difference-scale quantity, where only
differences are defined but no ratios. (For example, no point in time
is - absolutely speaking - "twice as late" as another
point in time.)
Given some arbitrary zero-point, one can express any point in time as
an elapsed time measured from that offset. Such an arbitrary
zero-point is called an epoch. This epoch-offset form is used as a
semantic representation here, without implying that any system would
have to implement the TS data type in that way. Systems that do not
need to compute distances between points in time will not need any
other representation than a calendar expression literal.
type PointInTime alias TS specializes QTY {
PQ offset;
CS calendar;
INT precision;
PQ timezone;
TS plus(QTY x);
literal ST;
};
A quantity specifying a point on the axis of natural time. A point
in time is most often represented as a calendar expression.
Semantically, however, time is independent from calendars and best
described by its relationship to elapsed time (measured as a physical
quantity in the dimension of time.) A point in time plus an elapsed
time yields another point in time. Inversely, a point in time minus
another point in time yields an elapsed time.
As nobody knows when time began, a point in time is conceptualized as
the amount of time that has elapsed from some arbitrary zero-point,
called an epoch. Because there is no absolute zero-point on the time
axis natural time is a difference-scale quantity, where only
differences are defined but no ratios. (For example, no point in time
is - absolutely speaking - "twice as late" as another
point in time.)
Given some arbitrary zero-point, one can express any point in time as
an elapsed time measured from that offset. Such an arbitrary
zero-point is called an epoch. This epoch-offset form is used as a
semantic representation here, without implying that any system would
have to implement the TS data type in that way. Systems that do not
need to compute distances between points in time will not need any
other representation than a calendar expression literal.
type PointInTime alias TS specializes QTY {
PQ offset;
CS calendar;
INT precision;
PQ timezone;
TS plus(QTY x);
literal ST;
};
A quantity specifying a point on the axis of natural time. A point
in time is most often represented as a calendar expression.
Semantically, however, time is independent from calendars and best
described by its relationship to elapsed time (measured as a physical
quantity in the dimension of time.) A point in time plus an elapsed
time yields another point in time. Inversely, a point in time minus
another point in time yields an elapsed time.
As nobody knows when time began, a point in time is conceptualized as
the amount of time that has elapsed from some arbitrary zero-point,
called an epoch. Because there is no absolute zero-point on the time
axis natural time is a difference-scale quantity, where only
differences are defined but no ratios. (For example, no point in time
is - absolutely speaking - "twice as late" as another
point in time.)
Given some arbitrary zero-point, one can express any point in time as
an elapsed time measured from that offset. Such an arbitrary
zero-point is called an epoch. This epoch-offset form is used as a
semantic representation here, without implying that any system would
have to implement the TS data type in that way. Systems that do not
need to compute distances between points in time will not need any
other representation than a calendar expression literal.
type PointInTime alias TS specializes QTY {
PQ offset;
CS calendar;
INT precision;
PQ timezone;
TS plus(QTY x);
literal ST;
};
A quantity specifying a point on the axis of natural time. A point
in time is most often represented as a calendar expression.
Semantically, however, time is independent from calendars and best
described by its relationship to elapsed time (measured as a physical
quantity in the dimension of time.) A point in time plus an elapsed
time yields another point in time. Inversely, a point in time minus
another point in time yields an elapsed time.
As nobody knows when time began, a point in time is conceptualized as
the amount of time that has elapsed from some arbitrary zero-point,
called an epoch. Because there is no absolute zero-point on the time
axis natural time is a difference-scale quantity, where only
differences are defined but no ratios. (For example, no point in time
is - absolutely speaking - "twice as late" as another
point in time.)
Given some arbitrary zero-point, one can express any point in time as
an elapsed time measured from that offset. Such an arbitrary
zero-point is called an epoch. This epoch-offset form is used as a
semantic representation here, without implying that any system would
have to implement the TS data type in that way. Systems that do not
need to compute distances between points in time will not need any
other representation than a calendar expression literal.
type PointInTime alias TS specializes QTY {
PQ offset;
CS calendar;
INT precision;
PQ timezone;
TS plus(QTY x);
literal ST;
};
A quantity specifying a point on the axis of natural time. A point
in time is most often represented as a calendar expression.
Semantically, however, time is independent from calendars and best
described by its relationship to elapsed time (measured as a physical
quantity in the dimension of time.) A point in time plus an elapsed
time yields another point in time. Inversely, a point in time minus
another point in time yields an elapsed time.
As nobody knows when time began, a point in time is conceptualized as
the amount of time that has elapsed from some arbitrary zero-point,
called an epoch. Because there is no absolute zero-point on the time
axis natural time is a difference-scale quantity, where only
differences are defined but no ratios. (For example, no point in time
is - absolutely speaking - "twice as late" as another
point in time.)
Given some arbitrary zero-point, one can express any point in time as
an elapsed time measured from that offset. Such an arbitrary
zero-point is called an epoch. This epoch-offset form is used as a
semantic representation here, without implying that any system would
have to implement the TS data type in that way. Systems that do not
need to compute distances between points in time will not need any
other representation than a calendar expression literal.
type PointInTime alias TS specializes QTY {
PQ offset;
CS calendar;
INT precision;
PQ timezone;
TS plus(QTY x);
literal ST;
};
A quantity specifying a point on the axis of natural time. A point
in time is most often represented as a calendar expression.
Semantically, however, time is independent from calendars and best
described by its relationship to elapsed time (measured as a physical
quantity in the dimension of time.) A point in time plus an elapsed
time yields another point in time. Inversely, a point in time minus
another point in time yields an elapsed time.
As nobody knows when time began, a point in time is conceptualized as
the amount of time that has elapsed from some arbitrary zero-point,
called an epoch. Because there is no absolute zero-point on the time
axis natural time is a difference-scale quantity, where only
differences are defined but no ratios. (For example, no point in time
is - absolutely speaking - "twice as late" as another
point in time.)
Given some arbitrary zero-point, one can express any point in time as
an elapsed time measured from that offset. Such an arbitrary
zero-point is called an epoch. This epoch-offset form is used as a
semantic representation here, without implying that any system would
have to implement the TS data type in that way. Systems that do not
need to compute distances between points in time will not need any
other representation than a calendar expression literal.
type PointInTime alias TS specializes QTY {
PQ offset;
CS calendar;
INT precision;
PQ timezone;
TS plus(QTY x);
literal ST;
};
A quantity specifying a point on the axis of natural time. A point
in time is most often represented as a calendar expression.
Semantically, however, time is independent from calendars and best
described by its relationship to elapsed time (measured as a physical
quantity in the dimension of time.) A point in time plus an elapsed
time yields another point in time. Inversely, a point in time minus
another point in time yields an elapsed time.
As nobody knows when time began, a point in time is conceptualized as
the amount of time that has elapsed from some arbitrary zero-point,
called an epoch. Because there is no absolute zero-point on the time
axis natural time is a difference-scale quantity, where only
differences are defined but no ratios. (For example, no point in time
is - absolutely speaking - "twice as late" as another
point in time.)
Given some arbitrary zero-point, one can express any point in time as
an elapsed time measured from that offset. Such an arbitrary
zero-point is called an epoch. This epoch-offset form is used as a
semantic representation here, without implying that any system would
have to implement the TS data type in that way. Systems that do not
need to compute distances between points in time will not need any
other representation than a calendar expression literal.
type PointInTime alias TS specializes QTY {
PQ offset;
CS calendar;
INT precision;
PQ timezone;
TS plus(QTY x);
literal ST;
};
A quantity specifying a point on the axis of natural time. A point
in time is most often represented as a calendar expression.
Semantically, however, time is independent from calendars and best
described by its relationship to elapsed time (measured as a physical
quantity in the dimension of time.) A point in time plus an elapsed
time yields another point in time. Inversely, a point in time minus
another point in time yields an elapsed time.
As nobody knows when time began, a point in time is conceptualized as
the amount of time that has elapsed from some arbitrary zero-point,
called an epoch. Because there is no absolute zero-point on the time
axis natural time is a difference-scale quantity, where only
differences are defined but no ratios. (For example, no point in time
is - absolutely speaking - "twice as late" as another
point in time.)
Given some arbitrary zero-point, one can express any point in time as
an elapsed time measured from that offset. Such an arbitrary
zero-point is called an epoch. This epoch-offset form is used as a
semantic representation here, without implying that any system would
have to implement the TS data type in that way. Systems that do not
need to compute distances between points in time will not need any
other representation than a calendar expression literal.
type PointInTime alias TS specializes QTY {
PQ offset;
CS calendar;
INT precision;
PQ timezone;
TS plus(QTY x);
literal ST;
};
A quantity specifying a point on the axis of natural time. A point
in time is most often represented as a calendar expression.
Semantically, however, time is independent from calendars and best
described by its relationship to elapsed time (measured as a physical
quantity in the dimension of time.) A point in time plus an elapsed
time yields another point in time. Inversely, a point in time minus
another point in time yields an elapsed time.
As nobody knows when time began, a point in time is conceptualized as
the amount of time that has elapsed from some arbitrary zero-point,
called an epoch. Because there is no absolute zero-point on the time
axis natural time is a difference-scale quantity, where only
differences are defined but no ratios. (For example, no point in time
is - absolutely speaking - "twice as late" as another
point in time.)
Given some arbitrary zero-point, one can express any point in time as
an elapsed time measured from that offset. Such an arbitrary
zero-point is called an epoch. This epoch-offset form is used as a
semantic representation here, without implying that any system would
have to implement the TS data type in that way. Systems that do not
need to compute distances between points in time will not need any
other representation than a calendar expression literal.
type PointInTime alias TS specializes QTY {
PQ offset;
CS calendar;
INT precision;
PQ timezone;
TS plus(QTY x);
literal ST;
};
A quantity specifying a point on the axis of natural time. A point
in time is most often represented as a calendar expression.
Semantically, however, time is independent from calendars and best
described by its relationship to elapsed time (measured as a physical
quantity in the dimension of time.) A point in time plus an elapsed
time yields another point in time. Inversely, a point in time minus
another point in time yields an elapsed time.
As nobody knows when time began, a point in time is conceptualized as
the amount of time that has elapsed from some arbitrary zero-point,
called an epoch. Because there is no absolute zero-point on the time
axis natural time is a difference-scale quantity, where only
differences are defined but no ratios. (For example, no point in time
is - absolutely speaking - "twice as late" as another
point in time.)
Given some arbitrary zero-point, one can express any point in time as
an elapsed time measured from that offset. Such an arbitrary
zero-point is called an epoch. This epoch-offset form is used as a
semantic representation here, without implying that any system would
have to implement the TS data type in that way. Systems that do not
need to compute distances between points in time will not need any
other representation than a calendar expression literal.
type PointInTime alias TS specializes QTY {
PQ offset;
CS calendar;
INT precision;
PQ timezone;
TS plus(QTY x);
literal ST;
};
SET (Set)
A value that contains other distinct values in no particular order.
template<ANY T>
type Set<T> alias SET<T> specializes ANY {
BL contains(T element);
BL contains(SET<T> subset);
BL isEmpty;
BL notEmpty;
INT cardinality;
SET<T> union(SET<T> otherset);
SET<T> union(T element);
SET<T> except(T element);
SET<T> except(SET<T> otherset);
SET<T> intersection(SET<T> otherset);
literal ST;
promotion SET<T> (T x);
IVL<T> hull;
};
A value that contains other distinct values in no particular order.
template<ANY T>
type Set<T> alias SET<T> specializes ANY {
BL contains(T element);
BL contains(SET<T> subset);
BL isEmpty;
BL notEmpty;
INT cardinality;
SET<T> union(SET<T> otherset);
SET<T> union(T element);
SET<T> except(T element);
SET<T> except(SET<T> otherset);
SET<T> intersection(SET<T> otherset);
literal ST;
promotion SET<T> (T x);
IVL<T> hull;
};
A value that contains other distinct values in no particular order.
template<ANY T>
type Set<T> alias SET<T> specializes ANY {
BL contains(T element);
BL contains(SET<T> subset);
BL isEmpty;
BL notEmpty;
INT cardinality;
SET<T> union(SET<T> otherset);
SET<T> union(T element);
SET<T> except(T element);
SET<T> except(SET<T> otherset);
SET<T> intersection(SET<T> otherset);
literal ST;
promotion SET<T> (T x);
IVL<T> hull;
};
A value that contains other distinct values in no particular order.
template<ANY T>
type Set<T> alias SET<T> specializes ANY {
BL contains(T element);
BL contains(SET<T> subset);
BL isEmpty;
BL notEmpty;
INT cardinality;
SET<T> union(SET<T> otherset);
SET<T> union(T element);
SET<T> except(T element);
SET<T> except(SET<T> otherset);
SET<T> intersection(SET<T> otherset);
literal ST;
promotion SET<T> (T x);
IVL<T> hull;
};
A value that contains other distinct values in no particular order.
template<ANY T>
type Set<T> alias SET<T> specializes ANY {
BL contains(T element);
BL contains(SET<T> subset);
BL isEmpty;
BL notEmpty;
INT cardinality;
SET<T> union(SET<T> otherset);
SET<T> union(T element);
SET<T> except(T element);
SET<T> except(SET<T> otherset);
SET<T> intersection(SET<T> otherset);
literal ST;
promotion SET<T> (T x);
IVL<T> hull;
};
A value that contains other distinct values in no particular order.
template<ANY T>
type Set<T> alias SET<T> specializes ANY {
BL contains(T element);
BL contains(SET<T> subset);
BL isEmpty;
BL notEmpty;
INT cardinality;
SET<T> union(SET<T> otherset);
SET<T> union(T element);
SET<T> except(T element);
SET<T> except(SET<T> otherset);
SET<T> intersection(SET<T> otherset);
literal ST;
promotion SET<T> (T x);
IVL<T> hull;
};
A value that contains other distinct values in no particular order.
template<ANY T>
type Set<T> alias SET<T> specializes ANY {
BL contains(T element);
BL contains(SET<T> subset);
BL isEmpty;
BL notEmpty;
INT cardinality;
SET<T> union(SET<T> otherset);
SET<T> union(T element);
SET<T> except(T element);
SET<T> except(SET<T> otherset);
SET<T> intersection(SET<T> otherset);
literal ST;
promotion SET<T> (T x);
IVL<T> hull;
};
A value that contains other distinct values in no particular order.
template<ANY T>
type Set<T> alias SET<T> specializes ANY {
BL contains(T element);
BL contains(SET<T> subset);
BL isEmpty;
BL notEmpty;
INT cardinality;
SET<T> union(SET<T> otherset);
SET<T> union(T element);
SET<T> except(T element);
SET<T> except(SET<T> otherset);
SET<T> intersection(SET<T> otherset);
literal ST;
promotion SET<T> (T x);
IVL<T> hull;
};
A value that contains other distinct values in no particular order.
template<ANY T>
type Set<T> alias SET<T> specializes ANY {
BL contains(T element);
BL contains(SET<T> subset);
BL isEmpty;
BL notEmpty;
INT cardinality;
SET<T> union(SET<T> otherset);
SET<T> union(T element);
SET<T> except(T element);
SET<T> except(SET<T> otherset);
SET<T> intersection(SET<T> otherset);
literal ST;
promotion SET<T> (T x);
IVL<T> hull;
};
A value that contains other distinct values in no particular order.
template<ANY T>
type Set<T> alias SET<T> specializes ANY {
BL contains(T element);
BL contains(SET<T> subset);
BL isEmpty;
BL notEmpty;
INT cardinality;
SET<T> union(SET<T> otherset);
SET<T> union(T element);
SET<T> except(T element);
SET<T> except(SET<T> otherset);
SET<T> intersection(SET<T> otherset);
literal ST;
promotion SET<T> (T x);
IVL<T> hull;
};
A value that contains other distinct values in no particular order.
template<ANY T>
type Set<T> alias SET<T> specializes ANY {
BL contains(T element);
BL contains(SET<T> subset);
BL isEmpty;
BL notEmpty;
INT cardinality;
SET<T> union(SET<T> otherset);
SET<T> union(T element);
SET<T> except(T element);
SET<T> except(SET<T> otherset);
SET<T> intersection(SET<T> otherset);
literal ST;
promotion SET<T> (T x);
IVL<T> hull;
};
A value that contains other distinct values in no particular order.
template<ANY T>
type Set<T> alias SET<T> specializes ANY {
BL contains(T element);
BL contains(SET<T> subset);
BL isEmpty;
BL notEmpty;
INT cardinality;
SET<T> union(SET<T> otherset);
SET<T> union(T element);
SET<T> except(T element);
SET<T> except(SET<T> otherset);
SET<T> intersection(SET<T> otherset);
literal ST;
promotion SET<T> (T x);
IVL<T> hull;
};
A value that contains other distinct values in no particular order.
template<ANY T>
type Set<T> alias SET<T> specializes ANY {
BL contains(T element);
BL contains(SET<T> subset);
BL isEmpty;
BL notEmpty;
INT cardinality;
SET<T> union(SET<T> otherset);
SET<T> union(T element);
SET<T> except(T element);
SET<T> except(SET<T> otherset);
SET<T> intersection(SET<T> otherset);
literal ST;
promotion SET<T> (T x);
IVL<T> hull;
};
A value that contains other distinct values in no particular order.
template<ANY T>
type Set<T> alias SET<T> specializes ANY {
BL contains(T element);
BL contains(SET<T> subset);
BL isEmpty;
BL notEmpty;
INT cardinality;
SET<T> union(SET<T> otherset);
SET<T> union(T element);
SET<T> except(T element);
SET<T> except(SET<T> otherset);
SET<T> intersection(SET<T> otherset);
literal ST;
promotion SET<T> (T x);
IVL<T> hull;
};
LIST (Sequence)
A value that contains other discrete (but not necessarily distinct) values in a defined sequence.
A sequence may contain NULL values as items.
template<ANY T>
type Sequence<T> alias LIST<T> specializes ANY {
T head;
LIST<T> tail;
BL isEmpty;
BL notEmpty;
T item(INT index);
BL contains(T item);
INT length;
literal ST;
promotion LIST<T> (T x);
};
A value that contains other discrete (but not necessarily distinct) values in a defined sequence.
A sequence may contain NULL values as items.
template<ANY T>
type Sequence<T> alias LIST<T> specializes ANY {
T head;
LIST<T> tail;
BL isEmpty;
BL notEmpty;
T item(INT index);
BL contains(T item);
INT length;
literal ST;
promotion LIST<T> (T x);
};
A value that contains other discrete (but not necessarily distinct) values in a defined sequence.
A sequence may contain NULL values as items.
template<ANY T>
type Sequence<T> alias LIST<T> specializes ANY {
T head;
LIST<T> tail;
BL isEmpty;
BL notEmpty;
T item(INT index);
BL contains(T item);
INT length;
literal ST;
promotion LIST<T> (T x);
};
A value that contains other discrete (but not necessarily distinct) values in a defined sequence.
A sequence may contain NULL values as items.
template<ANY T>
type Sequence<T> alias LIST<T> specializes ANY {
T head;
LIST<T> tail;
BL isEmpty;
BL notEmpty;
T item(INT index);
BL contains(T item);
INT length;
literal ST;
promotion LIST<T> (T x);
};
A value that contains other discrete (but not necessarily distinct) values in a defined sequence.
A sequence may contain NULL values as items.
template<ANY T>
type Sequence<T> alias LIST<T> specializes ANY {
T head;
LIST<T> tail;
BL isEmpty;
BL notEmpty;
T item(INT index);
BL contains(T item);
INT length;
literal ST;
promotion LIST<T> (T x);
};
A value that contains other discrete (but not necessarily distinct) values in a defined sequence.
A sequence may contain NULL values as items.
template<ANY T>
type Sequence<T> alias LIST<T> specializes ANY {
T head;
LIST<T> tail;
BL isEmpty;
BL notEmpty;
T item(INT index);
BL contains(T item);
INT length;
literal ST;
promotion LIST<T> (T x);
};
A value that contains other discrete (but not necessarily distinct) values in a defined sequence.
A sequence may contain NULL values as items.
template<ANY T>
type Sequence<T> alias LIST<T> specializes ANY {
T head;
LIST<T> tail;
BL isEmpty;
BL notEmpty;
T item(INT index);
BL contains(T item);
INT length;
literal ST;
promotion LIST<T> (T x);
};
A value that contains other discrete (but not necessarily distinct) values in a defined sequence.
A sequence may contain NULL values as items.
template<ANY T>
type Sequence<T> alias LIST<T> specializes ANY {
T head;
LIST<T> tail;
BL isEmpty;
BL notEmpty;
T item(INT index);
BL contains(T item);
INT length;
literal ST;
promotion LIST<T> (T x);
};
A value that contains other discrete (but not necessarily distinct) values in a defined sequence.
A sequence may contain NULL values as items.
template<ANY T>
type Sequence<T> alias LIST<T> specializes ANY {
T head;
LIST<T> tail;
BL isEmpty;
BL notEmpty;
T item(INT index);
BL contains(T item);
INT length;
literal ST;
promotion LIST<T> (T x);
};
A value that contains other discrete (but not necessarily distinct) values in a defined sequence.
A sequence may contain NULL values as items.
template<ANY T>
type Sequence<T> alias LIST<T> specializes ANY {
T head;
LIST<T> tail;
BL isEmpty;
BL notEmpty;
T item(INT index);
BL contains(T item);
INT length;
literal ST;
promotion LIST<T> (T x);
};
A value that contains other discrete (but not necessarily distinct) values in a defined sequence.
A sequence may contain NULL values as items.
template<ANY T>
type Sequence<T> alias LIST<T> specializes ANY {
T head;
LIST<T> tail;
BL isEmpty;
BL notEmpty;
T item(INT index);
BL contains(T item);
INT length;
literal ST;
promotion LIST<T> (T x);
};
GLIST (GeneratedSequence)
A periodic or monotone sequence of values generated from a few
parameters, rather than being enumerated. Used to specify regular
sampling points for biosignals.
The item at a certain index in the list is calculated by performing an
integer division on the index (i) with the
(d) and then take that
value's remainder with the
(p). Multiply this value with the
(?x) and add to the
(x 0.)
x i
=
x 0
+
?x
?
(i/d)
mod p Examples for Generated Sequences head increment denominator period meaning 0 1 1 8 The identity-sequence where each item is equal to its index. 198706052000 2 hour 1 8 Sequence starting on June 5, 1987 at 7 PM and
incrementing every two hours: 9 PM, 11 PM, 1 AM (June 6), 3
AM, 5 AM, and so on. 0 V 1 mV 1 100 The x-wave of a digital oscillograph scanning between
0 and 100 mV in 100 steps of 1 mV. The frequency is unknown
from these data as we do not know how much time elapses
between each step of the index. 2002072920300 100
us 1 8 A timebase from June 29,
2002 at 8:30 PM with 100 us between each steps of the
index. If combined with the previous generator as a second
sampling dimension this would now describe our digital
oscilloscope's x-timebase as 1 mV per 100 us. At 100 steps
per period, the period is 10 ms, which is equal to a
frequency of 100 Hz. 0 V 1 mV 100 100 Combining this generator to the previous two generators
could describe a three-dimensional sampling space with two
voltages and time. This generator also steps at 1 mV and has
100 steps per period, however, it only steps every 100 index
increments, so, the first voltage generator makes one full
cycle before this generator is incremented. One can think of
the two voltages as "rows" and "columns" of a "sampling
frame". With the previous generator as the timebase, this
results in a scan of sampling frames of 100 mV ? 100
mV with a framerate of 1 Hz.
template<QTY T>
type GeneratedSequence<T> alias GLIST<T> specializes LIST<T> {
QTY increment;
INT period;
INT denominator;
};
A periodic or monotone sequence of values generated from a few
parameters, rather than being enumerated. Used to specify regular
sampling points for biosignals.
The item at a certain index in the list is calculated by performing an
integer division on the index (i) with the
(d) and then take that
value's remainder with the
(p). Multiply this value with the
(?x) and add to the
(x 0.)
x i
=
x 0
+
?x
?
(i/d)
mod p Examples for Generated Sequences head increment denominator period meaning 0 1 1 8 The identity-sequence where each item is equal to its index. 198706052000 2 hour 1 8 Sequence starting on June 5, 1987 at 7 PM and
incrementing every two hours: 9 PM, 11 PM, 1 AM (June 6), 3
AM, 5 AM, and so on. 0 V 1 mV 1 100 The x-wave of a digital oscillograph scanning between
0 and 100 mV in 100 steps of 1 mV. The frequency is unknown
from these data as we do not know how much time elapses
between each step of the index. 2002072920300 100
us 1 8 A timebase from June 29,
2002 at 8:30 PM with 100 us between each steps of the
index. If combined with the previous generator as a second
sampling dimension this would now describe our digital
oscilloscope's x-timebase as 1 mV per 100 us. At 100 steps
per period, the period is 10 ms, which is equal to a
frequency of 100 Hz. 0 V 1 mV 100 100 Combining this generator to the previous two generators
could describe a three-dimensional sampling space with two
voltages and time. This generator also steps at 1 mV and has
100 steps per period, however, it only steps every 100 index
increments, so, the first voltage generator makes one full
cycle before this generator is incremented. One can think of
the two voltages as "rows" and "columns" of a "sampling
frame". With the previous generator as the timebase, this
results in a scan of sampling frames of 100 mV ? 100
mV with a framerate of 1 Hz.
template<QTY T>
type GeneratedSequence<T> alias GLIST<T> specializes LIST<T> {
QTY increment;
INT period;
INT denominator;
};
A periodic or monotone sequence of values generated from a few
parameters, rather than being enumerated. Used to specify regular
sampling points for biosignals.
The item at a certain index in the list is calculated by performing an
integer division on the index (i) with the
(d) and then take that
value's remainder with the
(p). Multiply this value with the
(?x) and add to the
(x 0.)
x i
=
x 0
+
?x
?
(i/d)
mod p Examples for Generated Sequences head increment denominator period meaning 0 1 1 8 The identity-sequence where each item is equal to its index. 198706052000 2 hour 1 8 Sequence starting on June 5, 1987 at 7 PM and
incrementing every two hours: 9 PM, 11 PM, 1 AM (June 6), 3
AM, 5 AM, and so on. 0 V 1 mV 1 100 The x-wave of a digital oscillograph scanning between
0 and 100 mV in 100 steps of 1 mV. The frequency is unknown
from these data as we do not know how much time elapses
between each step of the index. 2002072920300 100
us 1 8 A timebase from June 29,
2002 at 8:30 PM with 100 us between each steps of the
index. If combined with the previous generator as a second
sampling dimension this would now describe our digital
oscilloscope's x-timebase as 1 mV per 100 us. At 100 steps
per period, the period is 10 ms, which is equal to a
frequency of 100 Hz. 0 V 1 mV 100 100 Combining this generator to the previous two generators
could describe a three-dimensional sampling space with two
voltages and time. This generator also steps at 1 mV and has
100 steps per period, however, it only steps every 100 index
increments, so, the first voltage generator makes one full
cycle before this generator is incremented. One can think of
the two voltages as "rows" and "columns" of a "sampling
frame". With the previous generator as the timebase, this
results in a scan of sampling frames of 100 mV ? 100
mV with a framerate of 1 Hz.
template<QTY T>
type GeneratedSequence<T> alias GLIST<T> specializes LIST<T> {
QTY increment;
INT period;
INT denominator;
};
A periodic or monotone sequence of values generated from a few
parameters, rather than being enumerated. Used to specify regular
sampling points for biosignals.
The item at a certain index in the list is calculated by performing an
integer division on the index (i) with the
(d) and then take that
value's remainder with the
(p). Multiply this value with the
(?x) and add to the
(x 0.)
x i
=
x 0
+
?x
?
(i/d)
mod p Examples for Generated Sequences head increment denominator period meaning 0 1 1 8 The identity-sequence where each item is equal to its index. 198706052000 2 hour 1 8 Sequence starting on June 5, 1987 at 7 PM and
incrementing every two hours: 9 PM, 11 PM, 1 AM (June 6), 3
AM, 5 AM, and so on. 0 V 1 mV 1 100 The x-wave of a digital oscillograph scanning between
0 and 100 mV in 100 steps of 1 mV. The frequency is unknown
from these data as we do not know how much time elapses
between each step of the index. 2002072920300 100
us 1 8 A timebase from June 29,
2002 at 8:30 PM with 100 us between each steps of the
index. If combined with the previous generator as a second
sampling dimension this would now describe our digital
oscilloscope's x-timebase as 1 mV per 100 us. At 100 steps
per period, the period is 10 ms, which is equal to a
frequency of 100 Hz. 0 V 1 mV 100 100 Combining this generator to the previous two generators
could describe a three-dimensional sampling space with two
voltages and time. This generator also steps at 1 mV and has
100 steps per period, however, it only steps every 100 index
increments, so, the first voltage generator makes one full
cycle before this generator is incremented. One can think of
the two voltages as "rows" and "columns" of a "sampling
frame". With the previous generator as the timebase, this
results in a scan of sampling frames of 100 mV ? 100
mV with a framerate of 1 Hz.
template<QTY T>
type GeneratedSequence<T> alias GLIST<T> specializes LIST<T> {
QTY increment;
INT period;
INT denominator;
};
A periodic or monotone sequence of values generated from a few
parameters, rather than being enumerated. Used to specify regular
sampling points for biosignals.
The item at a certain index in the list is calculated by performing an
integer division on the index (i) with the
(d) and then take that
value's remainder with the
(p). Multiply this value with the
(?x) and add to the
(x 0.)
x i
=
x 0
+
?x
?
(i/d)
mod p Examples for Generated Sequences head increment denominator period meaning 0 1 1 8 The identity-sequence where each item is equal to its index. 198706052000 2 hour 1 8 Sequence starting on June 5, 1987 at 7 PM and
incrementing every two hours: 9 PM, 11 PM, 1 AM (June 6), 3
AM, 5 AM, and so on. 0 V 1 mV 1 100 The x-wave of a digital oscillograph scanning between
0 and 100 mV in 100 steps of 1 mV. The frequency is unknown
from these data as we do not know how much time elapses
between each step of the index. 2002072920300 100
us 1 8 A timebase from June 29,
2002 at 8:30 PM with 100 us between each steps of the
index. If combined with the previous generator as a second
sampling dimension this would now describe our digital
oscilloscope's x-timebase as 1 mV per 100 us. At 100 steps
per period, the period is 10 ms, which is equal to a
frequency of 100 Hz. 0 V 1 mV 100 100 Combining this generator to the previous two generators
could describe a three-dimensional sampling space with two
voltages and time. This generator also steps at 1 mV and has
100 steps per period, however, it only steps every 100 index
increments, so, the first voltage generator makes one full
cycle before this generator is incremented. One can think of
the two voltages as "rows" and "columns" of a "sampling
frame". With the previous generator as the timebase, this
results in a scan of sampling frames of 100 mV ? 100
mV with a framerate of 1 Hz.
template<QTY T>
type GeneratedSequence<T> alias GLIST<T> specializes LIST<T> {
QTY increment;
INT period;
INT denominator;
};
SLIST (SampledSequence)
A sequence of sampled values scaled and translated from a list of
integer values. Used to specify sampled biosignals.
The item at a certain index (i) in the list is calculated
by multiplying the item at the same index in the
sequence
(d i ) with the (s)
and then add that value to the
(x o ).
x i
=
x o
+
s
?
d i
template<QTY T>
type SampledSequence<T> alias SLIST<T> specializes LIST<T> {
T origin;
QTY scale;
LIST<INT> digits;
};
A sequence of sampled values scaled and translated from a list of
integer values. Used to specify sampled biosignals.
The item at a certain index (i) in the list is calculated
by multiplying the item at the same index in the
sequence
(d i ) with the (s)
and then add that value to the
(x o ).
x i
=
x o
+
s
?
d i
template<QTY T>
type SampledSequence<T> alias SLIST<T> specializes LIST<T> {
T origin;
QTY scale;
LIST<INT> digits;
};
A sequence of sampled values scaled and translated from a list of
integer values. Used to specify sampled biosignals.
The item at a certain index (i) in the list is calculated
by multiplying the item at the same index in the
sequence
(d i ) with the (s)
and then add that value to the
(x o ).
x i
=
x o
+
s
?
d i
template<QTY T>
type SampledSequence<T> alias SLIST<T> specializes LIST<T> {
T origin;
QTY scale;
LIST<INT> digits;
};
A sequence of sampled values scaled and translated from a list of
integer values. Used to specify sampled biosignals.
The item at a certain index (i) in the list is calculated
by multiplying the item at the same index in the
sequence
(d i ) with the (s)
and then add that value to the
(x o ).
x i
=
x o
+
s
?
d i
template<QTY T>
type SampledSequence<T> alias SLIST<T> specializes LIST<T> {
T origin;
QTY scale;
LIST<INT> digits;
};
BAG (Bag)
An unordered collection of values, where each value can be contained
more than once in the collection.
template<ANY T>
type Bag<T> alias BAG<T> specializes ANY {
INT contains(T kind);
BL isEmpty;
BL notEmpty;
BAG<T> plus(BAG<T> x);
BAG<T> minus(BAG<T> x);
promotion BAG<T> (T x);
};
An unordered collection of values, where each value can be contained
more than once in the collection.
template<ANY T>
type Bag<T> alias BAG<T> specializes ANY {
INT contains(T kind);
BL isEmpty;
BL notEmpty;
BAG<T> plus(BAG<T> x);
BAG<T> minus(BAG<T> x);
promotion BAG<T> (T x);
};
An unordered collection of values, where each value can be contained
more than once in the collection.
template<ANY T>
type Bag<T> alias BAG<T> specializes ANY {
INT contains(T kind);
BL isEmpty;
BL notEmpty;
BAG<T> plus(BAG<T> x);
BAG<T> minus(BAG<T> x);
promotion BAG<T> (T x);
};
An unordered collection of values, where each value can be contained
more than once in the collection.
template<ANY T>
type Bag<T> alias BAG<T> specializes ANY {
INT contains(T kind);
BL isEmpty;
BL notEmpty;
BAG<T> plus(BAG<T> x);
BAG<T> minus(BAG<T> x);
promotion BAG<T> (T x);
};
An unordered collection of values, where each value can be contained
more than once in the collection.
template<ANY T>
type Bag<T> alias BAG<T> specializes ANY {
INT contains(T kind);
BL isEmpty;
BL notEmpty;
BAG<T> plus(BAG<T> x);
BAG<T> minus(BAG<T> x);
promotion BAG<T> (T x);
};
An unordered collection of values, where each value can be contained
more than once in the collection.
template<ANY T>
type Bag<T> alias BAG<T> specializes ANY {
INT contains(T kind);
BL isEmpty;
BL notEmpty;
BAG<T> plus(BAG<T> x);
BAG<T> minus(BAG<T> x);
promotion BAG<T> (T x);
};
An unordered collection of values, where each value can be contained
more than once in the collection.
template<ANY T>
type Bag<T> alias BAG<T> specializes ANY {
INT contains(T kind);
BL isEmpty;
BL notEmpty;
BAG<T> plus(BAG<T> x);
BAG<T> minus(BAG<T> x);
promotion BAG<T> (T x);
};
IVL (Interval)
A set of consecutive values of an ordered base data type.
Any ordered type can be the basis of an interval; it does not matter
whether the base type is discrete or continuous. If the base data type
is only partially ordered, all elements of the interval must be
elements of a totally ordered subset of the partially ordered data
type.
For example, physical quantities are considered ordered. However the
ordering of physical quantities is only partial; a total order is only
defined among comparable quantities (quantities of the same physical
dimension.) While intervals between 2 and 4 meter exists, there is no
interval between 2 meters and 4 seconds.
Intervals are sets and have all the properties of sets. However, union
and differences of intervals may not be intervals any more, since the
elements of these union and difference sets might not be
contiguous. Intersections of intervals are always intervals.
template<QTY T>
type Interval<T> alias IVL<T> specializes SET<T> {
T low;
BL lowClosed;
T high;
BL highClosed;
QTY width;
T center;
IVL<T> hull(IVL<T> x);
literal ST;
promotion IVL<T> (T x);
demotion T;
};
A set of consecutive values of an ordered base data type.
Any ordered type can be the basis of an interval; it does not matter
whether the base type is discrete or continuous. If the base data type
is only partially ordered, all elements of the interval must be
elements of a totally ordered subset of the partially ordered data
type.
For example, physical quantities are considered ordered. However the
ordering of physical quantities is only partial; a total order is only
defined among comparable quantities (quantities of the same physical
dimension.) While intervals between 2 and 4 meter exists, there is no
interval between 2 meters and 4 seconds.
Intervals are sets and have all the properties of sets. However, union
and differences of intervals may not be intervals any more, since the
elements of these union and difference sets might not be
contiguous. Intersections of intervals are always intervals.
template<QTY T>
type Interval<T> alias IVL<T> specializes SET<T> {
T low;
BL lowClosed;
T high;
BL highClosed;
QTY width;
T center;
IVL<T> hull(IVL<T> x);
literal ST;
promotion IVL<T> (T x);
demotion T;
};
A set of consecutive values of an ordered base data type.
Any ordered type can be the basis of an interval; it does not matter
whether the base type is discrete or continuous. If the base data type
is only partially ordered, all elements of the interval must be
elements of a totally ordered subset of the partially ordered data
type.
For example, physical quantities are considered ordered. However the
ordering of physical quantities is only partial; a total order is only
defined among comparable quantities (quantities of the same physical
dimension.) While intervals between 2 and 4 meter exists, there is no
interval between 2 meters and 4 seconds.
Intervals are sets and have all the properties of sets. However, union
and differences of intervals may not be intervals any more, since the
elements of these union and difference sets might not be
contiguous. Intersections of intervals are always intervals.
template<QTY T>
type Interval<T> alias IVL<T> specializes SET<T> {
T low;
BL lowClosed;
T high;
BL highClosed;
QTY width;
T center;
IVL<T> hull(IVL<T> x);
literal ST;
promotion IVL<T> (T x);
demotion T;
};
A set of consecutive values of an ordered base data type.
Any ordered type can be the basis of an interval; it does not matter
whether the base type is discrete or continuous. If the base data type
is only partially ordered, all elements of the interval must be
elements of a totally ordered subset of the partially ordered data
type.
For example, physical quantities are considered ordered. However the
ordering of physical quantities is only partial; a total order is only
defined among comparable quantities (quantities of the same physical
dimension.) While intervals between 2 and 4 meter exists, there is no
interval between 2 meters and 4 seconds.
Intervals are sets and have all the properties of sets. However, union
and differences of intervals may not be intervals any more, since the
elements of these union and difference sets might not be
contiguous. Intersections of intervals are always intervals.
template<QTY T>
type Interval<T> alias IVL<T> specializes SET<T> {
T low;
BL lowClosed;
T high;
BL highClosed;
QTY width;
T center;
IVL<T> hull(IVL<T> x);
literal ST;
promotion IVL<T> (T x);
demotion T;
};
A set of consecutive values of an ordered base data type.
Any ordered type can be the basis of an interval; it does not matter
whether the base type is discrete or continuous. If the base data type
is only partially ordered, all elements of the interval must be
elements of a totally ordered subset of the partially ordered data
type.
For example, physical quantities are considered ordered. However the
ordering of physical quantities is only partial; a total order is only
defined among comparable quantities (quantities of the same physical
dimension.) While intervals between 2 and 4 meter exists, there is no
interval between 2 meters and 4 seconds.
Intervals are sets and have all the properties of sets. However, union
and differences of intervals may not be intervals any more, since the
elements of these union and difference sets might not be
contiguous. Intersections of intervals are always intervals.
template<QTY T>
type Interval<T> alias IVL<T> specializes SET<T> {
T low;
BL lowClosed;
T high;
BL highClosed;
QTY width;
T center;
IVL<T> hull(IVL<T> x);
literal ST;
promotion IVL<T> (T x);
demotion T;
};
A set of consecutive values of an ordered base data type.
Any ordered type can be the basis of an interval; it does not matter
whether the base type is discrete or continuous. If the base data type
is only partially ordered, all elements of the interval must be
elements of a totally ordered subset of the partially ordered data
type.
For example, physical quantities are considered ordered. However the
ordering of physical quantities is only partial; a total order is only
defined among comparable quantities (quantities of the same physical
dimension.) While intervals between 2 and 4 meter exists, there is no
interval between 2 meters and 4 seconds.
Intervals are sets and have all the properties of sets. However, union
and differences of intervals may not be intervals any more, since the
elements of these union and difference sets might not be
contiguous. Intersections of intervals are always intervals.
template<QTY T>
type Interval<T> alias IVL<T> specializes SET<T> {
T low;
BL lowClosed;
T high;
BL highClosed;
QTY width;
T center;
IVL<T> hull(IVL<T> x);
literal ST;
promotion IVL<T> (T x);
demotion T;
};
A set of consecutive values of an ordered base data type.
Any ordered type can be the basis of an interval; it does not matter
whether the base type is discrete or continuous. If the base data type
is only partially ordered, all elements of the interval must be
elements of a totally ordered subset of the partially ordered data
type.
For example, physical quantities are considered ordered. However the
ordering of physical quantities is only partial; a total order is only
defined among comparable quantities (quantities of the same physical
dimension.) While intervals between 2 and 4 meter exists, there is no
interval between 2 meters and 4 seconds.
Intervals are sets and have all the properties of sets. However, union
and differences of intervals may not be intervals any more, since the
elements of these union and difference sets might not be
contiguous. Intersections of intervals are always intervals.
template<QTY T>
type Interval<T> alias IVL<T> specializes SET<T> {
T low;
BL lowClosed;
T high;
BL highClosed;
QTY width;
T center;
IVL<T> hull(IVL<T> x);
literal ST;
promotion IVL<T> (T x);
demotion T;
};
A set of consecutive values of an ordered base data type.
Any ordered type can be the basis of an interval; it does not matter
whether the base type is discrete or continuous. If the base data type
is only partially ordered, all elements of the interval must be
elements of a totally ordered subset of the partially ordered data
type.
For example, physical quantities are considered ordered. However the
ordering of physical quantities is only partial; a total order is only
defined among comparable quantities (quantities of the same physical
dimension.) While intervals between 2 and 4 meter exists, there is no
interval between 2 meters and 4 seconds.
Intervals are sets and have all the properties of sets. However, union
and differences of intervals may not be intervals any more, since the
elements of these union and difference sets might not be
contiguous. Intersections of intervals are always intervals.
template<QTY T>
type Interval<T> alias IVL<T> specializes SET<T> {
T low;
BL lowClosed;
T high;
BL highClosed;
QTY width;
T center;
IVL<T> hull(IVL<T> x);
literal ST;
promotion IVL<T> (T x);
demotion T;
};
A set of consecutive values of an ordered base data type.
Any ordered type can be the basis of an interval; it does not matter
whether the base type is discrete or continuous. If the base data type
is only partially ordered, all elements of the interval must be
elements of a totally ordered subset of the partially ordered data
type.
For example, physical quantities are considered ordered. However the
ordering of physical quantities is only partial; a total order is only
defined among comparable quantities (quantities of the same physical
dimension.) While intervals between 2 and 4 meter exists, there is no
interval between 2 meters and 4 seconds.
Intervals are sets and have all the properties of sets. However, union
and differences of intervals may not be intervals any more, since the
elements of these union and difference sets might not be
contiguous. Intersections of intervals are always intervals.
template<QTY T>
type Interval<T> alias IVL<T> specializes SET<T> {
T low;
BL lowClosed;
T high;
BL highClosed;
QTY width;
T center;
IVL<T> hull(IVL<T> x);
literal ST;
promotion IVL<T> (T x);
demotion T;
};
A set of consecutive values of an ordered base data type.
Any ordered type can be the basis of an interval; it does not matter
whether the base type is discrete or continuous. If the base data type
is only partially ordered, all elements of the interval must be
elements of a totally ordered subset of the partially ordered data
type.
For example, physical quantities are considered ordered. However the
ordering of physical quantities is only partial; a total order is only
defined among comparable quantities (quantities of the same physical
dimension.) While intervals between 2 and 4 meter exists, there is no
interval between 2 meters and 4 seconds.
Intervals are sets and have all the properties of sets. However, union
and differences of intervals may not be intervals any more, since the
elements of these union and difference sets might not be
contiguous. Intersections of intervals are always intervals.
template<QTY T>
type Interval<T> alias IVL<T> specializes SET<T> {
T low;
BL lowClosed;
T high;
BL highClosed;
QTY width;
T center;
IVL<T> hull(IVL<T> x);
literal ST;
promotion IVL<T> (T x);
demotion T;
};
A set of consecutive values of an ordered base data type.
Any ordered type can be the basis of an interval; it does not matter
whether the base type is discrete or continuous. If the base data type
is only partially ordered, all elements of the interval must be
elements of a totally ordered subset of the partially ordered data
type.
For example, physical quantities are considered ordered. However the
ordering of physical quantities is only partial; a total order is only
defined among comparable quantities (quantities of the same physical
dimension.) While intervals between 2 and 4 meter exists, there is no
interval between 2 meters and 4 seconds.
Intervals are sets and have all the properties of sets. However, union
and differences of intervals may not be intervals any more, since the
elements of these union and difference sets might not be
contiguous. Intersections of intervals are always intervals.
template<QTY T>
type Interval<T> alias IVL<T> specializes SET<T> {
T low;
BL lowClosed;
T high;
BL highClosed;
QTY width;
T center;
IVL<T> hull(IVL<T> x);
literal ST;
promotion IVL<T> (T x);
demotion T;
};
A set of consecutive values of an ordered base data type.
Any ordered type can be the basis of an interval; it does not matter
whether the base type is discrete or continuous. If the base data type
is only partially ordered, all elements of the interval must be
elements of a totally ordered subset of the partially ordered data
type.
For example, physical quantities are considered ordered. However the
ordering of physical quantities is only partial; a total order is only
defined among comparable quantities (quantities of the same physical
dimension.) While intervals between 2 and 4 meter exists, there is no
interval between 2 meters and 4 seconds.
Intervals are sets and have all the properties of sets. However, union
and differences of intervals may not be intervals any more, since the
elements of these union and difference sets might not be
contiguous. Intersections of intervals are always intervals.
template<QTY T>
type Interval<T> alias IVL<T> specializes SET<T> {
T low;
BL lowClosed;
T high;
BL highClosed;
QTY width;
T center;
IVL<T> hull(IVL<T> x);
literal ST;
promotion IVL<T> (T x);
demotion T;
};
IVL_PQ (Interval<PhysicalQuantity>)
A set of consecutive values of physical quantities.
An interval of physical quantities is constructed from the generic
interval type. However, recognizing that the unit can be factored from
the boundaries, we add additional semantics and a separate literal
form. The additional view of an interval of physical quantities is an
interval of real numbers with one unit.
The unit applies to both low and high boundary.
The special literal form is simply an interval of real numbers a space
and the unit.
For example: "[0;5] mmol/L" or "<20 mg/dL" are valid literal forms
of intervals of physical quantities. The generic interval form, e.g.,
"[50 nm; 2 m]" is also allowed.
type Interval<PhysicalQuantity> alias IVL<PQ> specializes IVL<T> {
IVL<REAL> value;
CS unit;
};
A set of consecutive values of physical quantities.
An interval of physical quantities is constructed from the generic
interval type. However, recognizing that the unit can be factored from
the boundaries, we add additional semantics and a separate literal
form. The additional view of an interval of physical quantities is an
interval of real numbers with one unit.
The unit applies to both low and high boundary.
The special literal form is simply an interval of real numbers a space
and the unit.
For example: "[0;5] mmol/L" or "<20 mg/dL" are valid literal forms
of intervals of physical quantities. The generic interval form, e.g.,
"[50 nm; 2 m]" is also allowed.
type Interval<PhysicalQuantity> alias IVL<PQ> specializes IVL<T> {
IVL<REAL> value;
CS unit;
};
A set of consecutive values of physical quantities.
An interval of physical quantities is constructed from the generic
interval type. However, recognizing that the unit can be factored from
the boundaries, we add additional semantics and a separate literal
form. The additional view of an interval of physical quantities is an
interval of real numbers with one unit.
The unit applies to both low and high boundary.
The special literal form is simply an interval of real numbers a space
and the unit.
For example: "[0;5] mmol/L" or "<20 mg/dL" are valid literal forms
of intervals of physical quantities. The generic interval form, e.g.,
"[50 nm; 2 m]" is also allowed.
type Interval<PhysicalQuantity> alias IVL<PQ> specializes IVL<T> {
IVL<REAL> value;
CS unit;
};
IVL_TS (Interval<PointInTime>)
A set of consecutive values of time-stamps.
The generic interval data type defines the interval of points in time
too. However, there are some special considerations about literal
representations and conversions of intervals of point in time, which
are specified in this section.
type Interval<PointInTime> alias IVL<TS> specializes IVL<T> {
promotion IVL<TS> (TS x);
};
A set of consecutive values of time-stamps.
The generic interval data type defines the interval of points in time
too. However, there are some special considerations about literal
representations and conversions of intervals of point in time, which
are specified in this section.
type Interval<PointInTime> alias IVL<TS> specializes IVL<T> {
promotion IVL<TS> (TS x);
};
A set of consecutive values of time-stamps.
The generic interval data type defines the interval of points in time
too. However, there are some special considerations about literal
representations and conversions of intervals of point in time, which
are specified in this section.
type Interval<PointInTime> alias IVL<TS> specializes IVL<T> {
promotion IVL<TS> (TS x);
};
HXIT (HistoryItem)
A generic data type extension that tags a time range to any data value
of any data type. The time range is the time in which the information
represented by the value is (was) valid.
If the base type T does not possess a validTime property, the
adds that property to the base type. If, however,
the base type T does have a valid time property (currently only EN),
that property is mapped to the valid time property of the
.
Note that data types are specifications of abstract properties of
values. This specification does not mandate how these values are
represented in an ITS or implemented in an application. Specifically,
it does not mandate how the represented components are named or
positioned. In addition, the semantic generalization hierarchy may be
different from a class hierarchy chosen for implementation (if the
implementation technology has inheritance.) Keep the distinction
between a type (interface) and an implementation (concrete data
structure, class) in mind. The ITS must contain a mapping of ITS
defined features of any data type to the semantic properties defined
here.
template<ANY T>
protected type HistoryItem<T> alias HXIT<T> specializes T {
IVL<TS> validTime;
};
A generic data type extension that tags a time range to any data value
of any data type. The time range is the time in which the information
represented by the value is (was) valid.
If the base type T does not possess a validTime property, the
adds that property to the base type. If, however,
the base type T does have a valid time property (currently only EN),
that property is mapped to the valid time property of the
.
Note that data types are specifications of abstract properties of
values. This specification does not mandate how these values are
represented in an ITS or implemented in an application. Specifically,
it does not mandate how the represented components are named or
positioned. In addition, the semantic generalization hierarchy may be
different from a class hierarchy chosen for implementation (if the
implementation technology has inheritance.) Keep the distinction
between a type (interface) and an implementation (concrete data
structure, class) in mind. The ITS must contain a mapping of ITS
defined features of any data type to the semantic properties defined
here.
template<ANY T>
protected type HistoryItem<T> alias HXIT<T> specializes T {
IVL<TS> validTime;
};
HIST (History)
A set of data values that have a a valid-time property and thus
conform to the history item (HXIT) type. The history information is
not limited to the past; expected future values can also appear.
The intent of the HIST data type is to capture the true historical
(and future) values of an item, rather than the audit trail of
values any given system has held for the item
template<ANY T>
type History<T> alias HIST<T> specializes SET<HXIT<T>> {
HXIT<T> earliest;
HIST<T> exceptEarliest;
HXIT<T> latest;
HIST<T> exceptLatest;
demotion HXIT<T>;
};
A set of data values that have a a valid-time property and thus
conform to the history item (HXIT) type. The history information is
not limited to the past; expected future values can also appear.
The intent of the HIST data type is to capture the true historical
(and future) values of an item, rather than the audit trail of
values any given system has held for the item
template<ANY T>
type History<T> alias HIST<T> specializes SET<HXIT<T>> {
HXIT<T> earliest;
HIST<T> exceptEarliest;
HXIT<T> latest;
HIST<T> exceptLatest;
demotion HXIT<T>;
};
A set of data values that have a a valid-time property and thus
conform to the history item (HXIT) type. The history information is
not limited to the past; expected future values can also appear.
The intent of the HIST data type is to capture the true historical
(and future) values of an item, rather than the audit trail of
values any given system has held for the item
template<ANY T>
type History<T> alias HIST<T> specializes SET<HXIT<T>> {
HXIT<T> earliest;
HIST<T> exceptEarliest;
HXIT<T> latest;
HIST<T> exceptLatest;
demotion HXIT<T>;
};
A set of data values that have a a valid-time property and thus
conform to the history item (HXIT) type. The history information is
not limited to the past; expected future values can also appear.
The intent of the HIST data type is to capture the true historical
(and future) values of an item, rather than the audit trail of
values any given system has held for the item
template<ANY T>
type History<T> alias HIST<T> specializes SET<HXIT<T>> {
HXIT<T> earliest;
HIST<T> exceptEarliest;
HXIT<T> latest;
HIST<T> exceptLatest;
demotion HXIT<T>;
};
A set of data values that have a a valid-time property and thus
conform to the history item (HXIT) type. The history information is
not limited to the past; expected future values can also appear.
The intent of the HIST data type is to capture the true historical
(and future) values of an item, rather than the audit trail of
values any given system has held for the item
template<ANY T>
type History<T> alias HIST<T> specializes SET<HXIT<T>> {
HXIT<T> earliest;
HIST<T> exceptEarliest;
HXIT<T> latest;
HIST<T> exceptLatest;
demotion HXIT<T>;
};
A set of data values that have a a valid-time property and thus
conform to the history item (HXIT) type. The history information is
not limited to the past; expected future values can also appear.
The intent of the HIST data type is to capture the true historical
(and future) values of an item, rather than the audit trail of
values any given system has held for the item
template<ANY T>
type History<T> alias HIST<T> specializes SET<HXIT<T>> {
HXIT<T> earliest;
HIST<T> exceptEarliest;
HXIT<T> latest;
HIST<T> exceptLatest;
demotion HXIT<T>;
};
UVP (UncertainValueProbabilistic)
A generic data type extension used to specify a probability expressing
the information producer's belief that the given value holds.
How the probability number was arrived at is outside the scope of this
specification.
Probabilities are subjective and (as any data value) must be
interpreted in their individual context, for example, when new
information is found the probability might change. Thus, for any
message (document, or other information representation) the
information - and particularly the probabilities - reflect
what the information producer believed was appropriate for the purpose
and at the time the message (document) was created.
For example, at the beginning of the 2000 baseball season (May), the
Las Vegas odds makers may have given the New York Yankees a
probability of 1 in 10 (0.100) of winning the World Series. At the
time of this writing, the Yankees and Mets have won their respective
pennants, but the World Series has yet to begin. The probability of
the Yankees winning the World Series is obviously significantly
greater at this point in time, perhaps 6 in 10 (0.600). The context,
and in particular the time of year, made all the difference in the
world.
Since probabilities are subjective measures of belief, they can be
stated without being "correct" or "incorrect" per se, let alone
"precise" or "imprecise". Notably, one does not have to conduct
experiments to measure a frequency of some outcome in order to specify
a probability. In fact, whenever statements about individual people or
events are made, it is not possible to confirm such probabilities with
"frequentists" experiments.
Returning to our example, the Las Vegas odds makers can not insist on
the Yankees and Mets playing 1000 trial games prior to the Series;
even if they could, they would not have the fervor of the real Series
and therefore not be accurate. Instead, the odds makers must derive
the probability from past history, player statistics, injuries, etc.
The type T is not formally constrained. In theory, discrete
probabilities can only be stated for discrete data values. Thus,
generally should not be used with ,
, or values.
template<ANY T>
type UncertainValueProbabilistic<T> alias UVP<T> specializes T {
REAL probability;
};
A generic data type extension used to specify a probability expressing
the information producer's belief that the given value holds.
How the probability number was arrived at is outside the scope of this
specification.
Probabilities are subjective and (as any data value) must be
interpreted in their individual context, for example, when new
information is found the probability might change. Thus, for any
message (document, or other information representation) the
information - and particularly the probabilities - reflect
what the information producer believed was appropriate for the purpose
and at the time the message (document) was created.
For example, at the beginning of the 2000 baseball season (May), the
Las Vegas odds makers may have given the New York Yankees a
probability of 1 in 10 (0.100) of winning the World Series. At the
time of this writing, the Yankees and Mets have won their respective
pennants, but the World Series has yet to begin. The probability of
the Yankees winning the World Series is obviously significantly
greater at this point in time, perhaps 6 in 10 (0.600). The context,
and in particular the time of year, made all the difference in the
world.
Since probabilities are subjective measures of belief, they can be
stated without being "correct" or "incorrect" per se, let alone
"precise" or "imprecise". Notably, one does not have to conduct
experiments to measure a frequency of some outcome in order to specify
a probability. In fact, whenever statements about individual people or
events are made, it is not possible to confirm such probabilities with
"frequentists" experiments.
Returning to our example, the Las Vegas odds makers can not insist on
the Yankees and Mets playing 1000 trial games prior to the Series;
even if they could, they would not have the fervor of the real Series
and therefore not be accurate. Instead, the odds makers must derive
the probability from past history, player statistics, injuries, etc.
The type T is not formally constrained. In theory, discrete
probabilities can only be stated for discrete data values. Thus,
generally should not be used with ,
, or values.
template<ANY T>
type UncertainValueProbabilistic<T> alias UVP<T> specializes T {
REAL probability;
};
NPPD (NonParametricProbabilityDistribution)
A set of uncertain values with probabilities (also known as
histogram.) All the elements in the set are considered alternatives
and are rated each with its probability expressing the belief (or
frequency) that each given value holds.
The purpose of the non-parametric probability distribution is chiefly
to support statistical data reporting as it occurs in measurements
taken from many subjects and consolidated in a histogram. This occurs
in epidemiology, veterinary medicine, laboratory medicine, but also in
cost controlling and business process engineering.
Semantically, the information of a stated value exists in contrast to
the complement set of unstated possible values. Thus, semantically, a
non-parametric probability distribution contains all
possible values and assigns probabilities to each of them.
The easiest way to visualize this is a bar chart as shown in
This example illustrates the probability of selected major league
baseball teams winning the World Series (prior to the season
start). Each team is mutually exclusive, and were we to include all of
the teams, the sum of the probabilities would equal 1 (i.e., it is
certain that one of the teams will win).
Just as with , the type T is not formally
constrained, even though there are reasonable and unreasonable
uses. Typically one would use the for unordered types, if
only a "small" set of possible values is assigned explicit
probabilities, or if the probability distribution cannot (or should
not) be approximated with parametric methods. For other cases, one may
prefer .
template<ANY T>
type NonParametricProbabilityDistribution<T> alias NPPD<T>
specializes SET<UVP<T>> {
UVP<T> mostLikely(INT n);
};
A set of uncertain values with probabilities (also known as
histogram.) All the elements in the set are considered alternatives
and are rated each with its probability expressing the belief (or
frequency) that each given value holds.
The purpose of the non-parametric probability distribution is chiefly
to support statistical data reporting as it occurs in measurements
taken from many subjects and consolidated in a histogram. This occurs
in epidemiology, veterinary medicine, laboratory medicine, but also in
cost controlling and business process engineering.
Semantically, the information of a stated value exists in contrast to
the complement set of unstated possible values. Thus, semantically, a
non-parametric probability distribution contains all
possible values and assigns probabilities to each of them.
The easiest way to visualize this is a bar chart as shown in
This example illustrates the probability of selected major league
baseball teams winning the World Series (prior to the season
start). Each team is mutually exclusive, and were we to include all of
the teams, the sum of the probabilities would equal 1 (i.e., it is
certain that one of the teams will win).
Just as with , the type T is not formally
constrained, even though there are reasonable and unreasonable
uses. Typically one would use the for unordered types, if
only a "small" set of possible values is assigned explicit
probabilities, or if the probability distribution cannot (or should
not) be approximated with parametric methods. For other cases, one may
prefer .
template<ANY T>
type NonParametricProbabilityDistribution<T> alias NPPD<T>
specializes SET<UVP<T>> {
UVP<T> mostLikely(INT n);
};
PIVL (PeriodicIntervalOfTime)
An interval of time that recurs periodically. Periodic intervals have
two properties, phase and period. The phase specifies the "interval
prototype" that is repeated every period.
For example, "every eight hours for two minutes" is a periodic
interval where the interval's width equals 2 minutes and the period
at which the interval recurs equals 8 hours.
The phase also marks the anchor point in time for the entire series of
periodically recurring intervals. The recurrence of a periodic interval has no
beginning or ending, but is infinite in both future and past.
A periodic interval is fully specified when both the period and the
phase are fully specified. The interval may be only partially
specified where either only the width or only one boundary is
specified.
For example: "every eight hours for two minutes" specifies only the
period and the phase's width but no boundary of the phase. Conversely,
"every eight hours starting at 4 o'clock" specifies only the period
and the phase's low boundary but not the phase's high boundary. "Every
eight hours for two minutes starting at 4 o'clock" is fully specified
since the period, and both the phase's low boundary and width are
specified (low boundary and width implies the high boundary.)
The periodic interval of time is a generic type extension whose type
parameter T is restricted to the point in time ( )
data type and its extensions. The parametric probability distribution
of point in time ( < >) is
an extension of point in time and therefore can be used to form
periodic intervals of probability distributions of point in time
( <
< >>) values (uncertain periodic interval.)
Oftentimes repeating schedules are only approximately specified. For
instance "three times a day for ten minutes each" does not usually
mean a period of precisely 8 hours and does often not mean exactly 10
minutes intervals. Rather the distance between each occurrence may
vary as much as between 3 and 12 hours and the width of the interval
may be less than 5 minutes or more than 15 minutes. An uncertain
periodic interval can be used to indicate how much leeway is allowed
or how "timing-critical" the specification is.
The essential property of a set is that it contains elements. For
non-aligned periodic intervals, the contains-property is
defined as follows. A point in time t is contained in the
periodic interval of time if and only if there is an integer
i for which t plus the period times
i is an element of the phase interval.
invariant (PIVL<TS> x, TS t)
where x.nonNull.and(x.alignment.isNull) {
x.contains(t).equal(exists(INT i) {
x.phase.contains(t.plus(x.period.times(i)));
});
};
For calendar-aligned periodic intervals the contains
property is defined using the calendar-cycle's sum(t,
n) property that adds n such calendar cycles
to the time t.
invariant (PIVL<TS> x, TS t, CalendarCycle c)
where x.nonNull.and(c.equal(x.alignment)) {
x.contains(t).equal(exists(INT i) {
x.phase.contains(c.sum(t, i));
});
};
template<TS T>
type PeriodicIntervalOfTime<T> alias PIVL<T> specializes SET<T> {
IVL<T> phase;
PQ period;
CS alignment;
BL institutionSpecifiedTime;
literal ST;
};
An interval of time that recurs periodically. Periodic intervals have
two properties, phase and period. The phase specifies the "interval
prototype" that is repeated every period.
For example, "every eight hours for two minutes" is a periodic
interval where the interval's width equals 2 minutes and the period
at which the interval recurs equals 8 hours.
The phase also marks the anchor point in time for the entire series of
periodically recurring intervals. The recurrence of a periodic interval has no
beginning or ending, but is infinite in both future and past.
A periodic interval is fully specified when both the period and the
phase are fully specified. The interval may be only partially
specified where either only the width or only one boundary is
specified.
For example: "every eight hours for two minutes" specifies only the
period and the phase's width but no boundary of the phase. Conversely,
"every eight hours starting at 4 o'clock" specifies only the period
and the phase's low boundary but not the phase's high boundary. "Every
eight hours for two minutes starting at 4 o'clock" is fully specified
since the period, and both the phase's low boundary and width are
specified (low boundary and width implies the high boundary.)
The periodic interval of time is a generic type extension whose type
parameter T is restricted to the point in time ( )
data type and its extensions. The parametric probability distribution
of point in time ( < >) is
an extension of point in time and therefore can be used to form
periodic intervals of probability distributions of point in time
( <
< >>) values (uncertain periodic interval.)
Oftentimes repeating schedules are only approximately specified. For
instance "three times a day for ten minutes each" does not usually
mean a period of precisely 8 hours and does often not mean exactly 10
minutes intervals. Rather the distance between each occurrence may
vary as much as between 3 and 12 hours and the width of the interval
may be less than 5 minutes or more than 15 minutes. An uncertain
periodic interval can be used to indicate how much leeway is allowed
or how "timing-critical" the specification is.
The essential property of a set is that it contains elements. For
non-aligned periodic intervals, the contains-property is
defined as follows. A point in time t is contained in the
periodic interval of time if and only if there is an integer
i for which t plus the period times
i is an element of the phase interval.
invariant (PIVL<TS> x, TS t)
where x.nonNull.and(x.alignment.isNull) {
x.contains(t).equal(exists(INT i) {
x.phase.contains(t.plus(x.period.times(i)));
});
};
For calendar-aligned periodic intervals the contains
property is defined using the calendar-cycle's sum(t,
n) property that adds n such calendar cycles
to the time t.
invariant (PIVL<TS> x, TS t, CalendarCycle c)
where x.nonNull.and(c.equal(x.alignment)) {
x.contains(t).equal(exists(INT i) {
x.phase.contains(c.sum(t, i));
});
};
template<TS T>
type PeriodicIntervalOfTime<T> alias PIVL<T> specializes SET<T> {
IVL<T> phase;
PQ period;
CS alignment;
BL institutionSpecifiedTime;
literal ST;
};
An interval of time that recurs periodically. Periodic intervals have
two properties, phase and period. The phase specifies the "interval
prototype" that is repeated every period.
For example, "every eight hours for two minutes" is a periodic
interval where the interval's width equals 2 minutes and the period
at which the interval recurs equals 8 hours.
The phase also marks the anchor point in time for the entire series of
periodically recurring intervals. The recurrence of a periodic interval has no
beginning or ending, but is infinite in both future and past.
A periodic interval is fully specified when both the period and the
phase are fully specified. The interval may be only partially
specified where either only the width or only one boundary is
specified.
For example: "every eight hours for two minutes" specifies only the
period and the phase's width but no boundary of the phase. Conversely,
"every eight hours starting at 4 o'clock" specifies only the period
and the phase's low boundary but not the phase's high boundary. "Every
eight hours for two minutes starting at 4 o'clock" is fully specified
since the period, and both the phase's low boundary and width are
specified (low boundary and width implies the high boundary.)
The periodic interval of time is a generic type extension whose type
parameter T is restricted to the point in time ( )
data type and its extensions. The parametric probability distribution
of point in time ( < >) is
an extension of point in time and therefore can be used to form
periodic intervals of probability distributions of point in time
( <
< >>) values (uncertain periodic interval.)
Oftentimes repeating schedules are only approximately specified. For
instance "three times a day for ten minutes each" does not usually
mean a period of precisely 8 hours and does often not mean exactly 10
minutes intervals. Rather the distance between each occurrence may
vary as much as between 3 and 12 hours and the width of the interval
may be less than 5 minutes or more than 15 minutes. An uncertain
periodic interval can be used to indicate how much leeway is allowed
or how "timing-critical" the specification is.
The essential property of a set is that it contains elements. For
non-aligned periodic intervals, the contains-property is
defined as follows. A point in time t is contained in the
periodic interval of time if and only if there is an integer
i for which t plus the period times
i is an element of the phase interval.
invariant (PIVL<TS> x, TS t)
where x.nonNull.and(x.alignment.isNull) {
x.contains(t).equal(exists(INT i) {
x.phase.contains(t.plus(x.period.times(i)));
});
};
For calendar-aligned periodic intervals the contains
property is defined using the calendar-cycle's sum(t,
n) property that adds n such calendar cycles
to the time t.
invariant (PIVL<TS> x, TS t, CalendarCycle c)
where x.nonNull.and(c.equal(x.alignment)) {
x.contains(t).equal(exists(INT i) {
x.phase.contains(c.sum(t, i));
});
};
template<TS T>
type PeriodicIntervalOfTime<T> alias PIVL<T> specializes SET<T> {
IVL<T> phase;
PQ period;
CS alignment;
BL institutionSpecifiedTime;
literal ST;
};
An interval of time that recurs periodically. Periodic intervals have
two properties, phase and period. The phase specifies the "interval
prototype" that is repeated every period.
For example, "every eight hours for two minutes" is a periodic
interval where the interval's width equals 2 minutes and the period
at which the interval recurs equals 8 hours.
The phase also marks the anchor point in time for the entire series of
periodically recurring intervals. The recurrence of a periodic interval has no
beginning or ending, but is infinite in both future and past.
A periodic interval is fully specified when both the period and the
phase are fully specified. The interval may be only partially
specified where either only the width or only one boundary is
specified.
For example: "every eight hours for two minutes" specifies only the
period and the phase's width but no boundary of the phase. Conversely,
"every eight hours starting at 4 o'clock" specifies only the period
and the phase's low boundary but not the phase's high boundary. "Every
eight hours for two minutes starting at 4 o'clock" is fully specified
since the period, and both the phase's low boundary and width are
specified (low boundary and width implies the high boundary.)
The periodic interval of time is a generic type extension whose type
parameter T is restricted to the point in time ( )
data type and its extensions. The parametric probability distribution
of point in time ( < >) is
an extension of point in time and therefore can be used to form
periodic intervals of probability distributions of point in time
( <
< >>) values (uncertain periodic interval.)
Oftentimes repeating schedules are only approximately specified. For
instance "three times a day for ten minutes each" does not usually
mean a period of precisely 8 hours and does often not mean exactly 10
minutes intervals. Rather the distance between each occurrence may
vary as much as between 3 and 12 hours and the width of the interval
may be less than 5 minutes or more than 15 minutes. An uncertain
periodic interval can be used to indicate how much leeway is allowed
or how "timing-critical" the specification is.
The essential property of a set is that it contains elements. For
non-aligned periodic intervals, the contains-property is
defined as follows. A point in time t is contained in the
periodic interval of time if and only if there is an integer
i for which t plus the period times
i is an element of the phase interval.
invariant (PIVL<TS> x, TS t)
where x.nonNull.and(x.alignment.isNull) {
x.contains(t).equal(exists(INT i) {
x.phase.contains(t.plus(x.period.times(i)));
});
};
For calendar-aligned periodic intervals the contains
property is defined using the calendar-cycle's sum(t,
n) property that adds n such calendar cycles
to the time t.
invariant (PIVL<TS> x, TS t, CalendarCycle c)
where x.nonNull.and(c.equal(x.alignment)) {
x.contains(t).equal(exists(INT i) {
x.phase.contains(c.sum(t, i));
});
};
template<TS T>
type PeriodicIntervalOfTime<T> alias PIVL<T> specializes SET<T> {
IVL<T> phase;
PQ period;
CS alignment;
BL institutionSpecifiedTime;
literal ST;
};
An interval of time that recurs periodically. Periodic intervals have
two properties, phase and period. The phase specifies the "interval
prototype" that is repeated every period.
For example, "every eight hours for two minutes" is a periodic
interval where the interval's width equals 2 minutes and the period
at which the interval recurs equals 8 hours.
The phase also marks the anchor point in time for the entire series of
periodically recurring intervals. The recurrence of a periodic interval has no
beginning or ending, but is infinite in both future and past.
A periodic interval is fully specified when both the period and the
phase are fully specified. The interval may be only partially
specified where either only the width or only one boundary is
specified.
For example: "every eight hours for two minutes" specifies only the
period and the phase's width but no boundary of the phase. Conversely,
"every eight hours starting at 4 o'clock" specifies only the period
and the phase's low boundary but not the phase's high boundary. "Every
eight hours for two minutes starting at 4 o'clock" is fully specified
since the period, and both the phase's low boundary and width are
specified (low boundary and width implies the high boundary.)
The periodic interval of time is a generic type extension whose type
parameter T is restricted to the point in time ( )
data type and its extensions. The parametric probability distribution
of point in time ( < >) is
an extension of point in time and therefore can be used to form
periodic intervals of probability distributions of point in time
( <
< >>) values (uncertain periodic interval.)
Oftentimes repeating schedules are only approximately specified. For
instance "three times a day for ten minutes each" does not usually
mean a period of precisely 8 hours and does often not mean exactly 10
minutes intervals. Rather the distance between each occurrence may
vary as much as between 3 and 12 hours and the width of the interval
may be less than 5 minutes or more than 15 minutes. An uncertain
periodic interval can be used to indicate how much leeway is allowed
or how "timing-critical" the specification is.
The essential property of a set is that it contains elements. For
non-aligned periodic intervals, the contains-property is
defined as follows. A point in time t is contained in the
periodic interval of time if and only if there is an integer
i for which t plus the period times
i is an element of the phase interval.
invariant (PIVL<TS> x, TS t)
where x.nonNull.and(x.alignment.isNull) {
x.contains(t).equal(exists(INT i) {
x.phase.contains(t.plus(x.period.times(i)));
});
};
For calendar-aligned periodic intervals the contains
property is defined using the calendar-cycle's sum(t,
n) property that adds n such calendar cycles
to the time t.
invariant (PIVL<TS> x, TS t, CalendarCycle c)
where x.nonNull.and(c.equal(x.alignment)) {
x.contains(t).equal(exists(INT i) {
x.phase.contains(c.sum(t, i));
});
};
template<TS T>
type PeriodicIntervalOfTime<T> alias PIVL<T> specializes SET<T> {
IVL<T> phase;
PQ period;
CS alignment;
BL institutionSpecifiedTime;
literal ST;
};
An interval of time that recurs periodically. Periodic intervals have
two properties, phase and period. The phase specifies the "interval
prototype" that is repeated every period.
For example, "every eight hours for two minutes" is a periodic
interval where the interval's width equals 2 minutes and the period
at which the interval recurs equals 8 hours.
The phase also marks the anchor point in time for the entire series of
periodically recurring intervals. The recurrence of a periodic interval has no
beginning or ending, but is infinite in both future and past.
A periodic interval is fully specified when both the period and the
phase are fully specified. The interval may be only partially
specified where either only the width or only one boundary is
specified.
For example: "every eight hours for two minutes" specifies only the
period and the phase's width but no boundary of the phase. Conversely,
"every eight hours starting at 4 o'clock" specifies only the period
and the phase's low boundary but not the phase's high boundary. "Every
eight hours for two minutes starting at 4 o'clock" is fully specified
since the period, and both the phase's low boundary and width are
specified (low boundary and width implies the high boundary.)
The periodic interval of time is a generic type extension whose type
parameter T is restricted to the point in time ( )
data type and its extensions. The parametric probability distribution
of point in time ( < >) is
an extension of point in time and therefore can be used to form
periodic intervals of probability distributions of point in time
( <
< >>) values (uncertain periodic interval.)
Oftentimes repeating schedules are only approximately specified. For
instance "three times a day for ten minutes each" does not usually
mean a period of precisely 8 hours and does often not mean exactly 10
minutes intervals. Rather the distance between each occurrence may
vary as much as between 3 and 12 hours and the width of the interval
may be less than 5 minutes or more than 15 minutes. An uncertain
periodic interval can be used to indicate how much leeway is allowed
or how "timing-critical" the specification is.
The essential property of a set is that it contains elements. For
non-aligned periodic intervals, the contains-property is
defined as follows. A point in time t is contained in the
periodic interval of time if and only if there is an integer
i for which t plus the period times
i is an element of the phase interval.
invariant (PIVL<TS> x, TS t)
where x.nonNull.and(x.alignment.isNull) {
x.contains(t).equal(exists(INT i) {
x.phase.contains(t.plus(x.period.times(i)));
});
};
For calendar-aligned periodic intervals the contains
property is defined using the calendar-cycle's sum(t,
n) property that adds n such calendar cycles
to the time t.
invariant (PIVL<TS> x, TS t, CalendarCycle c)
where x.nonNull.and(c.equal(x.alignment)) {
x.contains(t).equal(exists(INT i) {
x.phase.contains(c.sum(t, i));
});
};
template<TS T>
type PeriodicIntervalOfTime<T> alias PIVL<T> specializes SET<T> {
IVL<T> phase;
PQ period;
CS alignment;
BL institutionSpecifiedTime;
literal ST;
};
EIVL (EventRelatedPeriodicInterval)
Specifies a periodic interval of time where the recurrence is based on
activities of daily living or other important events that are
time-related but not fully determined by time.
For example, "one hour after breakfast" specifies the beginning of the
interval at one hour after breakfast is finished. Breakfast is assumed
to occur before lunch but is not determined to occur at any specific
time.
An event-related periodic interval of time is a set of time, that is,
one can test whether a particular time or time interval is an element
of the set. Whether an event-related periodic interval of time
contains a given interval of time is decided using a relation event
? time referred to as EVENT(event,
time). The property occurrenceAt(t) is the
occurrence interval that would exist if the event occurred at time
t.
invariant(EIVL<T> x, T eventTime, IVL<T> v)
where v.equal(x.occurrenceAt(eventTime)) {
v.low.equal(eventTime.plus(x.offset.low));
v.high.equal(eventTime.plus(x.offset.high));
v.lowClosed.equal(x.offset.lowClosed);
v.highClosed.equal(x.offset.highClosed);
};
Thus, an event related interval of time contains a point in time
t if there is an event time e with an
occurrence interval v such that v contains
t.
invariant(EIVL<T> x, T y) {
x.contains(y).equal(exists(T e, IVL<T> v)
where EVENT(x.event, y)
.and(v.resolvedAt(y)) {
v.contains(y);
});
};
template<TS T>
type EventRelatedPeriodicInterval<T> alias EIVL<T>
specializes SET<T> {
CS event;
IVL<PQ> offset;
IVL<T> occurrenceAt(TS eventTime);
literal ST;
};
Specifies a periodic interval of time where the recurrence is based on
activities of daily living or other important events that are
time-related but not fully determined by time.
For example, "one hour after breakfast" specifies the beginning of the
interval at one hour after breakfast is finished. Breakfast is assumed
to occur before lunch but is not determined to occur at any specific
time.
An event-related periodic interval of time is a set of time, that is,
one can test whether a particular time or time interval is an element
of the set. Whether an event-related periodic interval of time
contains a given interval of time is decided using a relation event
? time referred to as EVENT(event,
time). The property occurrenceAt(t) is the
occurrence interval that would exist if the event occurred at time
t.
invariant(EIVL<T> x, T eventTime, IVL<T> v)
where v.equal(x.occurrenceAt(eventTime)) {
v.low.equal(eventTime.plus(x.offset.low));
v.high.equal(eventTime.plus(x.offset.high));
v.lowClosed.equal(x.offset.lowClosed);
v.highClosed.equal(x.offset.highClosed);
};
Thus, an event related interval of time contains a point in time
t if there is an event time e with an
occurrence interval v such that v contains
t.
invariant(EIVL<T> x, T y) {
x.contains(y).equal(exists(T e, IVL<T> v)
where EVENT(x.event, y)
.and(v.resolvedAt(y)) {
v.contains(y);
});
};
template<TS T>
type EventRelatedPeriodicInterval<T> alias EIVL<T>
specializes SET<T> {
CS event;
IVL<PQ> offset;
IVL<T> occurrenceAt(TS eventTime);
literal ST;
};
Specifies a periodic interval of time where the recurrence is based on
activities of daily living or other important events that are
time-related but not fully determined by time.
For example, "one hour after breakfast" specifies the beginning of the
interval at one hour after breakfast is finished. Breakfast is assumed
to occur before lunch but is not determined to occur at any specific
time.
An event-related periodic interval of time is a set of time, that is,
one can test whether a particular time or time interval is an element
of the set. Whether an event-related periodic interval of time
contains a given interval of time is decided using a relation event
? time referred to as EVENT(event,
time). The property occurrenceAt(t) is the
occurrence interval that would exist if the event occurred at time
t.
invariant(EIVL<T> x, T eventTime, IVL<T> v)
where v.equal(x.occurrenceAt(eventTime)) {
v.low.equal(eventTime.plus(x.offset.low));
v.high.equal(eventTime.plus(x.offset.high));
v.lowClosed.equal(x.offset.lowClosed);
v.highClosed.equal(x.offset.highClosed);
};
Thus, an event related interval of time contains a point in time
t if there is an event time e with an
occurrence interval v such that v contains
t.
invariant(EIVL<T> x, T y) {
x.contains(y).equal(exists(T e, IVL<T> v)
where EVENT(x.event, y)
.and(v.resolvedAt(y)) {
v.contains(y);
});
};
template<TS T>
type EventRelatedPeriodicInterval<T> alias EIVL<T>
specializes SET<T> {
CS event;
IVL<PQ> offset;
IVL<T> occurrenceAt(TS eventTime);
literal ST;
};
Specifies a periodic interval of time where the recurrence is based on
activities of daily living or other important events that are
time-related but not fully determined by time.
For example, "one hour after breakfast" specifies the beginning of the
interval at one hour after breakfast is finished. Breakfast is assumed
to occur before lunch but is not determined to occur at any specific
time.
An event-related periodic interval of time is a set of time, that is,
one can test whether a particular time or time interval is an element
of the set. Whether an event-related periodic interval of time
contains a given interval of time is decided using a relation event
? time referred to as EVENT(event,
time). The property occurrenceAt(t) is the
occurrence interval that would exist if the event occurred at time
t.
invariant(EIVL<T> x, T eventTime, IVL<T> v)
where v.equal(x.occurrenceAt(eventTime)) {
v.low.equal(eventTime.plus(x.offset.low));
v.high.equal(eventTime.plus(x.offset.high));
v.lowClosed.equal(x.offset.lowClosed);
v.highClosed.equal(x.offset.highClosed);
};
Thus, an event related interval of time contains a point in time
t if there is an event time e with an
occurrence interval v such that v contains
t.
invariant(EIVL<T> x, T y) {
x.contains(y).equal(exists(T e, IVL<T> v)
where EVENT(x.event, y)
.and(v.resolvedAt(y)) {
v.contains(y);
});
};
template<TS T>
type EventRelatedPeriodicInterval<T> alias EIVL<T>
specializes SET<T> {
CS event;
IVL<PQ> offset;
IVL<T> occurrenceAt(TS eventTime);
literal ST;
};
Specifies a periodic interval of time where the recurrence is based on
activities of daily living or other important events that are
time-related but not fully determined by time.
For example, "one hour after breakfast" specifies the beginning of the
interval at one hour after breakfast is finished. Breakfast is assumed
to occur before lunch but is not determined to occur at any specific
time.
An event-related periodic interval of time is a set of time, that is,
one can test whether a particular time or time interval is an element
of the set. Whether an event-related periodic interval of time
contains a given interval of time is decided using a relation event
? time referred to as EVENT(event,
time). The property occurrenceAt(t) is the
occurrence interval that would exist if the event occurred at time
t.
invariant(EIVL<T> x, T eventTime, IVL<T> v)
where v.equal(x.occurrenceAt(eventTime)) {
v.low.equal(eventTime.plus(x.offset.low));
v.high.equal(eventTime.plus(x.offset.high));
v.lowClosed.equal(x.offset.lowClosed);
v.highClosed.equal(x.offset.highClosed);
};
Thus, an event related interval of time contains a point in time
t if there is an event time e with an
occurrence interval v such that v contains
t.
invariant(EIVL<T> x, T y) {
x.contains(y).equal(exists(T e, IVL<T> v)
where EVENT(x.event, y)
.and(v.resolvedAt(y)) {
v.contains(y);
});
};
template<TS T>
type EventRelatedPeriodicInterval<T> alias EIVL<T>
specializes SET<T> {
CS event;
IVL<PQ> offset;
IVL<T> occurrenceAt(TS eventTime);
literal ST;
};
GTS (GeneralTimingSpecification)
A set of points in time, specifying the timing of events and actions
and the cyclical validity-patterns that may exist for certain kinds of
information, such as phone numbers (evening, daytime), addresses (so
called "snowbirds," residing closer to the equator during winter and
farther from the equator during summer) and office hours.
The GTS data type has the following aspects:
GTS as a general set of points in time (
< >). From this aspect GTS answers
whether any given point in time falls in the schedule described by the
GTS value.
GTS as the combination of multiple periodic intervals of time. This
aspect describes how both simple and complex repeat-patterns are
specified with the GTS.
GTS as a generator of a sequence of intervals of point in time
( <
< >>).
From this aspect, GTS can generate all occurrence intervals of an event or
action, or all validity periods for a fact.
GTS as an expression-syntax defined for a calendar. This aspect is the
GTS literal form.
In all cases the GTS is defined as a set of point in time (
< >). Using the set operations,
union, intersection and difference, more complex sets of time can be
constructed from simpler ones. Ultimately the building blocks from
which all GTS values are constructed are interval, periodic interval,
and event-related periodic interval. The construction of the GTS can
be specified in the literal form. No special data type structure is
defined that would generate a combination of simpler time-sets from a
given GTS value. While any implementation would have to contain such a
structured representation, it is not needed in order to exchange GTS
values given the literal form.
The GTS is an example of a data type that is only defined
algebraically without giving any definition of a data structure that
might implement the behavior of such a data type. The algebraic
definition looks extremely simple, so that one might assume it is
incomplete. Since at this point we are relying entirely on the literal
form to represent GTS values, all the definition of data structur
The GTS data type is defined as using intervals, periodic intervals,
and event-related periodic intervals. Intervals of time have been
defined above
A convex hull is the least interval that is a superset of all
occurrence intervals. As noted in , all
totally ordered sets have a convex hull. Because a GTS is a
<> and because a
<> is a totally ordered set, all
GTS values have a convex hull.
The convex hull of a GTS can less formally be called "outer bound
interval". Thus, the convex hull of a GTS describes the absolute
beginning and end of the repeating schedule. For infinite repetitions
(e.g., a simple periodic interval) the convex hull has infinite
bounds.
Convex Hull of a Schedule
A value is a generator of a sequence of time
intervals during which an event or activity occurs, or during which a
state is effective.
The nextTo-property maps to every point in
time t the greatest continuous subset (an "occurrence
interval") v of the value
S, where v is the interval closest to
t that begins later than t or that contains
t.
invariant(GTS S, TS t, IVL<TS> v) {
v.equal(S.nextTo(t)).equal(
S.contains(o)
.and(forall(IVL<TS> u) where x.contains(u) {
u.contains(v).implies(u.equal(v)); })
.and( v.contains(t)
.or(forall(TS i) where t.lessOrEqual(i)
.and(i.lessThan(v.low)) {
S.conatins(i).not; })));
};
The nextAfter-property maps to every point
in time t the greatest continuous subset (an "occurrence
interval") v of the value
S, where v is the interval closest to
t that begins later than t.
invariant(GTS S, TS t) where {
S.contains(t).not
.implies(S.nextAfter(t).equal(S.nextTo(t)));
S.contains(t)
.implies(S.nextAfter(t).equal(
S.except(nextTo(t)).nextTo(t)));
};
A value can be converted into a generic Sequence
of time intervals (<>)
of occurrence intervals.
invariant(GTS x) where x.isEmpty { ((LIST<IVL<TS>>)x).isEmpty; };
invariant(GTS x, IVL<TS> first)
where x.notEmpty
.and(x.hull.low.nonNull)
.and(first.equal(x.nextTo(x.hull.low))
{
((LIST<IVL<TS>>)x).head.equal(first);
((LIST<IVL<TS>>)x).tail.equal(
(LIST<IVL<TS>>)x.except(first));
};
Interleaving Schedules and Periodic Hull
For two values A and B we
say that A interleaves B if their occurrence
intervals interleave on the time line. This concept is visualized in
Figure 15.
For the values A and B
to interleave the occurrence intervals of both groups can be arranged
in pairs of corresponding occurrence intervals. It must further hold
that for all corresponding occurrence intervals a
? A and b ? B,
a starts before b starts (or at the same
time) and b ends after a ends (or at the
same time).
The interleaves-relation holds when two schedules have the same
average frequency, and when the second schedule never "outpaces" the
first schedule. That is, no occurrence interval in the second schedule
may start before its corresponding occurrence interval in the first
schedule.
With two interleaving values one can derive a
periodic hull such that the occurrence intervals of the periodic hull
is the convex hull of the corresponding occurrence intervals.
The periodic hull is important to construct two schedules by combining
expressions. For example, to construct the periodic
interval from Memorial Day to Labor Day every year, one first needs to
set up the schedules M for Memorial Day (the last Monday
in May) and L for Labor Day (the first Monday in
September) and then combine these two schedules using the periodic
hull of M and L.
invariant(GTS A, B) where x.nonNull.and(y.nonNull) {
A.interleaves(B).equal(
forall(IVL<TS> a, b, c; TS t)
where a.equal(A.nextTo(t))
.and(b.equal(B.nextTo(a.low)))
.and(c.equal(A.nextTo(b.high))) {
b.equal(B.nextTo(a.high));
a.low.lessOrEqual(b.low);
c.equal(A.nextTo(b.high));
c.equal(a).or(c.equal(A.nextAfter(a.high)));
});
};
For two values A and B
where A interleaves B, a periodic hull is
defined as the pair wise convex hull of the corresponding occurrence
intervals of A and B.
invariant(GTS A, B, C) where A.interleaves(B) {
A.periodicHull(B).equal(C).equal(
forall(IVL<TS> a, b; TS t)
where a.equal(A.nextTo(t))
.and(b.equal(B.nextTo(a.low))) {
C.contains(c).equal(c.equal(a.hull(b)));
});
};
The interleaves-relation is reflexive, asymmetric, and
intransitive. The periodic hull operation is non-commutative and
non-associative.
The interleaves property may appear overly constrained. However, these
constraints are reasonable for the use case for which the interleaves
and periodic hull properties are defined. To safely and predictably
combine two schedules one would want to know which of the operands
sets the start points and which sets the endpoints of the periodic
hull's occurrence intervals.
type GeneralTimingSpecification alias GTS specializes SET<TS> {
IVL<TS> hull;
IVL<TS> nextTo(TS x);
IVL<TS> nextAfter(TS x);
GTS periodicHull(GTS x);
BL interleaves(GTS x);
demotion LIST<IVL<TS>>;
literal ST;
};
A set of points in time, specifying the timing of events and actions
and the cyclical validity-patterns that may exist for certain kinds of
information, such as phone numbers (evening, daytime), addresses (so
called "snowbirds," residing closer to the equator during winter and
farther from the equator during summer) and office hours.
The GTS data type has the following aspects:
GTS as a general set of points in time (
< >). From this aspect GTS answers
whether any given point in time falls in the schedule described by the
GTS value.
GTS as the combination of multiple periodic intervals of time. This
aspect describes how both simple and complex repeat-patterns are
specified with the GTS.
GTS as a generator of a sequence of intervals of point in time
( <
< >>).
From this aspect, GTS can generate all occurrence intervals of an event or
action, or all validity periods for a fact.
GTS as an expression-syntax defined for a calendar. This aspect is the
GTS literal form.
In all cases the GTS is defined as a set of point in time (
< >). Using the set operations,
union, intersection and difference, more complex sets of time can be
constructed from simpler ones. Ultimately the building blocks from
which all GTS values are constructed are interval, periodic interval,
and event-related periodic interval. The construction of the GTS can
be specified in the literal form. No special data type structure is
defined that would generate a combination of simpler time-sets from a
given GTS value. While any implementation would have to contain such a
structured representation, it is not needed in order to exchange GTS
values given the literal form.
The GTS is an example of a data type that is only defined
algebraically without giving any definition of a data structure that
might implement the behavior of such a data type. The algebraic
definition looks extremely simple, so that one might assume it is
incomplete. Since at this point we are relying entirely on the literal
form to represent GTS values, all the definition of data structur
The GTS data type is defined as using intervals, periodic intervals,
and event-related periodic intervals. Intervals of time have been
defined above
A convex hull is the least interval that is a superset of all
occurrence intervals. As noted in , all
totally ordered sets have a convex hull. Because a GTS is a
<> and because a
<> is a totally ordered set, all
GTS values have a convex hull.
The convex hull of a GTS can less formally be called "outer bound
interval". Thus, the convex hull of a GTS describes the absolute
beginning and end of the repeating schedule. For infinite repetitions
(e.g., a simple periodic interval) the convex hull has infinite
bounds.
Convex Hull of a Schedule
A value is a generator of a sequence of time
intervals during which an event or activity occurs, or during which a
state is effective.
The nextTo-property maps to every point in
time t the greatest continuous subset (an "occurrence
interval") v of the value
S, where v is the interval closest to
t that begins later than t or that contains
t.
invariant(GTS S, TS t, IVL<TS> v) {
v.equal(S.nextTo(t)).equal(
S.contains(o)
.and(forall(IVL<TS> u) where x.contains(u) {
u.contains(v).implies(u.equal(v)); })
.and( v.contains(t)
.or(forall(TS i) where t.lessOrEqual(i)
.and(i.lessThan(v.low)) {
S.conatins(i).not; })));
};
The nextAfter-property maps to every point
in time t the greatest continuous subset (an "occurrence
interval") v of the value
S, where v is the interval closest to
t that begins later than t.
invariant(GTS S, TS t) where {
S.contains(t).not
.implies(S.nextAfter(t).equal(S.nextTo(t)));
S.contains(t)
.implies(S.nextAfter(t).equal(
S.except(nextTo(t)).nextTo(t)));
};
A value can be converted into a generic Sequence
of time intervals (<>)
of occurrence intervals.
invariant(GTS x) where x.isEmpty { ((LIST<IVL<TS>>)x).isEmpty; };
invariant(GTS x, IVL<TS> first)
where x.notEmpty
.and(x.hull.low.nonNull)
.and(first.equal(x.nextTo(x.hull.low))
{
((LIST<IVL<TS>>)x).head.equal(first);
((LIST<IVL<TS>>)x).tail.equal(
(LIST<IVL<TS>>)x.except(first));
};
Interleaving Schedules and Periodic Hull
For two values A and B we
say that A interleaves B if their occurrence
intervals interleave on the time line. This concept is visualized in
Figure 15.
For the values A and B
to interleave the occurrence intervals of both groups can be arranged
in pairs of corresponding occurrence intervals. It must further hold
that for all corresponding occurrence intervals a
? A and b ? B,
a starts before b starts (or at the same
time) and b ends after a ends (or at the
same time).
The interleaves-relation holds when two schedules have the same
average frequency, and when the second schedule never "outpaces" the
first schedule. That is, no occurrence interval in the second schedule
may start before its corresponding occurrence interval in the first
schedule.
With two interleaving values one can derive a
periodic hull such that the occurrence intervals of the periodic hull
is the convex hull of the corresponding occurrence intervals.
The periodic hull is important to construct two schedules by combining
expressions. For example, to construct the periodic
interval from Memorial Day to Labor Day every year, one first needs to
set up the schedules M for Memorial Day (the last Monday
in May) and L for Labor Day (the first Monday in
September) and then combine these two schedules using the periodic
hull of M and L.
invariant(GTS A, B) where x.nonNull.and(y.nonNull) {
A.interleaves(B).equal(
forall(IVL<TS> a, b, c; TS t)
where a.equal(A.nextTo(t))
.and(b.equal(B.nextTo(a.low)))
.and(c.equal(A.nextTo(b.high))) {
b.equal(B.nextTo(a.high));
a.low.lessOrEqual(b.low);
c.equal(A.nextTo(b.high));
c.equal(a).or(c.equal(A.nextAfter(a.high)));
});
};
For two values A and B
where A interleaves B, a periodic hull is
defined as the pair wise convex hull of the corresponding occurrence
intervals of A and B.
invariant(GTS A, B, C) where A.interleaves(B) {
A.periodicHull(B).equal(C).equal(
forall(IVL<TS> a, b; TS t)
where a.equal(A.nextTo(t))
.and(b.equal(B.nextTo(a.low))) {
C.contains(c).equal(c.equal(a.hull(b)));
});
};
The interleaves-relation is reflexive, asymmetric, and
intransitive. The periodic hull operation is non-commutative and
non-associative.
The interleaves property may appear overly constrained. However, these
constraints are reasonable for the use case for which the interleaves
and periodic hull properties are defined. To safely and predictably
combine two schedules one would want to know which of the operands
sets the start points and which sets the endpoints of the periodic
hull's occurrence intervals.
type GeneralTimingSpecification alias GTS specializes SET<TS> {
IVL<TS> hull;
IVL<TS> nextTo(TS x);
IVL<TS> nextAfter(TS x);
GTS periodicHull(GTS x);
BL interleaves(GTS x);
demotion LIST<IVL<TS>>;
literal ST;
};
A set of points in time, specifying the timing of events and actions
and the cyclical validity-patterns that may exist for certain kinds of
information, such as phone numbers (evening, daytime), addresses (so
called "snowbirds," residing closer to the equator during winter and
farther from the equator during summer) and office hours.
The GTS data type has the following aspects:
GTS as a general set of points in time (
< >). From this aspect GTS answers
whether any given point in time falls in the schedule described by the
GTS value.
GTS as the combination of multiple periodic intervals of time. This
aspect describes how both simple and complex repeat-patterns are
specified with the GTS.
GTS as a generator of a sequence of intervals of point in time
( <
< >>).
From this aspect, GTS can generate all occurrence intervals of an event or
action, or all validity periods for a fact.
GTS as an expression-syntax defined for a calendar. This aspect is the
GTS literal form.
In all cases the GTS is defined as a set of point in time (
< >). Using the set operations,
union, intersection and difference, more complex sets of time can be
constructed from simpler ones. Ultimately the building blocks from
which all GTS values are constructed are interval, periodic interval,
and event-related periodic interval. The construction of the GTS can
be specified in the literal form. No special data type structure is
defined that would generate a combination of simpler time-sets from a
given GTS value. While any implementation would have to contain such a
structured representation, it is not needed in order to exchange GTS
values given the literal form.
The GTS is an example of a data type that is only defined
algebraically without giving any definition of a data structure that
might implement the behavior of such a data type. The algebraic
definition looks extremely simple, so that one might assume it is
incomplete. Since at this point we are relying entirely on the literal
form to represent GTS values, all the definition of data structur
The GTS data type is defined as using intervals, periodic intervals,
and event-related periodic intervals. Intervals of time have been
defined above
A convex hull is the least interval that is a superset of all
occurrence intervals. As noted in , all
totally ordered sets have a convex hull. Because a GTS is a
<> and because a
<> is a totally ordered set, all
GTS values have a convex hull.
The convex hull of a GTS can less formally be called "outer bound
interval". Thus, the convex hull of a GTS describes the absolute
beginning and end of the repeating schedule. For infinite repetitions
(e.g., a simple periodic interval) the convex hull has infinite
bounds.
Convex Hull of a Schedule
A value is a generator of a sequence of time
intervals during which an event or activity occurs, or during which a
state is effective.
The nextTo-property maps to every point in
time t the greatest continuous subset (an "occurrence
interval") v of the value
S, where v is the interval closest to
t that begins later than t or that contains
t.
invariant(GTS S, TS t, IVL<TS> v) {
v.equal(S.nextTo(t)).equal(
S.contains(o)
.and(forall(IVL<TS> u) where x.contains(u) {
u.contains(v).implies(u.equal(v)); })
.and( v.contains(t)
.or(forall(TS i) where t.lessOrEqual(i)
.and(i.lessThan(v.low)) {
S.conatins(i).not; })));
};
The nextAfter-property maps to every point
in time t the greatest continuous subset (an "occurrence
interval") v of the value
S, where v is the interval closest to
t that begins later than t.
invariant(GTS S, TS t) where {
S.contains(t).not
.implies(S.nextAfter(t).equal(S.nextTo(t)));
S.contains(t)
.implies(S.nextAfter(t).equal(
S.except(nextTo(t)).nextTo(t)));
};
A value can be converted into a generic Sequence
of time intervals (<>)
of occurrence intervals.
invariant(GTS x) where x.isEmpty { ((LIST<IVL<TS>>)x).isEmpty; };
invariant(GTS x, IVL<TS> first)
where x.notEmpty
.and(x.hull.low.nonNull)
.and(first.equal(x.nextTo(x.hull.low))
{
((LIST<IVL<TS>>)x).head.equal(first);
((LIST<IVL<TS>>)x).tail.equal(
(LIST<IVL<TS>>)x.except(first));
};
Interleaving Schedules and Periodic Hull
For two values A and B we
say that A interleaves B if their occurrence
intervals interleave on the time line. This concept is visualized in
Figure 15.
For the values A and B
to interleave the occurrence intervals of both groups can be arranged
in pairs of corresponding occurrence intervals. It must further hold
that for all corresponding occurrence intervals a
? A and b ? B,
a starts before b starts (or at the same
time) and b ends after a ends (or at the
same time).
The interleaves-relation holds when two schedules have the same
average frequency, and when the second schedule never "outpaces" the
first schedule. That is, no occurrence interval in the second schedule
may start before its corresponding occurrence interval in the first
schedule.
With two interleaving values one can derive a
periodic hull such that the occurrence intervals of the periodic hull
is the convex hull of the corresponding occurrence intervals.
The periodic hull is important to construct two schedules by combining
expressions. For example, to construct the periodic
interval from Memorial Day to Labor Day every year, one first needs to
set up the schedules M for Memorial Day (the last Monday
in May) and L for Labor Day (the first Monday in
September) and then combine these two schedules using the periodic
hull of M and L.
invariant(GTS A, B) where x.nonNull.and(y.nonNull) {
A.interleaves(B).equal(
forall(IVL<TS> a, b, c; TS t)
where a.equal(A.nextTo(t))
.and(b.equal(B.nextTo(a.low)))
.and(c.equal(A.nextTo(b.high))) {
b.equal(B.nextTo(a.high));
a.low.lessOrEqual(b.low);
c.equal(A.nextTo(b.high));
c.equal(a).or(c.equal(A.nextAfter(a.high)));
});
};
For two values A and B
where A interleaves B, a periodic hull is
defined as the pair wise convex hull of the corresponding occurrence
intervals of A and B.
invariant(GTS A, B, C) where A.interleaves(B) {
A.periodicHull(B).equal(C).equal(
forall(IVL<TS> a, b; TS t)
where a.equal(A.nextTo(t))
.and(b.equal(B.nextTo(a.low))) {
C.contains(c).equal(c.equal(a.hull(b)));
});
};
The interleaves-relation is reflexive, asymmetric, and
intransitive. The periodic hull operation is non-commutative and
non-associative.
The interleaves property may appear overly constrained. However, these
constraints are reasonable for the use case for which the interleaves
and periodic hull properties are defined. To safely and predictably
combine two schedules one would want to know which of the operands
sets the start points and which sets the endpoints of the periodic
hull's occurrence intervals.
type GeneralTimingSpecification alias GTS specializes SET<TS> {
IVL<TS> hull;
IVL<TS> nextTo(TS x);
IVL<TS> nextAfter(TS x);
GTS periodicHull(GTS x);
BL interleaves(GTS x);
demotion LIST<IVL<TS>>;
literal ST;
};
A set of points in time, specifying the timing of events and actions
and the cyclical validity-patterns that may exist for certain kinds of
information, such as phone numbers (evening, daytime), addresses (so
called "snowbirds," residing closer to the equator during winter and
farther from the equator during summer) and office hours.
The GTS data type has the following aspects:
GTS as a general set of points in time (
< >). From this aspect GTS answers
whether any given point in time falls in the schedule described by the
GTS value.
GTS as the combination of multiple periodic intervals of time. This
aspect describes how both simple and complex repeat-patterns are
specified with the GTS.
GTS as a generator of a sequence of intervals of point in time
( <
< >>).
From this aspect, GTS can generate all occurrence intervals of an event or
action, or all validity periods for a fact.
GTS as an expression-syntax defined for a calendar. This aspect is the
GTS literal form.
In all cases the GTS is defined as a set of point in time (
< >). Using the set operations,
union, intersection and difference, more complex sets of time can be
constructed from simpler ones. Ultimately the building blocks from
which all GTS values are constructed are interval, periodic interval,
and event-related periodic interval. The construction of the GTS can
be specified in the literal form. No special data type structure is
defined that would generate a combination of simpler time-sets from a
given GTS value. While any implementation would have to contain such a
structured representation, it is not needed in order to exchange GTS
values given the literal form.
The GTS is an example of a data type that is only defined
algebraically without giving any definition of a data structure that
might implement the behavior of such a data type. The algebraic
definition looks extremely simple, so that one might assume it is
incomplete. Since at this point we are relying entirely on the literal
form to represent GTS values, all the definition of data structur
The GTS data type is defined as using intervals, periodic intervals,
and event-related periodic intervals. Intervals of time have been
defined above
A convex hull is the least interval that is a superset of all
occurrence intervals. As noted in , all
totally ordered sets have a convex hull. Because a GTS is a
<> and because a
<> is a totally ordered set, all
GTS values have a convex hull.
The convex hull of a GTS can less formally be called "outer bound
interval". Thus, the convex hull of a GTS describes the absolute
beginning and end of the repeating schedule. For infinite repetitions
(e.g., a simple periodic interval) the convex hull has infinite
bounds.
Convex Hull of a Schedule
A value is a generator of a sequence of time
intervals during which an event or activity occurs, or during which a
state is effective.
The nextTo-property maps to every point in
time t the greatest continuous subset (an "occurrence
interval") v of the value
S, where v is the interval closest to
t that begins later than t or that contains
t.
invariant(GTS S, TS t, IVL<TS> v) {
v.equal(S.nextTo(t)).equal(
S.contains(o)
.and(forall(IVL<TS> u) where x.contains(u) {
u.contains(v).implies(u.equal(v)); })
.and( v.contains(t)
.or(forall(TS i) where t.lessOrEqual(i)
.and(i.lessThan(v.low)) {
S.conatins(i).not; })));
};
The nextAfter-property maps to every point
in time t the greatest continuous subset (an "occurrence
interval") v of the value
S, where v is the interval closest to
t that begins later than t.
invariant(GTS S, TS t) where {
S.contains(t).not
.implies(S.nextAfter(t).equal(S.nextTo(t)));
S.contains(t)
.implies(S.nextAfter(t).equal(
S.except(nextTo(t)).nextTo(t)));
};
A value can be converted into a generic Sequence
of time intervals (<>)
of occurrence intervals.
invariant(GTS x) where x.isEmpty { ((LIST<IVL<TS>>)x).isEmpty; };
invariant(GTS x, IVL<TS> first)
where x.notEmpty
.and(x.hull.low.nonNull)
.and(first.equal(x.nextTo(x.hull.low))
{
((LIST<IVL<TS>>)x).head.equal(first);
((LIST<IVL<TS>>)x).tail.equal(
(LIST<IVL<TS>>)x.except(first));
};
Interleaving Schedules and Periodic Hull
For two values A and B we
say that A interleaves B if their occurrence
intervals interleave on the time line. This concept is visualized in
Figure 15.
For the values A and B
to interleave the occurrence intervals of both groups can be arranged
in pairs of corresponding occurrence intervals. It must further hold
that for all corresponding occurrence intervals a
? A and b ? B,
a starts before b starts (or at the same
time) and b ends after a ends (or at the
same time).
The interleaves-relation holds when two schedules have the same
average frequency, and when the second schedule never "outpaces" the
first schedule. That is, no occurrence interval in the second schedule
may start before its corresponding occurrence interval in the first
schedule.
With two interleaving values one can derive a
periodic hull such that the occurrence intervals of the periodic hull
is the convex hull of the corresponding occurrence intervals.
The periodic hull is important to construct two schedules by combining
expressions. For example, to construct the periodic
interval from Memorial Day to Labor Day every year, one first needs to
set up the schedules M for Memorial Day (the last Monday
in May) and L for Labor Day (the first Monday in
September) and then combine these two schedules using the periodic
hull of M and L.
invariant(GTS A, B) where x.nonNull.and(y.nonNull) {
A.interleaves(B).equal(
forall(IVL<TS> a, b, c; TS t)
where a.equal(A.nextTo(t))
.and(b.equal(B.nextTo(a.low)))
.and(c.equal(A.nextTo(b.high))) {
b.equal(B.nextTo(a.high));
a.low.lessOrEqual(b.low);
c.equal(A.nextTo(b.high));
c.equal(a).or(c.equal(A.nextAfter(a.high)));
});
};
For two values A and B
where A interleaves B, a periodic hull is
defined as the pair wise convex hull of the corresponding occurrence
intervals of A and B.
invariant(GTS A, B, C) where A.interleaves(B) {
A.periodicHull(B).equal(C).equal(
forall(IVL<TS> a, b; TS t)
where a.equal(A.nextTo(t))
.and(b.equal(B.nextTo(a.low))) {
C.contains(c).equal(c.equal(a.hull(b)));
});
};
The interleaves-relation is reflexive, asymmetric, and
intransitive. The periodic hull operation is non-commutative and
non-associative.
The interleaves property may appear overly constrained. However, these
constraints are reasonable for the use case for which the interleaves
and periodic hull properties are defined. To safely and predictably
combine two schedules one would want to know which of the operands
sets the start points and which sets the endpoints of the periodic
hull's occurrence intervals.
type GeneralTimingSpecification alias GTS specializes SET<TS> {
IVL<TS> hull;
IVL<TS> nextTo(TS x);
IVL<TS> nextAfter(TS x);
GTS periodicHull(GTS x);
BL interleaves(GTS x);
demotion LIST<IVL<TS>>;
literal ST;
};
A set of points in time, specifying the timing of events and actions
and the cyclical validity-patterns that may exist for certain kinds of
information, such as phone numbers (evening, daytime), addresses (so
called "snowbirds," residing closer to the equator during winter and
farther from the equator during summer) and office hours.
The GTS data type has the following aspects:
GTS as a general set of points in time (
< >). From this aspect GTS answers
whether any given point in time falls in the schedule described by the
GTS value.
GTS as the combination of multiple periodic intervals of time. This
aspect describes how both simple and complex repeat-patterns are
specified with the GTS.
GTS as a generator of a sequence of intervals of point in time
( <
< >>).
From this aspect, GTS can generate all occurrence intervals of an event or
action, or all validity periods for a fact.
GTS as an expression-syntax defined for a calendar. This aspect is the
GTS literal form.
In all cases the GTS is defined as a set of point in time (
< >). Using the set operations,
union, intersection and difference, more complex sets of time can be
constructed from simpler ones. Ultimately the building blocks from
which all GTS values are constructed are interval, periodic interval,
and event-related periodic interval. The construction of the GTS can
be specified in the literal form. No special data type structure is
defined that would generate a combination of simpler time-sets from a
given GTS value. While any implementation would have to contain such a
structured representation, it is not needed in order to exchange GTS
values given the literal form.
The GTS is an example of a data type that is only defined
algebraically without giving any definition of a data structure that
might implement the behavior of such a data type. The algebraic
definition looks extremely simple, so that one might assume it is
incomplete. Since at this point we are relying entirely on the literal
form to represent GTS values, all the definition of data structur
The GTS data type is defined as using intervals, periodic intervals,
and event-related periodic intervals. Intervals of time have been
defined above
A convex hull is the least interval that is a superset of all
occurrence intervals. As noted in , all
totally ordered sets have a convex hull. Because a GTS is a
<> and because a
<> is a totally ordered set, all
GTS values have a convex hull.
The convex hull of a GTS can less formally be called "outer bound
interval". Thus, the convex hull of a GTS describes the absolute
beginning and end of the repeating schedule. For infinite repetitions
(e.g., a simple periodic interval) the convex hull has infinite
bounds.
Convex Hull of a Schedule
A value is a generator of a sequence of time
intervals during which an event or activity occurs, or during which a
state is effective.
The nextTo-property maps to every point in
time t the greatest continuous subset (an "occurrence
interval") v of the value
S, where v is the interval closest to
t that begins later than t or that contains
t.
invariant(GTS S, TS t, IVL<TS> v) {
v.equal(S.nextTo(t)).equal(
S.contains(o)
.and(forall(IVL<TS> u) where x.contains(u) {
u.contains(v).implies(u.equal(v)); })
.and( v.contains(t)
.or(forall(TS i) where t.lessOrEqual(i)
.and(i.lessThan(v.low)) {
S.conatins(i).not; })));
};
The nextAfter-property maps to every point
in time t the greatest continuous subset (an "occurrence
interval") v of the value
S, where v is the interval closest to
t that begins later than t.
invariant(GTS S, TS t) where {
S.contains(t).not
.implies(S.nextAfter(t).equal(S.nextTo(t)));
S.contains(t)
.implies(S.nextAfter(t).equal(
S.except(nextTo(t)).nextTo(t)));
};
A value can be converted into a generic Sequence
of time intervals (<>)
of occurrence intervals.
invariant(GTS x) where x.isEmpty { ((LIST<IVL<TS>>)x).isEmpty; };
invariant(GTS x, IVL<TS> first)
where x.notEmpty
.and(x.hull.low.nonNull)
.and(first.equal(x.nextTo(x.hull.low))
{
((LIST<IVL<TS>>)x).head.equal(first);
((LIST<IVL<TS>>)x).tail.equal(
(LIST<IVL<TS>>)x.except(first));
};
Interleaving Schedules and Periodic Hull
For two values A and B we
say that A interleaves B if their occurrence
intervals interleave on the time line. This concept is visualized in
Figure 15.
For the values A and B
to interleave the occurrence intervals of both groups can be arranged
in pairs of corresponding occurrence intervals. It must further hold
that for all corresponding occurrence intervals a
? A and b ? B,
a starts before b starts (or at the same
time) and b ends after a ends (or at the
same time).
The interleaves-relation holds when two schedules have the same
average frequency, and when the second schedule never "outpaces" the
first schedule. That is, no occurrence interval in the second schedule
may start before its corresponding occurrence interval in the first
schedule.
With two interleaving values one can derive a
periodic hull such that the occurrence intervals of the periodic hull
is the convex hull of the corresponding occurrence intervals.
The periodic hull is important to construct two schedules by combining
expressions. For example, to construct the periodic
interval from Memorial Day to Labor Day every year, one first needs to
set up the schedules M for Memorial Day (the last Monday
in May) and L for Labor Day (the first Monday in
September) and then combine these two schedules using the periodic
hull of M and L.
invariant(GTS A, B) where x.nonNull.and(y.nonNull) {
A.interleaves(B).equal(
forall(IVL<TS> a, b, c; TS t)
where a.equal(A.nextTo(t))
.and(b.equal(B.nextTo(a.low)))
.and(c.equal(A.nextTo(b.high))) {
b.equal(B.nextTo(a.high));
a.low.lessOrEqual(b.low);
c.equal(A.nextTo(b.high));
c.equal(a).or(c.equal(A.nextAfter(a.high)));
});
};
For two values A and B
where A interleaves B, a periodic hull is
defined as the pair wise convex hull of the corresponding occurrence
intervals of A and B.
invariant(GTS A, B, C) where A.interleaves(B) {
A.periodicHull(B).equal(C).equal(
forall(IVL<TS> a, b; TS t)
where a.equal(A.nextTo(t))
.and(b.equal(B.nextTo(a.low))) {
C.contains(c).equal(c.equal(a.hull(b)));
});
};
The interleaves-relation is reflexive, asymmetric, and
intransitive. The periodic hull operation is non-commutative and
non-associative.
The interleaves property may appear overly constrained. However, these
constraints are reasonable for the use case for which the interleaves
and periodic hull properties are defined. To safely and predictably
combine two schedules one would want to know which of the operands
sets the start points and which sets the endpoints of the periodic
hull's occurrence intervals.
type GeneralTimingSpecification alias GTS specializes SET<TS> {
IVL<TS> hull;
IVL<TS> nextTo(TS x);
IVL<TS> nextAfter(TS x);
GTS periodicHull(GTS x);
BL interleaves(GTS x);
demotion LIST<IVL<TS>>;
literal ST;
};
A set of points in time, specifying the timing of events and actions
and the cyclical validity-patterns that may exist for certain kinds of
information, such as phone numbers (evening, daytime), addresses (so
called "snowbirds," residing closer to the equator during winter and
farther from the equator during summer) and office hours.
The GTS data type has the following aspects:
GTS as a general set of points in time (
< >). From this aspect GTS answers
whether any given point in time falls in the schedule described by the
GTS value.
GTS as the combination of multiple periodic intervals of time. This
aspect describes how both simple and complex repeat-patterns are
specified with the GTS.
GTS as a generator of a sequence of intervals of point in time
( <
< >>).
From this aspect, GTS can generate all occurrence intervals of an event or
action, or all validity periods for a fact.
GTS as an expression-syntax defined for a calendar. This aspect is the
GTS literal form.
In all cases the GTS is defined as a set of point in time (
< >). Using the set operations,
union, intersection and difference, more complex sets of time can be
constructed from simpler ones. Ultimately the building blocks from
which all GTS values are constructed are interval, periodic interval,
and event-related periodic interval. The construction of the GTS can
be specified in the literal form. No special data type structure is
defined that would generate a combination of simpler time-sets from a
given GTS value. While any implementation would have to contain such a
structured representation, it is not needed in order to exchange GTS
values given the literal form.
The GTS is an example of a data type that is only defined
algebraically without giving any definition of a data structure that
might implement the behavior of such a data type. The algebraic
definition looks extremely simple, so that one might assume it is
incomplete. Since at this point we are relying entirely on the literal
form to represent GTS values, all the definition of data structur
The GTS data type is defined as using intervals, periodic intervals,
and event-related periodic intervals. Intervals of time have been
defined above
A convex hull is the least interval that is a superset of all
occurrence intervals. As noted in , all
totally ordered sets have a convex hull. Because a GTS is a
<> and because a
<> is a totally ordered set, all
GTS values have a convex hull.
The convex hull of a GTS can less formally be called "outer bound
interval". Thus, the convex hull of a GTS describes the absolute
beginning and end of the repeating schedule. For infinite repetitions
(e.g., a simple periodic interval) the convex hull has infinite
bounds.
Convex Hull of a Schedule
A value is a generator of a sequence of time
intervals during which an event or activity occurs, or during which a
state is effective.
The nextTo-property maps to every point in
time t the greatest continuous subset (an "occurrence
interval") v of the value
S, where v is the interval closest to
t that begins later than t or that contains
t.
invariant(GTS S, TS t, IVL<TS> v) {
v.equal(S.nextTo(t)).equal(
S.contains(o)
.and(forall(IVL<TS> u) where x.contains(u) {
u.contains(v).implies(u.equal(v)); })
.and( v.contains(t)
.or(forall(TS i) where t.lessOrEqual(i)
.and(i.lessThan(v.low)) {
S.conatins(i).not; })));
};
The nextAfter-property maps to every point
in time t the greatest continuous subset (an "occurrence
interval") v of the value
S, where v is the interval closest to
t that begins later than t.
invariant(GTS S, TS t) where {
S.contains(t).not
.implies(S.nextAfter(t).equal(S.nextTo(t)));
S.contains(t)
.implies(S.nextAfter(t).equal(
S.except(nextTo(t)).nextTo(t)));
};
A value can be converted into a generic Sequence
of time intervals (<>)
of occurrence intervals.
invariant(GTS x) where x.isEmpty { ((LIST<IVL<TS>>)x).isEmpty; };
invariant(GTS x, IVL<TS> first)
where x.notEmpty
.and(x.hull.low.nonNull)
.and(first.equal(x.nextTo(x.hull.low))
{
((LIST<IVL<TS>>)x).head.equal(first);
((LIST<IVL<TS>>)x).tail.equal(
(LIST<IVL<TS>>)x.except(first));
};
Interleaving Schedules and Periodic Hull
For two values A and B we
say that A interleaves B if their occurrence
intervals interleave on the time line. This concept is visualized in
Figure 15.
For the values A and B
to interleave the occurrence intervals of both groups can be arranged
in pairs of corresponding occurrence intervals. It must further hold
that for all corresponding occurrence intervals a
? A and b ? B,
a starts before b starts (or at the same
time) and b ends after a ends (or at the
same time).
The interleaves-relation holds when two schedules have the same
average frequency, and when the second schedule never "outpaces" the
first schedule. That is, no occurrence interval in the second schedule
may start before its corresponding occurrence interval in the first
schedule.
With two interleaving values one can derive a
periodic hull such that the occurrence intervals of the periodic hull
is the convex hull of the corresponding occurrence intervals.
The periodic hull is important to construct two schedules by combining
expressions. For example, to construct the periodic
interval from Memorial Day to Labor Day every year, one first needs to
set up the schedules M for Memorial Day (the last Monday
in May) and L for Labor Day (the first Monday in
September) and then combine these two schedules using the periodic
hull of M and L.
invariant(GTS A, B) where x.nonNull.and(y.nonNull) {
A.interleaves(B).equal(
forall(IVL<TS> a, b, c; TS t)
where a.equal(A.nextTo(t))
.and(b.equal(B.nextTo(a.low)))
.and(c.equal(A.nextTo(b.high))) {
b.equal(B.nextTo(a.high));
a.low.lessOrEqual(b.low);
c.equal(A.nextTo(b.high));
c.equal(a).or(c.equal(A.nextAfter(a.high)));
});
};
For two values A and B
where A interleaves B, a periodic hull is
defined as the pair wise convex hull of the corresponding occurrence
intervals of A and B.
invariant(GTS A, B, C) where A.interleaves(B) {
A.periodicHull(B).equal(C).equal(
forall(IVL<TS> a, b; TS t)
where a.equal(A.nextTo(t))
.and(b.equal(B.nextTo(a.low))) {
C.contains(c).equal(c.equal(a.hull(b)));
});
};
The interleaves-relation is reflexive, asymmetric, and
intransitive. The periodic hull operation is non-commutative and
non-associative.
The interleaves property may appear overly constrained. However, these
constraints are reasonable for the use case for which the interleaves
and periodic hull properties are defined. To safely and predictably
combine two schedules one would want to know which of the operands
sets the start points and which sets the endpoints of the periodic
hull's occurrence intervals.
type GeneralTimingSpecification alias GTS specializes SET<TS> {
IVL<TS> hull;
IVL<TS> nextTo(TS x);
IVL<TS> nextAfter(TS x);
GTS periodicHull(GTS x);
BL interleaves(GTS x);
demotion LIST<IVL<TS>>;
literal ST;
};
A set of points in time, specifying the timing of events and actions
and the cyclical validity-patterns that may exist for certain kinds of
information, such as phone numbers (evening, daytime), addresses (so
called "snowbirds," residing closer to the equator during winter and
farther from the equator during summer) and office hours.
The GTS data type has the following aspects:
GTS as a general set of points in time (
< >). From this aspect GTS answers
whether any given point in time falls in the schedule described by the
GTS value.
GTS as the combination of multiple periodic intervals of time. This
aspect describes how both simple and complex repeat-patterns are
specified with the GTS.
GTS as a generator of a sequence of intervals of point in time
( <
< >>).
From this aspect, GTS can generate all occurrence intervals of an event or
action, or all validity periods for a fact.
GTS as an expression-syntax defined for a calendar. This aspect is the
GTS literal form.
In all cases the GTS is defined as a set of point in time (
< >). Using the set operations,
union, intersection and difference, more complex sets of time can be
constructed from simpler ones. Ultimately the building blocks from
which all GTS values are constructed are interval, periodic interval,
and event-related periodic interval. The construction of the GTS can
be specified in the literal form. No special data type structure is
defined that would generate a combination of simpler time-sets from a
given GTS value. While any implementation would have to contain such a
structured representation, it is not needed in order to exchange GTS
values given the literal form.
The GTS is an example of a data type that is only defined
algebraically without giving any definition of a data structure that
might implement the behavior of such a data type. The algebraic
definition looks extremely simple, so that one might assume it is
incomplete. Since at this point we are relying entirely on the literal
form to represent GTS values, all the definition of data structur
The GTS data type is defined as using intervals, periodic intervals,
and event-related periodic intervals. Intervals of time have been
defined above
A convex hull is the least interval that is a superset of all
occurrence intervals. As noted in , all
totally ordered sets have a convex hull. Because a GTS is a
<> and because a
<> is a totally ordered set, all
GTS values have a convex hull.
The convex hull of a GTS can less formally be called "outer bound
interval". Thus, the convex hull of a GTS describes the absolute
beginning and end of the repeating schedule. For infinite repetitions
(e.g., a simple periodic interval) the convex hull has infinite
bounds.
Convex Hull of a Schedule
A value is a generator of a sequence of time
intervals during which an event or activity occurs, or during which a
state is effective.
The nextTo-property maps to every point in
time t the greatest continuous subset (an "occurrence
interval") v of the value
S, where v is the interval closest to
t that begins later than t or that contains
t.
invariant(GTS S, TS t, IVL<TS> v) {
v.equal(S.nextTo(t)).equal(
S.contains(o)
.and(forall(IVL<TS> u) where x.contains(u) {
u.contains(v).implies(u.equal(v)); })
.and( v.contains(t)
.or(forall(TS i) where t.lessOrEqual(i)
.and(i.lessThan(v.low)) {
S.conatins(i).not; })));
};
The nextAfter-property maps to every point
in time t the greatest continuous subset (an "occurrence
interval") v of the value
S, where v is the interval closest to
t that begins later than t.
invariant(GTS S, TS t) where {
S.contains(t).not
.implies(S.nextAfter(t).equal(S.nextTo(t)));
S.contains(t)
.implies(S.nextAfter(t).equal(
S.except(nextTo(t)).nextTo(t)));
};
A value can be converted into a generic Sequence
of time intervals (<>)
of occurrence intervals.
invariant(GTS x) where x.isEmpty { ((LIST<IVL<TS>>)x).isEmpty; };
invariant(GTS x, IVL<TS> first)
where x.notEmpty
.and(x.hull.low.nonNull)
.and(first.equal(x.nextTo(x.hull.low))
{
((LIST<IVL<TS>>)x).head.equal(first);
((LIST<IVL<TS>>)x).tail.equal(
(LIST<IVL<TS>>)x.except(first));
};
Interleaving Schedules and Periodic Hull
For two values A and B we
say that A interleaves B if their occurrence
intervals interleave on the time line. This concept is visualized in
Figure 15.
For the values A and B
to interleave the occurrence intervals of both groups can be arranged
in pairs of corresponding occurrence intervals. It must further hold
that for all corresponding occurrence intervals a
? A and b ? B,
a starts before b starts (or at the same
time) and b ends after a ends (or at the
same time).
The interleaves-relation holds when two schedules have the same
average frequency, and when the second schedule never "outpaces" the
first schedule. That is, no occurrence interval in the second schedule
may start before its corresponding occurrence interval in the first
schedule.
With two interleaving values one can derive a
periodic hull such that the occurrence intervals of the periodic hull
is the convex hull of the corresponding occurrence intervals.
The periodic hull is important to construct two schedules by combining
expressions. For example, to construct the periodic
interval from Memorial Day to Labor Day every year, one first needs to
set up the schedules M for Memorial Day (the last Monday
in May) and L for Labor Day (the first Monday in
September) and then combine these two schedules using the periodic
hull of M and L.
invariant(GTS A, B) where x.nonNull.and(y.nonNull) {
A.interleaves(B).equal(
forall(IVL<TS> a, b, c; TS t)
where a.equal(A.nextTo(t))
.and(b.equal(B.nextTo(a.low)))
.and(c.equal(A.nextTo(b.high))) {
b.equal(B.nextTo(a.high));
a.low.lessOrEqual(b.low);
c.equal(A.nextTo(b.high));
c.equal(a).or(c.equal(A.nextAfter(a.high)));
});
};
For two values A and B
where A interleaves B, a periodic hull is
defined as the pair wise convex hull of the corresponding occurrence
intervals of A and B.
invariant(GTS A, B, C) where A.interleaves(B) {
A.periodicHull(B).equal(C).equal(
forall(IVL<TS> a, b; TS t)
where a.equal(A.nextTo(t))
.and(b.equal(B.nextTo(a.low))) {
C.contains(c).equal(c.equal(a.hull(b)));
});
};
The interleaves-relation is reflexive, asymmetric, and
intransitive. The periodic hull operation is non-commutative and
non-associative.
The interleaves property may appear overly constrained. However, these
constraints are reasonable for the use case for which the interleaves
and periodic hull properties are defined. To safely and predictably
combine two schedules one would want to know which of the operands
sets the start points and which sets the endpoints of the periodic
hull's occurrence intervals.
type GeneralTimingSpecification alias GTS specializes SET<TS> {
IVL<TS> hull;
IVL<TS> nextTo(TS x);
IVL<TS> nextAfter(TS x);
GTS periodicHull(GTS x);
BL interleaves(GTS x);
demotion LIST<IVL<TS>>;
literal ST;
};
A set of points in time, specifying the timing of events and actions
and the cyclical validity-patterns that may exist for certain kinds of
information, such as phone numbers (evening, daytime), addresses (so
called "snowbirds," residing closer to the equator during winter and
farther from the equator during summer) and office hours.
The GTS data type has the following aspects:
GTS as a general set of points in time (
< >). From this aspect GTS answers
whether any given point in time falls in the schedule described by the
GTS value.
GTS as the combination of multiple periodic intervals of time. This
aspect describes how both simple and complex repeat-patterns are
specified with the GTS.
GTS as a generator of a sequence of intervals of point in time
( <
< >>).
From this aspect, GTS can generate all occurrence intervals of an event or
action, or all validity periods for a fact.
GTS as an expression-syntax defined for a calendar. This aspect is the
GTS literal form.
In all cases the GTS is defined as a set of point in time (
< >). Using the set operations,
union, intersection and difference, more complex sets of time can be
constructed from simpler ones. Ultimately the building blocks from
which all GTS values are constructed are interval, periodic interval,
and event-related periodic interval. The construction of the GTS can
be specified in the literal form. No special data type structure is
defined that would generate a combination of simpler time-sets from a
given GTS value. While any implementation would have to contain such a
structured representation, it is not needed in order to exchange GTS
values given the literal form.
The GTS is an example of a data type that is only defined
algebraically without giving any definition of a data structure that
might implement the behavior of such a data type. The algebraic
definition looks extremely simple, so that one might assume it is
incomplete. Since at this point we are relying entirely on the literal
form to represent GTS values, all the definition of data structur
The GTS data type is defined as using intervals, periodic intervals,
and event-related periodic intervals. Intervals of time have been
defined above
A convex hull is the least interval that is a superset of all
occurrence intervals. As noted in , all
totally ordered sets have a convex hull. Because a GTS is a
<> and because a
<> is a totally ordered set, all
GTS values have a convex hull.
The convex hull of a GTS can less formally be called "outer bound
interval". Thus, the convex hull of a GTS describes the absolute
beginning and end of the repeating schedule. For infinite repetitions
(e.g., a simple periodic interval) the convex hull has infinite
bounds.
Convex Hull of a Schedule
A value is a generator of a sequence of time
intervals during which an event or activity occurs, or during which a
state is effective.
The nextTo-property maps to every point in
time t the greatest continuous subset (an "occurrence
interval") v of the value
S, where v is the interval closest to
t that begins later than t or that contains
t.
invariant(GTS S, TS t, IVL<TS> v) {
v.equal(S.nextTo(t)).equal(
S.contains(o)
.and(forall(IVL<TS> u) where x.contains(u) {
u.contains(v).implies(u.equal(v)); })
.and( v.contains(t)
.or(forall(TS i) where t.lessOrEqual(i)
.and(i.lessThan(v.low)) {
S.conatins(i).not; })));
};
The nextAfter-property maps to every point
in time t the greatest continuous subset (an "occurrence
interval") v of the value
S, where v is the interval closest to
t that begins later than t.
invariant(GTS S, TS t) where {
S.contains(t).not
.implies(S.nextAfter(t).equal(S.nextTo(t)));
S.contains(t)
.implies(S.nextAfter(t).equal(
S.except(nextTo(t)).nextTo(t)));
};
A value can be converted into a generic Sequence
of time intervals (<>)
of occurrence intervals.
invariant(GTS x) where x.isEmpty { ((LIST<IVL<TS>>)x).isEmpty; };
invariant(GTS x, IVL<TS> first)
where x.notEmpty
.and(x.hull.low.nonNull)
.and(first.equal(x.nextTo(x.hull.low))
{
((LIST<IVL<TS>>)x).head.equal(first);
((LIST<IVL<TS>>)x).tail.equal(
(LIST<IVL<TS>>)x.except(first));
};
Interleaving Schedules and Periodic Hull
For two values A and B we
say that A interleaves B if their occurrence
intervals interleave on the time line. This concept is visualized in
Figure 15.
For the values A and B
to interleave the occurrence intervals of both groups can be arranged
in pairs of corresponding occurrence intervals. It must further hold
that for all corresponding occurrence intervals a
? A and b ? B,
a starts before b starts (or at the same
time) and b ends after a ends (or at the
same time).
The interleaves-relation holds when two schedules have the same
average frequency, and when the second schedule never "outpaces" the
first schedule. That is, no occurrence interval in the second schedule
may start before its corresponding occurrence interval in the first
schedule.
With two interleaving values one can derive a
periodic hull such that the occurrence intervals of the periodic hull
is the convex hull of the corresponding occurrence intervals.
The periodic hull is important to construct two schedules by combining
expressions. For example, to construct the periodic
interval from Memorial Day to Labor Day every year, one first needs to
set up the schedules M for Memorial Day (the last Monday
in May) and L for Labor Day (the first Monday in
September) and then combine these two schedules using the periodic
hull of M and L.
invariant(GTS A, B) where x.nonNull.and(y.nonNull) {
A.interleaves(B).equal(
forall(IVL<TS> a, b, c; TS t)
where a.equal(A.nextTo(t))
.and(b.equal(B.nextTo(a.low)))
.and(c.equal(A.nextTo(b.high))) {
b.equal(B.nextTo(a.high));
a.low.lessOrEqual(b.low);
c.equal(A.nextTo(b.high));
c.equal(a).or(c.equal(A.nextAfter(a.high)));
});
};
For two values A and B
where A interleaves B, a periodic hull is
defined as the pair wise convex hull of the corresponding occurrence
intervals of A and B.
invariant(GTS A, B, C) where A.interleaves(B) {
A.periodicHull(B).equal(C).equal(
forall(IVL<TS> a, b; TS t)
where a.equal(A.nextTo(t))
.and(b.equal(B.nextTo(a.low))) {
C.contains(c).equal(c.equal(a.hull(b)));
});
};
The interleaves-relation is reflexive, asymmetric, and
intransitive. The periodic hull operation is non-commutative and
non-associative.
The interleaves property may appear overly constrained. However, these
constraints are reasonable for the use case for which the interleaves
and periodic hull properties are defined. To safely and predictably
combine two schedules one would want to know which of the operands
sets the start points and which sets the endpoints of the periodic
hull's occurrence intervals.
type GeneralTimingSpecification alias GTS specializes SET<TS> {
IVL<TS> hull;
IVL<TS> nextTo(TS x);
IVL<TS> nextAfter(TS x);
GTS periodicHull(GTS x);
BL interleaves(GTS x);
demotion LIST<IVL<TS>>;
literal ST;
};
PPD (ParametricProbabilityDistribution)
A generic data type extension specifying uncertainty of quantitative
data using a distribution function and its parameters. Aside from the
specific parameters of the distribution, a mean (expected value) and
standard deviation is always given to help maintain a minimum layer
of interoperability if receiving applications cannot deal with a
certain probability distribution.
For example, the most common college entrance exam in the United
States is the SAT, which is comprised of two parts: verbal and
math. Each part has a minimum score of 400 (no questions answered
correctly) and a perfect score of 800. In 1998, according to the
College Board, 1,172,779 college-bound seniors took the test. The mean
score for the math portion of the test was 512, and the standard
deviation 112. These parameter values (512, 112), tagged as the normal
distribution parameters, paint a pretty good picture of test score
distribution. In most cases, there is no need to specify all
1-million+ points of data when just 2 parameters will do!
Note that the normal distribution is only one of several distributions
defined for HL7.
Since a specializes its parameter type T, a simple T value is
the mean (expected value or first moment) of the probability
distribution. Applications that cannot deal with distributions will
take the simple T value neglecting the uncertainty. That simple value
of type T is also used to standardize the data for computing the
distribution.
Probability distributions are defined over integer or real numbers and
normalized to a certain reference point (typically zero) and reference
unit (e.g., standard deviation = 1). When other quantities defined in
this specification are used as base types, the mean and the standard
deviation are used to scale the probability distribution. For example,
if a of PQ for a length is given with mean 20 ft
and a standard deviation of 2 in, the normalized distribution function
f(x) that maps a real number x
to a probability density would be translated to
f'(x') that maps a length
x' to a probability density as
f'(x') =
f((x' - ? ) / s).
Where applicable, the specification conforms to
the ISO Guide to the Expression of Uncertainty in
Measurement (GUM) as reflected by NIST publication 1297
Guidelines for Evaluating and Expressing the Uncertainty of NIST
Measurement Results. The specification does not
describe how uncertainty is to be evaluated but only how it is
expressed. The concept of "standard uncertainty" as set forth by the
ISO GUM corresponds to the "standard deviation" property of the .
template<QTY T>
type ParametricProbabilityDistribution<T> alias PPD<T>
specializes T {
QTY standardDeviation;
CS distributionType;
literal ST;
};
A generic data type extension specifying uncertainty of quantitative
data using a distribution function and its parameters. Aside from the
specific parameters of the distribution, a mean (expected value) and
standard deviation is always given to help maintain a minimum layer
of interoperability if receiving applications cannot deal with a
certain probability distribution.
For example, the most common college entrance exam in the United
States is the SAT, which is comprised of two parts: verbal and
math. Each part has a minimum score of 400 (no questions answered
correctly) and a perfect score of 800. In 1998, according to the
College Board, 1,172,779 college-bound seniors took the test. The mean
score for the math portion of the test was 512, and the standard
deviation 112. These parameter values (512, 112), tagged as the normal
distribution parameters, paint a pretty good picture of test score
distribution. In most cases, there is no need to specify all
1-million+ points of data when just 2 parameters will do!
Note that the normal distribution is only one of several distributions
defined for HL7.
Since a specializes its parameter type T, a simple T value is
the mean (expected value or first moment) of the probability
distribution. Applications that cannot deal with distributions will
take the simple T value neglecting the uncertainty. That simple value
of type T is also used to standardize the data for computing the
distribution.
Probability distributions are defined over integer or real numbers and
normalized to a certain reference point (typically zero) and reference
unit (e.g., standard deviation = 1). When other quantities defined in
this specification are used as base types, the mean and the standard
deviation are used to scale the probability distribution. For example,
if a of PQ for a length is given with mean 20 ft
and a standard deviation of 2 in, the normalized distribution function
f(x) that maps a real number x
to a probability density would be translated to
f'(x') that maps a length
x' to a probability density as
f'(x') =
f((x' - ? ) / s).
Where applicable, the specification conforms to
the ISO Guide to the Expression of Uncertainty in
Measurement (GUM) as reflected by NIST publication 1297
Guidelines for Evaluating and Expressing the Uncertainty of NIST
Measurement Results. The specification does not
describe how uncertainty is to be evaluated but only how it is
expressed. The concept of "standard uncertainty" as set forth by the
ISO GUM corresponds to the "standard deviation" property of the .
template<QTY T>
type ParametricProbabilityDistribution<T> alias PPD<T>
specializes T {
QTY standardDeviation;
CS distributionType;
literal ST;
};
A generic data type extension specifying uncertainty of quantitative
data using a distribution function and its parameters. Aside from the
specific parameters of the distribution, a mean (expected value) and
standard deviation is always given to help maintain a minimum layer
of interoperability if receiving applications cannot deal with a
certain probability distribution.
For example, the most common college entrance exam in the United
States is the SAT, which is comprised of two parts: verbal and
math. Each part has a minimum score of 400 (no questions answered
correctly) and a perfect score of 800. In 1998, according to the
College Board, 1,172,779 college-bound seniors took the test. The mean
score for the math portion of the test was 512, and the standard
deviation 112. These parameter values (512, 112), tagged as the normal
distribution parameters, paint a pretty good picture of test score
distribution. In most cases, there is no need to specify all
1-million+ points of data when just 2 parameters will do!
Note that the normal distribution is only one of several distributions
defined for HL7.
Since a specializes its parameter type T, a simple T value is
the mean (expected value or first moment) of the probability
distribution. Applications that cannot deal with distributions will
take the simple T value neglecting the uncertainty. That simple value
of type T is also used to standardize the data for computing the
distribution.
Probability distributions are defined over integer or real numbers and
normalized to a certain reference point (typically zero) and reference
unit (e.g., standard deviation = 1). When other quantities defined in
this specification are used as base types, the mean and the standard
deviation are used to scale the probability distribution. For example,
if a of PQ for a length is given with mean 20 ft
and a standard deviation of 2 in, the normalized distribution function
f(x) that maps a real number x
to a probability density would be translated to
f'(x') that maps a length
x' to a probability density as
f'(x') =
f((x' - ? ) / s).
Where applicable, the specification conforms to
the ISO Guide to the Expression of Uncertainty in
Measurement (GUM) as reflected by NIST publication 1297
Guidelines for Evaluating and Expressing the Uncertainty of NIST
Measurement Results. The specification does not
describe how uncertainty is to be evaluated but only how it is
expressed. The concept of "standard uncertainty" as set forth by the
ISO GUM corresponds to the "standard deviation" property of the .
template<QTY T>
type ParametricProbabilityDistribution<T> alias PPD<T>
specializes T {
QTY standardDeviation;
CS distributionType;
literal ST;
};
A generic data type extension specifying uncertainty of quantitative
data using a distribution function and its parameters. Aside from the
specific parameters of the distribution, a mean (expected value) and
standard deviation is always given to help maintain a minimum layer
of interoperability if receiving applications cannot deal with a
certain probability distribution.
For example, the most common college entrance exam in the United
States is the SAT, which is comprised of two parts: verbal and
math. Each part has a minimum score of 400 (no questions answered
correctly) and a perfect score of 800. In 1998, according to the
College Board, 1,172,779 college-bound seniors took the test. The mean
score for the math portion of the test was 512, and the standard
deviation 112. These parameter values (512, 112), tagged as the normal
distribution parameters, paint a pretty good picture of test score
distribution. In most cases, there is no need to specify all
1-million+ points of data when just 2 parameters will do!
Note that the normal distribution is only one of several distributions
defined for HL7.
Since a specializes its parameter type T, a simple T value is
the mean (expected value or first moment) of the probability
distribution. Applications that cannot deal with distributions will
take the simple T value neglecting the uncertainty. That simple value
of type T is also used to standardize the data for computing the
distribution.
Probability distributions are defined over integer or real numbers and
normalized to a certain reference point (typically zero) and reference
unit (e.g., standard deviation = 1). When other quantities defined in
this specification are used as base types, the mean and the standard
deviation are used to scale the probability distribution. For example,
if a of PQ for a length is given with mean 20 ft
and a standard deviation of 2 in, the normalized distribution function
f(x) that maps a real number x
to a probability density would be translated to
f'(x') that maps a length
x' to a probability density as
f'(x') =
f((x' - ? ) / s).
Where applicable, the specification conforms to
the ISO Guide to the Expression of Uncertainty in
Measurement (GUM) as reflected by NIST publication 1297
Guidelines for Evaluating and Expressing the Uncertainty of NIST
Measurement Results. The specification does not
describe how uncertainty is to be evaluated but only how it is
expressed. The concept of "standard uncertainty" as set forth by the
ISO GUM corresponds to the "standard deviation" property of the .
template<QTY T>
type ParametricProbabilityDistribution<T> alias PPD<T>
specializes T {
QTY standardDeviation;
CS distributionType;
literal ST;
};
PPD_REAL (ParametricProbabilityDistribution<RealNumber>)
The parametric probability distribution of real numbers is fully defined by
the generic data type.
However, there are some special considerations about literal representations
and conversions of probability distributions over real numbers, which are
specified in this section.
When converting a into a ,
the standard deviation is calculated from the value's
order of magnitude and precision (number of significant digits).
Let x be a real number with precision n. We can
determine the order of magnitude e of x as
e = log10 |x| where e is rounded to
the next integer that is closer to zero (special case: if x
is zero, e is zero.) The value of least significant digit
l is then l = 10e-n
and the standard deviation s is s = l /
2.
Examples of standard deviations computed from precision p and order of magnitude eRepresentationxepe - p + 1ls00(0)1010.51101010.52201010.59901010.5101012010.510010023010.51e+1101111051e+21002121005010e+11002211051.11.102-10.10.0510.110.113-10.10.051.1e+21102211051.1e-20.011-22-30.0010.00051.1e-40.00011-42-50.000010.00000510.1e-40.00101-33-50.000010.0000050.1e-10.01-21-20.010.0050.01e-10.001-31-30.0010.00050.01e-20.0001-41-40.00010.000050.000(0)3-20.010.005
type ParametricProbabilityDistribution<RealNumber> alias PPD<REAL> specializes PPD<T>;
The parametric probability distribution of real numbers is fully defined by
the generic data type.
However, there are some special considerations about literal representations
and conversions of probability distributions over real numbers, which are
specified in this section.
When converting a into a ,
the standard deviation is calculated from the value's
order of magnitude and precision (number of significant digits).
Let x be a real number with precision n. We can
determine the order of magnitude e of x as
e = log10 |x| where e is rounded to
the next integer that is closer to zero (special case: if x
is zero, e is zero.) The value of least significant digit
l is then l = 10e-n
and the standard deviation s is s = l /
2.
Examples of standard deviations computed from precision p and order of magnitude eRepresentationxepe - p + 1ls00(0)1010.51101010.52201010.59901010.5101012010.510010023010.51e+1101111051e+21002121005010e+11002211051.11.102-10.10.0510.110.113-10.10.051.1e+21102211051.1e-20.011-22-30.0010.00051.1e-40.00011-42-50.000010.00000510.1e-40.00101-33-50.000010.0000050.1e-10.01-21-20.010.0050.01e-10.001-31-30.0010.00050.01e-20.0001-41-40.00010.000050.000(0)3-20.010.005
type ParametricProbabilityDistribution<RealNumber> alias PPD<REAL> specializes PPD<T>;
PPD_PQ (ParametricProbabilityDistribution<PhysicalQuantity>)
A parametric probability distribution over physical quantities is
constructed from the generic type. However,
recognizing that the unit can be factored from the boundaries, we add
additional semantics and a separate literal form. The additional view
of a probability distribution over physical quantities is a
probability distribution over real numbers with one unit.
The unit applies to both mean and standard deviation.
type ParametricProbabilityDistribution<PhysicalQuantity> alias PPD<PQ> specializes PPD<T> {
PPD<REAL> value;
CS unit;
};
A parametric probability distribution over physical quantities is
constructed from the generic type. However,
recognizing that the unit can be factored from the boundaries, we add
additional semantics and a separate literal form. The additional view
of a probability distribution over physical quantities is a
probability distribution over real numbers with one unit.
The unit applies to both mean and standard deviation.
type ParametricProbabilityDistribution<PhysicalQuantity> alias PPD<PQ> specializes PPD<T> {
PPD<REAL> value;
CS unit;
};
A parametric probability distribution over physical quantities is
constructed from the generic type. However,
recognizing that the unit can be factored from the boundaries, we add
additional semantics and a separate literal form. The additional view
of a probability distribution over physical quantities is a
probability distribution over real numbers with one unit.
The unit applies to both mean and standard deviation.
type ParametricProbabilityDistribution<PhysicalQuantity> alias PPD<PQ> specializes PPD<T> {
PPD<REAL> value;
CS unit;
};
A parametric probability distribution over physical quantities is
constructed from the generic type. However,
recognizing that the unit can be factored from the boundaries, we add
additional semantics and a separate literal form. The additional view
of a probability distribution over physical quantities is a
probability distribution over real numbers with one unit.
The unit applies to both mean and standard deviation.
type ParametricProbabilityDistribution<PhysicalQuantity> alias PPD<PQ> specializes PPD<T> {
PPD<REAL> value;
CS unit;
};
PPD_TS (ParametricProbabilityDistribution<PointInTime>)
The parametric probability distribution over time points is fully defined by
the generic data type.
The standard deviation is of type TS.diffType, which is a duration (a physical
quantity in the dimension of time.)
When converting a into a
<>, the standard deviation is
calculated from the value's order of magnitude
and precision (number of significant digits) such that two standard
deviations span the maximal time range of the digits not
specified. For example, in 20000609 the unspecified digits are hour of
the day and lower. All these digits together span a duration of 24
hours, and thus, the standard deviation ( is( = 12 h from
20000609000000.0000... up to 20000609999999.9999... (= 20000610)
This rule is different from real numbers in that the range of uncertainty lies
above the time value specified. This is to go with the common sense judgment
that June 9th spans all day of June 9th with noon as the center, not midnight.
type ParametricProbabilityDistribution<PointInTime> alias PPD<TS> specializes PPD<T>;