ONT Re: Data Models, Ontologies, Logic
o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o
JA = Jon Awbrey
JF = Jim Farrugia
MW = Matthew West
JF: A few comments below. I hope this is complementary to a message
John Sowa sent to the SUO list over the weekend, which discussed
the notions of data models and ontologies.
MW: Data Model, a structure of types and relations against
which instances of the types and relations can be stored.
Definitions of the types and relations are in natural language.
Some constraints are defined, usually in terms of the cardinality
of relationships.
JA: I am not comfortable with the term "data model",
and I would tend to shy away from it due to all
of the confusion that we already have about the
polysemantic word "model", but maybe I will get
used to it over time.
JA: There are all sorts of names for "what you do to define
a dataset before you get down to putting data into it",
and if that is roughly what you are talking about, then
I think I know what you mean. I used to use a variety
of different names for this, depending on the software
of the moment, but they all seemed to cluster about
words like "scheme", "specification", "structure".
JA: Is that anything like what you mean by "data model"?
I will stop to see if we are on the same page here,
and then we can back up or progress from there.
JF: Here is one definition, which may not be perfect,
but which may help us get on the same page. The
phrase "data model" is widely used; I think it's
something to get used to.
| A data model is an abstract, self-contained, logical definition
| of the objects, operators, and so forth, that together constitute
| the abstract machine with which users interact. The objects allow
| us to model the structure of the data. The operators allow us to
| model its behavior.
|
| Source: An Introduction to Database Systems, Seventh Edition
| by C. J. Date. Addison Wesley Longmann, 2000, p. 14.
I would call this "operational semantics".
I am a pragmatist about that.
But I do find that people's
sense of "widely used" can be
rather narrowly defined, and
I have to ask whether the next
physicist or psychologist that
I talk to will be able to guess
this definition. Probably not.
So it may be necessary to take this into account
if we want to keep talking to samples of such folks.
Usages that we can maintain within a specialized
discipline are not always possible to maintain
in wider communities of discourse and inquiry.
There's a name for that.
If we want to keep getting data from a sample of such folks,
and, by the way, not to forget that not all data is machine,
then it may be necessary to keep an open mind here.
JF: The above may make more sense after reading the following,
which I've reformatted slightly:
| -----------------------------------------------------------------------
|
| Users -- who may be people as well as programs -- interact with a database
| using the interface it provides. The abstraction provided by the interface
| is called the logical level of the database. Data is represented here using
| a data model.
|
| Intuitively, a data model provides a uniform way to organize
| and manipulate data. Examples of data models are the relational,
| hierarchical, network, entity-relationship, and object-oriented
| models.
|
| By far the most popular remains the relational model, in which data
| is presented as a set of tables. Each table is identified by a name;
| columns also have names, called attributes.
|
| The structure of the tables in a relational database,
| given by their names and attributes, is referred to as
| the database schema. The schema provides the ``skeleton''
| of the database, without its data.
|
| The content of each table at any given time is a set of tuples -- a relation.
|
| The relations contained by the tables form an instance of the database.
|
| Data manipulation capabilities provided at the logical level include
| a query language (used to extract information from the database) and
| an update language (used to modify the content of the database).
|
| A relational database schema is essentially a first-order vocabulary
| without function symbols or constants.
|
| A database instance can be viewed as a finite relational structure
| providing a finite interpretation for the vocabulary.
|
| This analogy is the basis for the connection between databases and
| finite-model theory. "
|
| author = "V. Vianu",
| title = "Databases and finite-model theory",
| text = "V. Vianu. Databases and finite-model theory. In N. Immerman
| and P. Kolaitis, editors, DIMACS Series in Discrete Mathematics and
| Theoretical Computer Science, vol. 31, pages 97-- 148. American
| Mathematical Society, 1997.", year = "1997",
| url = "citeseer.nj.nec.com/5334.html"
|
| -----------------------------------------------------------------------
JF: I agree with Jon's comments in another posting that Matthew's use
of the terms "Taxonomy" and "Thesaurus" are [probably] not standard.
JF: But I think that on the notion of "data model" Matthew is rather on
target, especially if the two quoted passages above can be taken as
reliable guides to that notion.
All of this is very familiar to me, some of it under other names.
But the real problem that I noticed throughout my years in this biz
was finding ways to build bridges, not only between different styles
of datasets -- deductive, qualitative, raw, statistical, and so on --
but between the users possessed of -- and by -- different mindsets.
Certainly enough for a start, though.
Jon Awbrey
o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o