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 blog). Herewith I describe what the essentials are of a formalized language definition and thus of language defining ontologies. A language defining ontology should include . . .
Unique identifiers, synonyms and homonyms It is widely recognized that there is a difference between things (or concepts) and the various names by which those things can be denoted. Nevertheless, in databases and date exchange messages, things are usually denoted only by names, which results in interpretation problems and difficulties for interoperability of systems and for data integration. This can be solved by using a formalized language within which unique identifiers represent the things (including also concepts, aspect, relations, etc.), . . .
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 numbers, negative numbers, text strings, dates, etc., depending on the kinds of characters that are used and whether particular conventions are obeyed. However, in the . . .
Two kinds of ontologies: language defining and knowledge modeling Ontologies are models that express formalized knowledge (or requirements) in some application domain. Typically 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 theories about how ontologies should be created unfortunately have not (yet) resulted in an agreed and common ontology development process. As a consequence, the resulting . . .
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 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 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 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 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) 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 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 . . .