Unique identifiers – synonyms and homonyms

Unique identifiers, synonyms and homonyms It is widely recognized that there is a difference between things (concepts, aspect, relations, etc.) and their various denotations, such as terms or names, abbreviations and codes. In practice, database systems and date exchange messages use different terms to denote the same things (synonyms) and the same term denotes different things (homonyms). This results in interpretation problems and difficulties for interoperability of systems and for data integration. This can be solved by using a formalization . . .

Data types not needed

Data types are not needed I would like to defend the statement: Data types are not needed in semantic databases, provided that the meaning of each concept is unambiguously captured in its unique identifier. In natural languages we use just strings of characters, so, why would we use data types when storing data in computers? Certainly can infer a classification of character strings in natural languages. For example, we can distinguish as numeric strings, or numbers, decimal numbers, whole numbers, . . .

Two kinds of ontologies

What is an ontology? An ontology is a coherent expression of knowledge about some application domain. Ontologies are increasingly expressed in a computer interpretable formalized language, such as in Gellish English. An ontology is an extension of a (taxonomic) dictionary that includes relations of additional kinds between the defined concepts. A taxonomic dictionary is an extension of an ordinary dictionary that includes subtype-supertype relations between all defined concepts. Organizations may create their own ontology describing their proprietary knowledge. Unfortunately however, . . .

Constraints and requirements

Constraints and requirements modeling and verification

Databases and data exchange messages may contain specifications of constraints and specifications of requirements for information. Those constraints and requirements specifications may also be used to verify whether the same or other databases and data exchange messages satisfy those constraints and requirements. This article introduces the modeling and verification of various kinds of them.

. . .

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

Dialogues, inserts and queries in one common language

Dialogues, inserts and queries in one common language Computer interpretable dialogues among various parties require that assertions, queries, answers, denials, etc. are expressed in one common language. This article describes how that can be achieved. In natural languages, queries and assertions have nearly the same structure and use the same terminology. Thus the sentences used for assertions and questions are only slightly different. The differences, such as changes in word sequences and the use of question marks, can even be . . .

Database design – a new approach

Database design – a new approach Conventional database development and modification requires that first a physical data model is created or modified, from which the database tables are generated, before those tables can be loaded with ‘instances’. The physical data model tables then specify what can and cannot be expressed, because the tables are the templates for the possible expressions and what cannot be instantiated in those tables cannot be expressed in the database. (Note that in fact this defines . . .

Modeling by binary relations

Modeling by binary relations In conventional data modeling usually various attribute types that provide information about the same kind of thing are grouped into entity types (or ‘object types’). As a consequence of that higher order relations (tables) are created. However, many of those higher order relations must be changed when business requirements change. Thus most conventional data models have structures that are business requirements specific.

Modeling of higher order relations (N-ary relations)

Modeling of higher order relations (N-ary relations) Conventional ‘entities’ with their ‘attributes’ are usually higher order relations, because they relate more than two ”attributes”. Some of such relations appear to be natural higher order relations, whereas others appear to be artificial higher order relations. Higher order relations can also be represented by equivalent collections of binary relations, while explicitly including the higher order relations as elements in the model and nevertheless using only binary relation to express their semantics. Thus . . .

Modeling of change over time

Modeling of change over time In conventional methodologies, modeling of change over time is often difficult or even ‘not supported’. Semantic modeling provides easy modeling of change over time. This is caused by the following difference: when the life of a relation in a conventional model is terminated (the relation is deleted) the consequence is that the entity (and the attributes) do not exist anymore. However, when the life of a relation in a semantic model is terminated, then the . . .