ONT RE: Data Models, Ontologies, Logic
Dear Jim,
The best definition I know of "data model" is "the structure and
meaning of data". This is some distance from the ones you offer
below. See below for specific comments.
Matthew West
Principal Consultant
Shell Information Technology International Limited
Shell Centre, London SE1 7NA, United Kingdom
Tel: +44 20 7934 4490 Other Tel: +44 7796 336538
Email: matthew.r.west@is.shell.com
Internet: http://www.shell.com
> -----Original Message-----
> From: Jim Farrugia [mailto:jim@spatial.maine.edu]
> Sent: 28 May 2002 19:12
> To: Jon Awbrey
> Cc: Ontology; West, Matthew R SITI-ITPSIE; sowa@bestweb.net; Jim
> Farrugia
> Subject: Re: Data Models, Ontologies, Logic
>
>
> Jon and Matthew,
>
> 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.
>
> Jim
>
>
> JA - Jon Awbrey
> > JF = Jim Farrugia
> > MW = Matthew West
> >
> > 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.
> >
> > 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".
> >
> > 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.
MW: This seems to be how data is represented and processed, rather than
anything to do with a data model (aka entity-relationship model).
>
>
>
> --------------------------------------------------------------
> ---------
>
>
> 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.
MW: Well this confirms my suspicions above. Just another use of the
term, and not the one used by people who design databases.
>
> 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.
MW: Now this schema is what we would call a physical data model
(generally just "data model" implies "logical data model"). The
logical data model is developed first, and then mapped onto/into
a physical data model, that will depend on the processing in the
application as well as the information requirements.
>
> 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.
>
> 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.
>
>
> Jim
>
>