Inserts and queries – a new approach

Inserts and queries – a new approach

Queries that are expressed in natural languages have nearly the same structure and use the same terminology as statements in natural languages. Thus the language used for statements as well as the variant that is used for questions are only slightly different. The differences, such as changes in word sequences and the use of question marks, can even be eliminated completely when the ‘Speech act’ theory of John Searl is applied. Searl demonstrated that the expressions can be made identical by explicit mentioning the intention of an expression. For example:

Statement: book B-1 has a price of 110 dollar
Question: book B-1 has a price of 110 dollar
Confirmation: book B-1 has a price of 110 dollar

Because the second expression shall be interpreted as a question, it is clear that its asks for a confirmation or a denial. Note that a confirmations is equivalent to the answer ‘yes’ or ‘indeed’. Queries on conventional database content are usually expressed in dedicated query languages, such as SQL and SPARQL. The ”Speech act” theory and other conventions open up the possibility to use the same formalized language for statements (in exchanges messages or data stores) as well as for insertion commands, for queries and for responses (answers), as is described below.

SQL assumptions and limited semantics

Query languages such as SQL are independent of database structures and used language for the content, as long as the structure is tabular. do not put any requirements on the tables in the database, neither on their names nor on their columns and column names. This freedom is required because a lack of standardization causes that different databases are composed of different tables, with other names and other numbers of columns with different names, even when they contain the same information about the same kinds of things. Thus INSERTs as well as SELECT statements will be different for each database. This freedom also implies that these languages presuppose that authors of inserts and queries have knowledge about the internal structure (syntax) of the queried database as well as of the used terminology for table columns and table content. Thus, SQL and other query languages themselves do not deal with any meaning (semantics) of the columns of the tables and are also independent of the terminology that is used for the content of the tables. They are generic languages that have a minimum of semantics. For example, the following simple insertion in database table called ‘Book’ is written in SQL (adapted from http://en.wikipedia.org/wiki/SQL):

INSERT INTO Book
 (title, price, type)
 VALUES
 (‘B-1’, 110) (‘B-2’, 120, paperback) ;

Apparently the author of this insert knows that there exists already a table, called ‘Book’ that has at least three columns, called title, price, and type, whereas he also knows that a title is the title of a book and a price on the same row is the net selling price (in dollar) of a single copy of a book with that title and a type denotes a subtype of book that classifies the book on that same row. He also introduces a new free term in the vocabulary of the content, unless the term ‘paperback’ is a predefined allowed value for ‘type’.

The same content could however be stored in a databases that have different definitions. For example, the database ‘Product’, with columns that have names such as ‘name’, ‘nett price’, ‘product type’. Then the INSERT would have been different, although the content would be the same.

Data can be retrieved from such database tables with queries that are also expressed in such query languages. For example the following select from the ‘Book’ table is also expressed in SQL:

SELECT *

FROM Book

WHERE price > 100.00 ;

This simple query apparently assumes the same knowledge from the author as is required for the insertion.

The same query would be different when it was a query on the ‘Product’ database. Furthermore, the expressions for insertion of information are significantly different from expressions of a query about the same information and those expressions are again different from expressions that present the results of a query.

Equivalent inserts and selects in Formal English

This is quite different when Formal English is adopted. One of the advantages of Formal English expressions is that the structure of expressions as well as their vocabulary are all the same. This is achieved by the rule that all Formal English expressions have the same expression components (thus they can all be stored in one standard table) and all Formal English expressions use the same (extensible) dictionary-taxonomy with predefined concepts, such as book, title, price and paperback. Furthermore, the expressions for insertion are similar to the expressions of queries and to stored and exchanged information.

Thus Formal English insertions and queries are only determined by the semantics and are not determined by the many possible database structures, and they are independent on the variety of terminology that is used in current practices for names of entity types and names of attribute types.

This means that information that is expressed in Formal English can be inserted in any database table that is based on Formal English or that has import and export mapping to Formal English expressions (within access and requirements constraints). Note that Formal English expression tables are not just for books only!. Thus the system independent expressions don’t need to be rewritten for other databases. Table 1 presents an example of an insert command for information about the prices of two books with expressions in Formal English that are database independent.

\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n

\r\n

Intention

\r\n

UID of left hand object

\r\n

Name of left hand object

\r\n

Name of relation type

\r\n

UID of right hand object

\r\n

Name of right hand object

\r\n

UoM

\r\n

command

\r\n

195070

\r\n

insert

\r\n

the following expressions into

\r\n

101

\r\n

ABC

\r\n

statement

\r\n

102

\r\n

B-1

\r\n

is classified as a

\r\n

490023

\r\n

book

\r\n

statement

\r\n

102

\r\n

B-1

\r\n

has as aspect

\r\n

103

\r\n

P-1 of B-1

\r\n

statement

\r\n

103

\r\n

P-1 of B-1

\r\n

is classified as a

\r\n

550742

\r\n

price

\r\n

statement

\r\n

103

\r\n

P-1 of B-1

\r\n

has on scale a value equal to

\r\n

920366

\r\n

110

\r\n

$

\r\n

statement

\r\n

104

\r\n

B-2

\r\n

is classified as a

\r\n

493755

\r\n

paperback

\r\n

statement

\r\n

104

\r\n

B-2

\r\n

has as aspect

\r\n

105

\r\n

P-1 of B-2

\r\n

statement

\r\n

105

\r\n

P-1 of B-2

\r\n

is classified as a

\r\n

550742

\r\n

price

\r\n

statement

\r\n

105

\r\n

P-1 of B-2

\r\n

has on scale a value equal to

\r\n

920376

\r\n

120

\r\n

$

\r\n

command

\r\n

193423

\r\n

terminate

\r\n

the execution of

\r\n

195070

\r\n

insert

Table 1, Insert product data in table ABC

Note: Table 1 only shows a subset of the Gellish Expression Format. In a full Gellish Expression Format each line has more UID’s and contextual facts, such as the validity period, status, originator, etc. This enables e.g. to add multiple prices in various currencies and each with its own validity time period, if the cardinality constraints allow for that.

The body of Table 1, without the first and the last line can be copied exactly into a database table, such as ABC, because the storage table has an identical table structure.

The above query in SQL is expressed in Formal English as follows:

\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n

\r\n

Intention

\r\n

UID of left hand object

\r\n

Name of left hand object

\r\n

Name of relation type

\r\n

UID of right hand object

\r\n

Name of right hand object

\r\n

UoM

\r\n

command

\r\n

193617

\r\n

select

\r\n

the following expressions from

\r\n

101

\r\n

ABC

\r\n

question

\r\n

1

\r\n

?Book-1

\r\n

is classified as a

\r\n

490023

\r\n

book

\r\n

question

\r\n

1

\r\n

?Book-1

\r\n

has as aspect

\r\n

2

\r\n

?Price-1

\r\n

question

\r\n

2

\r\n

?Price-1

\r\n

is classified as a

\r\n

550742

\r\n

price

\r\n

question

\r\n

2

\r\n

?Price-1

\r\n

has on scale a value greater than

\r\n

920053

\r\n

100

\r\n

$

\r\n

command

\r\n

193423

\r\n

terminate

\r\n

the execution of

\r\n

193617

\r\n

select

Table 2, Query table ABC in the form of a product model

Comparison of Table 1 with Table 2 shows the similarity of the models, which demonstrates that the expression of information and the expression of queries can be done in the same language. Thus there is no need for a dedicated query language.

Note 1: Formally the names of the unknowns are free, although it is recommended to use terms such as ‘what’ and ‘which’ and ‘who’ (possibly followed by a sequence number) or terms that start with a question mark (?), as is an SPARQL convention. The reason why the names are free is to enable search on string commonalities (see below). This freedom is enabled by the fact that, according to the Gellish Formal English convention, all unknowns shall be represented by UID’s that are numbers in the range 1 to 99. Thus each query can have a maximum of 99 variables. Remember that all terms denote concepts that are represented by UID’s., although those UID’s are not shown in Table 1 and Table 2 to limit the widths of the tables.
Thus, in practice the expressions, the left and right hand objects and the kinds of relations all have unique identifiers (UID’s).

Note 2: A query may search for and select from more than one table at the same time (because the various tables have the same definition). Tables do not need to be JOINed, only the search results should then be presented to the user as a combined result.

The query that is expressed in Table 2 illustrates that software should take the taxonomy of concepts into account. For example, the dictionary-taxonomy specifies that the concept paperback is a subtype of book. If the software processes that information correctly, then a query on book will also find the paperbacks. This hierarchy enables to simply modify the query to search e.g. on paperbacks only or on any other subtype.

In SQL and asterisk (*) can be used to specify that ‘all’ attributes from a table should be reported. This assumes that the authors knows which attributes are in the table, but when there is information about the books in other tables the query becomes more complicated. In the Gellish Formal English approach the kinds of relations that are queried can be specified more precisely. For example the query in Table 2 uses relation type <has as aspect> and thus it only asks for aspects, whereas on the following line it is specified that only aspects are required for which holds that the aspect <is classified as a> price. The query can easily be extended with additional requests for other information, such as

\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n

\r\n

question

\r\n

What-1

\r\n

is located in

\r\n

Some location-1

\r\n

question

\r\n

Some location-1

\r\n

is classified as a

\r\n

building

Or with the very generic question:

\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n

\r\n

question

\r\n

What-1

\r\n

is related to

\r\n

A-1

\r\n

question

\r\n

A-1

\r\n

is classified as a

\r\n

anything

This latest question asks for everything that is known about the books.

Further data manipulation constructs for operations on the search results, including operations on the contextual facts, are outside the scope of this paper.

Search string commonalities

One of the reasons to leave the names of the variables free is to enable to specify character strings that only partially match with names that are searched for. The name of an unknown can be specified as P-1, whereas the intention is to search for things that have a name that starts with P-1, so that e.g. P-101 and P-1201, etc. are included in the search result. To enable specifying to what extent a search string shall match with target strings, there are two additional components available in a Gellish Expression Format, being a left hand and a right hand string commonality. For example, in case of the above search on P-1 it will be ‘case insensitive front end identical’.

Further details about these string commonalities are described in the book ‘Semantic Modeling in Formal English’.

SPARQL and RDF

SPARQL is a query language that is especially made for querying databases that are formatted conform RDF, also called ‘triple stores’. As shown above, the semantics of questions and other expressions require more than just triples, such as units of measure and contextual facts. That is the reason why many implementation specify extensions of RDF to represent collections of triples, which are called ‘named graphs’ as is also applied in ISO 15926-11, which standardizes an RDF implementation of Gellish Formal English.

Extended RDF implementations of Formal English can use SPARQL directly. However, RDF itself defined a syntax and a minimum of semantics (it only defined a few concepts), just as SQL. This enables that in RDF expressions any relation type (‘predicate’ in RDF) and any left hand and right hand term (‘subject’ and ‘object’ in RDF) can be used. Thus everybody can use his or her own ‘namespace’ and own ontology. This powerful flexibility at the same time reveals the weakness towards interoperability, because of the lack of standardization of the language in which the database, message and query contents can or shall be expressed.

The expression of inserts and queries can be made database system independent only when an extended RDF is combined with a semantically rich language, such as Formal English. Such a combination provides a language that includes semantics as well as syntax (format).

Another question is whether the SPARQL syntax is to be preferred above the tabular Gellish Expression Format syntax as is used in Table 1 and Table 2. The commonalities and differences between these two formats can be illustrated on the SPARQL example query for a ‘foaf’ (friend of a friend) database http://en.wikipedia.org/wiki/SPARQL:

PREFIX foaf: <http://xmlns.com/foaf/spec/>
SELECT ?name ?email
WHERE {
  ?person a foaf:Person.
  ?person foaf:name ?name.
  ?person foaf:mbox ?email.
}

The above example shows that SPARQL also presupposes knowledge about the particular structure of the queries database. Although the structure of RDF expressions is database (data model) independent, this example demonstrates that this query is dependent on the structure of the foaf database and relies on the understanding of the content of the foaf ontology (http://xmlns.com/foaf/spec/), which includes a database structure (table definitions) with definitions of ‘classes’ (entity types) that have pre-defined ‘properties’ (attribute types). For example the class foaf:Person is not the same as the generic concept ‘person’, because the foaf ontology defines a foaf:Person as a person that has a number of predefined ‘properties’ (attributes) with specific names. Thus a foaf:Person is defined as a particular collection of ‘properties’. For example the foaf ontology pre-defines that a foaf:Person can have or has a surname, as well as e.g. publications and a currentProject, and inherits an mbox. Apparently the foaf ontology defines a very specific ‘language’ that cannot be merged with other ontologies/languages and thus the query will only work on a foaf database and shall be rewritten for any other database.

This demonstrates why the neutral form of Formal English expressions in Table 1 and 2 has advantages.

‘, 1, 0, 0, 17, ‘2014-09-13 11:21:06’, 240, ”, ‘2015-11-09 12:26:34’, 240, 0, ‘0000-00-00 00:00:00’, ‘2014-09-13 11:21:06’, ‘0000-00-00 00:00:00’, ‘{“image_intro”:””,”float_intro”:””,”image_intro_alt”:””,”image_intro_caption”:””,”image_fulltext”:””,”float_fulltext”:””,”image_fulltext_alt”:””,”image_fulltext_caption”:””}’, ‘{“urla”:false,”urlatext”:””,”targeta”:””,”urlb”:false,”urlbtext”:””,”targetb”:””,”urlc”:false,”urlctext”:””,”targetc”:””}’, ‘{“show_title”:””,”link_titles”:””,”show_intro”:”1″,”show_category”:””,”link_category”:””,”show_parent_category”:””,”link_parent_category”:””,”show_author”:””,”link_author”:””,”show_create_date”:””,”show_modify_date”:””,”show_publish_date”:””,”show_item_navigation”:””,”show_icons”:””,”show_print_icon”:””,”show_email_icon”:””,”show_vote”:””,”show_hits”:””,”show_noauth”:””,”urls_position”:””,”alternative_readmore”:””,”article_layout”:””,”show_publishing_options”:””,”show_article_options”:””,”show_urls_images_backend”:””,”show_urls_images_frontend”:””}’, 4, 0, 5, ‘query language, queries, insert, insertion, data manipulation language, database, system independent, interoperability, interoperable’, ‘Conventionally, dedicated query languages are used for insertions in databases and queries on databases. This article describes that Formal English expressions for insertions, queries, storage and exchange are all the same, so that no separate query languages are required. Furthermore it illustrates that conventional query languages cannot be used without detailed knowledge of the subject database, whereas Formal English expressions are independent of database structures.’, 1, 1587, ‘{“robots”:””,”author”:”dr. ir. Andries van Renssen”,”rights”:”Gellish.net”,”xreference”:””}’, 0, ‘*’, ”);
INSERT INTO `j25_content` (`id`, `asset_id`, `title`, `alias`, `title_alias`, `introtext`, `fulltext`, `state`, `sectionid`, `mask`, `catid`, `created`, `created_by`, `created_by_alias`, `modified`, `modified_by`, `checked_out`, `checked_out_time`, `publish_up`, `publish_down`, `images`, `urls`, `attribs`, `version`, `parentid`, `ordering`, `metakey`, `metadesc`, `access`, `hits`, `metadata`, `featured`, `language`, `xreference`) VALUES
(51, 101, ‘Semantic consistency verification’, ‘semantic-consistency-verification’, ”, ‘

Semantic consistency verification

Databases and data exchange files should be verified on the semantic consistency of their content. Semantic consistency verification checks whether collections of expressions contain redundant statements or statements that are in conflict with other statements. The verification possibilities and processes for the content of conventional databases, such as in relational (entity-attribute-relationship) data model instances, differ from the verification possibilities and processes for databases which content is expressed in a formalized natural language that is based on a defined taxonomy of concepts, such as Gellish Formal English. This article discusses the verification of several semantic consistency rules and constraints in formalized natural languages.
‘, ‘\r\n

Prerequisite: known typology (mandatory classification and generalization)

Kinds of relations define the kinds of things that are allowed to be related by such a relation. Thus related things shall be of kinds that comply with the definitions of the kinds of relations in which they are involved. Semantic verification therefore has two prerequisites: classification of individual things and generalization of kinds of things.

Classification of individual things

The first prerequisite is that individual things shall be of kinds that are allowed by the relations in which they are involved. This implies that the correct use of relations of particular kinds can only be verified when from all individual things it is known of which kind(s) they are. In other words:
– Every individual thing (including also individual aspects, properties and activities and individual relations) shall be classified at least once by a kind.
In semantic databases and data exchange messages that apply a formalized language, the requirement for classification of individual things implies that explicit classification relations are required. For example, by a statement such as: P1 <is classified as a> pump. Such explicit classification relations allows that the classifying kinds are selected from any kind in the dictionary of the language, including any of many subtypes. Thus classification is not restricted to instantiation in available attribute types. Furthermore, multiple explicit classification relations for the same individual things are possible and simple in a fomalized language, and all things can freely appear in many relations of various kinds, without the constraint that the related things shall be classified by the same kind. This means that classification in a formalized natural language is more flexible than classification in conventional databases and conventional data exchange files.

Generalization of kinds of things

Knowledge, requirements and constraints are typically expressed as relations between kinds of things. When those kinds of things are arranged in a subtype-supertype hierarchy (taxonomy), then the knowledge, requirements and constraints that are expressed for particular kinds are inherited to all the subtypes of those kinds. When individual things are classified by one of those subtypes, then this means that all the knowledge, requirements and constraints that are specified for its supertypes is inherited to the classifying subtype and thus is applicable for the classified individual thing.
Thus, to enable the verification whether individual things satisfy the knowledge, requirements and constraints, it is required that such a taxonomy is known. The second prerequisite for this verification is therefore that for all kinds of things (the classifiers of the individual things) mandatory generalization relations are required. In other words:
– Every kind (concept), including also every kind of relation, shall be defined by a specialization relation as a subtype of one or more supertype concepts (more generalized concepts).

Thus specialization-generalization relations between concepts enable that knowledge, requirements, constraints and definitions are inherited from supertype concepts to their subtypes, whereas the classification relations determine the individual things for which that knowledge and those requirements and constraints are applicable. Those are the reasons why classification relations and specialization-generalization relations are prerequisites for semantic verification.
Note 1: Formalized English can be applied without these mandatory relations, but then many semantic verifications are impossible.
Note 2: Conventional data models usually do not include a taxonomy (subtype-supertype hierarchy) of kinds. Thus then there is no taxonomy available for the determination whether specified knowledge, requirements and constraints are applicable for individual things.

For example, an individual thing that is denoted as Paris is used in an expression in a formalized language, such as ‘the Eiffel tower <is located in> Paris’. Thus the Eiffel tower and Paris are incorporated in the language. However, but the validity of their involvement in relations and the applicability of knowledge, requirements and constraints can only be verified when they are defined by classification relations. Thus, for example. Paris is classified as a city. The validity of that classification relation can only be verified when the concept city is a valid classifier. This can be determined by it being defined by a specialization relation as a subtype of the more generic concept that is by definition allowed to be a classifier in a classification relation. Thus the concept city should become an element in a subtype-supertype hierarchy (taxonomy). Some concepts in that hierarchy will appear in definitions of other kinds of relations as being allowed as players of roles of various kinds in such relations. For example, physical objects are allowed to play a role as ‘locator’ in <is located in> relations. This allowed role player role is inherited via the taxonomy e.g. by the concept ”city”. The classification of Paris as a city thus specifies that statements such as ‘the Eiffel tower <is located in> Paris’ are valid statements.

To enable the maintenance of a semantically consistent database, the following rule is applicable: If all classifications of an individual thing or all specialization relations of a kind are deleted or terminated (historicized), then that thing terminates its existence. In other words: then its being represented and being known in the language is terminated. Such a termination implies that all binary relations in which the thing appears shall be deleted or terminated (historicized) as well. This may cause a chain of deletions and terminations.

Redundancy – unnecessary duplicates

In Gellish Formalized English every thing shall have its own unique identifier (UID”s). Thus one thing may not have multiple UID”s, although every thing may have multiple names (synonyms). (Note that e.g. in RDF and OWL things may have multiple IRI”s in different namespaces; thus IRI”s differ from UID”s). Furthermore, the same name may be used for different things (homonyms), provided that the identical names are specified as having their base in different language communities (naming contexts).

This means that duplicate things are defined as things that are the same but that have different UID’s.

Such duplicates can thus be detected when different UID”s are denoted by the same name in the same language community (although they may appear not to be real duplicates when the identical names are caused by a naming error). Although it is difficult for software to detect proven duplicates (e.g. in case of twin baby’s), software can conclude that it is likely that different UID’s represent the same thing in the following situations:

When different UID”s are denoted by the same name in different language community contexts (homonyms), they are likely duplicates when they are individual things that are classified by the same kind (or by a near subtype of the other kind) or when they are kinds of things that are defined as being subtypes of (nearly) the same supertype. When they have the same name, but one is an individual thing and the other is a kind of thing then they are somewhat suspect. To reduce that chance it is recommended to denote individual things by names that start with a capital and to denote kinds of things by names that start with a lower case character.

When different UID’s are related to the same other role player, whereas playing roles of the same kind in relations of the same kind. This probability becomes stronger when cardinality constraints do not allow for that number of relations with the same role player. Note that the UID”s are not duplicates when they play roles of different kinds in a relation between each other (especially when another relation explicitly states that they are distinct things; e.g. when A and B are a daughter of C, whereas a relation states that A is a first born twin of B); or when a time difference of occurrences in which they are involved excludes that they are the same thing.

Duplicate binary relations are relations that relate the same two things (UID’s) by a relation of the same kind (or by a subtype of the other kind of relation), even if the names of the related things are different (synonyms), whereas the validity periods have an overlap.
For a duplicate higher order relation the same applies as for duplicate things. But in addition to that it holds that higher order relations are likely duplicates when each of them has involvement relations with the same involved objects, so that the same things are involved in two similar occurrences (activities) at the same time. However, this is not a proof, because occasionally the same object may be involved in two similar activities at the same time.

Note that in particular contexts databases might allow for the recording of different expressions of the same statements. For example, a database may record multiple identical opinions about the same topic expressed by different persons, possibly in the same language or in different languages. In those cases the things (UID’s) may still not be duplicated, because the expressions are about the same things. However, the expressions (utterances) should be distinguished from the statements (relations plus intention). In exceptional cases databases may allow for the recording that the same person expresses the same opinion several times. Then they are still not duplicate expressions, because they are expressed at different moments in time.

Consistent typology

Individual things can be explicitly be classified and kinds can have explicit specialization relations, whereas the fact that they are used in relations of particular kinds implies that they are (subtypes of) allowed kinds of role players for such relations. These various kinds should be consistent. This requirement results in the following rules:

Consistent typology (1): The language defining ontology defines kinds of relations by the kinds of roles that are played in such relations and by specifying which kinds of things are allowed to play such roles. This implies that it also specifies things of kinds that are not allowed to play such a role. Thus, individual things (which shall always be classified) may not play a role in a relation that conflicts with the kind that is required for its role player. Thus the kind of individual thing shall be identical or belong to the hierarchy of subtypes of the allowed kind of role player for the kind of relation.

Consistent typology (2): An individual thing may be classified multiple times by different kinds, and a kind may be a subtype of various supertype kinds. In both cases the kinds are subtypes of a nearest common ancestor kind. That nearest common ancestor kind shall be allowed as a role player in the relations of the kind in which that thing or kind is involved. The typology is inconsistent when one of the kinds is not allowed a relation of a kind in which the thing is involved.

Constraints and requirements verification

See also the related topic of modeling and verification of constraints and requirements.

Share this:

Leave a Reply

Your email address will not be published. Required fields are marked *