Sean,
Just a response to one of your points, on conversion of info from one
model to another:
> Since in practice, any system is only a partial representation of its
> domain, and therefore will be described by a partial ontology, there
> exist two further problems:
> - How to identify the subsets of OA and OB for which the transformation
> can be defined;
> - How to identify subsets of OA and OB that in principle cannot be
> mapped to each other because of differences in the bases.
> (There is also the occasional row over whether it is possible to
> construct a single ontology that can form the basis for all domains.) (01)
I do believe that constructing such an ontology is practical -
specifically, to construct a foundation ontology that contains (at any given
time) all of the primitive elements that are required to provide an accurate
**translation** (via the foundation ontology) of data in one database/model
to data in another (at any given time). I call that the "Conceptual
Defining Vocabulary" (CDV): those who prefer to reserve the term
'definition' for necessary&sufficient conditions won't like that label, but
in this phrase I am using the term 'defining' in a more general sense closer
to (but not identical with) the *dictionary definition* sense; in the
ontology case it means "to create a logical specification with sufficient
detail to be adequate to serve the intended applications".
The number of basic concept representations required to serve as a CDV is
as yet unknown, and will in any case likely expand (slowly, I expect) as new
fields are specified with respect to the foundation ontology that serves as
the CDV. At present I expect the foundation ontology/CDV to have at least
6000 elements. That estimate is based on the number of elements that appear
likely to be necessary to represent the Longman's dictionary defining
vocabulary - a project I am currently working on.
The practicality of that approach is an important issue. I have only a
little experience to work from, but thus far it appears that the time
required to retroactively map some given relational database to a foundation
ontology will be comparable to the time required to create the relational
database in the first place. So this approach to database integration may
be used mostly when new databases are being developed, to minimize the cost.
Integration of legacy databases will also be possible, but only if it is
important enough to justify the expense. It may also be cost-justified to
integrate legacy databases via an ontology at the time that the databases
are being refactored or converted into a DB warehouse for other purposes.
Legacy databases are very important, but if we take a longer view and
imagine that in, say, twenty years, *most* databases in use will be newly
created or refactored in that interval, it appears quite practical.
If one takes the approach (e.g., supported by Ontology Works) of building
one's databases from the start by creating the conceptual model as an
ontology, and then using their tool to automatically create the database
from that, it should be as cost-effective as using a traditional database
creation process. For the databases to interoperate, however, still
requires that a common foundation ontology be used, and that that foundation
ontology should have all of the basic elements needed to represent and
translate all of the data elements in the databases. The range of
interoperability will depend only on how many different data managers decide
to use the same foundation ontology. (02)
Pat (03)
Patrick Cassidy
MICRA, Inc.
908-561-3416
cell: 908-565-4053
cassidy@xxxxxxxxx (04)
> -----Original Message-----
> From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx [mailto:ontolog-forum-
> bounces@xxxxxxxxxxxxxxxx] On Behalf Of Barker, Sean (UK)
> Sent: Friday, May 23, 2008 5:27 AM
> To: [ontolog-forum]
> Subject: Re: [ontolog-forum] Data Models v. Ontologies (again)
>
>
> This mail is publicly posted to a distribution list as part of a
> process
> of public discussion, any automatically generated statements to the
> contrary non-withstanding. It is the opinion of the author, and does
> not
> represent an official company view.
>
> Thanks to John and all for their comments.
>
> John Sowa wrote"
> I'd replace the phrase "assumes a set of entities" with the
> > phrase "assumes an ontology". That makes it clear that some
> > kind of ontology is required for data modeling, but it's not
> > the only one."
>
> Recasting the discussion into pseudo-linear algebra (I'm a
> mathematician
> by trade):
>
> Databases A, B have data models MA, MB where, say, MA ={e1, e2, e3,...}
> for some set of entities ei. The basic data exchange problem is to
> construct a transformation T[AB] s.t.
>
> B' = A.T[AB] + B (B is updated by a translation of the data from A)
> where also MA.T*[AB] = MB (the translation of data is equivalent a
> translation of the data model)
>
> The problem for data exchange is that every transformation T[AB] must
> be
> hand crafted.
>
> One could rewrite a data model MA in terms of an ontology OA, such that
> the ontology OA defined by a basis of ontology classes {o1, o2, o3...}
> where every entity in the model has some representation on the ontology
> (or at least, every entity in the domain covered by the system, but not
> necessarily entities needed for the mechanics of the system).
>
> The claim for ontologies seems to be that given ontologies OA and OB,
> the transformation T[AB]can be <i>automatically</i> constructed.
>
> The basic problems for ontology are therefore:
> - How to define the basis elements oi to enable this to be done;
> - How to ensure that the set of basis elements oi are consistent;
> - How to ensure that the set of basis elements oi are complete w.r.t.
> the domain;
> - How to construct an orthogonal basis, such that any data model entity
> has a unique representation in oi;
> - How to construct the transformations T[AB], ensuring the construction
> terminates, or that it terminates within a given time;
>
> Since in practice, any system is only a partial representation of its
> domain, and therefore will be described by a partial ontology, there
> exist two further problems:
> - How to identify the subsets of OA and OB for which the transformation
> can be defined;
> - How to identify subsets of OA and OB that in principle cannot be
> mapped to each other because of differences in the bases.
> (There is also the occasional row over whether it is possible to
> construct a single ontology that can form the basis for all domains.)
>
> In practice, many discussions are framed in terms of particular
> representations of an ontology, so two other sorts of problem appear:
> - How to create transformations between different representations of an
> ontology;
> - How to define a meta-ontology that characterises the representations,
> such that the transformations between representations may be
> constructed
> automatically (shades of IDRIS).
>
> Put in this way, it seems obvious (to me at least) that
> a) Ontology studies in themselves are a sub-branch of
> mathematics/logic, being concerned with the properties rather than the
> content of an ontology;
> b) The metaphysics which forms the design criteria for the basis
> classes (the content) of an ontology is a branch of philosophy;
> c) Knowledge engineering is engineering in so far as it has a
> theoretical basis in ontology structure, however much of it is a craft
> working in applied metaphysics.
> d) Data modelling is a craft, since it is not based on ontology
> studies.
>
> Conversely, if something is entirely hand crafted so that the structure
> cannot be formally analysed, then its a data model, no matter what
> language it is written in.
>
> Sean Barker
> BAE SYSTEMS - Advanced Technology Centre
> Bristol, UK
> +44(0) 117 302 8184
>
> BAE Systems (Operations) Limited
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace
> Centre, Farnborough, Hants, GU14 6YU, UK
> Registered in England & Wales No: 1996687
>
>
> ********************************************************************
> This email and any attachments are confidential to the intended
> recipient and may also be privileged. If you are not the intended
> recipient please delete it from your system and notify the sender.
> You should not copy it or use it for any purpose nor disclose or
> distribute its contents to any other person.
> ********************************************************************
>
>
> _________________________________________________________________
> Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
> Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontolog-
> forum/
> Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
> Shared Files: http://ontolog.cim3.net/file/
> Community Wiki: http://ontolog.cim3.net/wiki/
> To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx
> (05)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (06)
|