Common languages for databases

Common languages for database definitions and database contents Language defining ontologies I advocate to adopt and/or develop formalized natural languages for database design as well as for the harmonization of database content. Such formalized languages should be defined in language defining ontologies that are distinct from knowledge modeling ontologies (as I have explained in another more

Data types not needed

Data types are not needed I would like to defend the statement: Data types are not needed in semantic databases. In natural languages we use just strings of characters…, or are we using data types? Certainly we can classify character strings in natural languages e.g. as numeric strings, or numbers, decimal numbers, whole numbers, rational more

Two kinds of ontologies

Two kinds of ontologies: language defining and knowledge modeling Ontologies are models that express formalized knowledge (or requirements) in some application domain. Usually every organization creates its own ontology on the basis of its own business needs and domain knowledge. Creating your own ontology is often advocated because of differences in business needs. The general more

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 more

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 more

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 more