|
Duane
Chris Menzel was right in saying it's not that subtle.
The term type here refers to the abstract data type used to reify the concept -
for example, does one reify a latitude as a real number, a fixed precision
decimal number, or as a triple of integers for degree, minute, second.
This is distinct from the problem 3D v 4Dism that
Matthew referred to.
One of the problems I have not seen discussed much -
possibly because I have been looking in the wrong place - is the
relation in ontology languages between concepts and their reification,
as opposed to the relation between different concepts. For example, I would
regard 2D and 3D points as referring to different concepts, whereas Cartesian
co-ordinate systems v. polar co-ordinate systems for a 2D point
as different reifications of the same concept. Looking at languages
like OWL, it seems that the reification is identified with form
of the concept, as if there is only one way of reifying it.
Having two different reifications of a concept should
not be a major semantic challenge, the challenge is that, unless you account for
the different reifications, the systems cannot interoperate. However there may
be practical problems concerning the adequacy of the reifications. See, for
example, Cliff B Jones, "Systematic Software Development using VDM", Chapter 8
on Data reification for a more detailed treatment.
The converse is what John Sowa keeps insisting on, that
interoperation happens mostly at the level of middle ontologies. In this case,
there is some morphism between the reifications - or at least a subset of the
reifications - which can be used for interoperation. For example, there is a
simple morphism between points in Euclidean space and those in a homogenious
co-ordinate system. In one dimension this is
E(x) -> H(x, 1) and H(x, 1) ->
E(x).
This breaks down for points of the form H(x, 0), but
then Eucllidean spaces doesn't have a lot to say about points at
infinity.
Sean Barker
Bristol
From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Duane
Nickull
Sent: 09 March 2010 22:41
To:
[ontolog-forum]
Subject: Re: [ontolog-forum] Re Foundation ontology,
CYC, and Mapping
*** WARNING ***
This message has originated outside your organisation,
either from an external partner or the Global Internet.
Keep this in mind if you answer this message.
Sean:
For the second of these (conflicts when the
same concept is represented by different types), can you elaborate a couple of
examples (no hurry). I just want to make sure I have a good idea of this.
Duane
On 3/9/10 2:30 PM, "sean barker" <sean.barker@xxxxxxxxxxxxx>
wrote:
Apologies for slow response to a
couple of requests for sources on semantic incompatibilities.
This is the
table we generated internally, based partly on older database
work
Semantic Incompatibilities
Naming Conflicts When
objects representing the same concept may contain dissimilar names:
conflicts due to either homonyms or synonyms.
Type Conflicts When
the same concept is represented by different types.
Key Conflicts When
different keys are assigned to the same concept in different schema.
Behavioural
Conflicts
When different insertion/deletion policies
are associated with the same class of objects in different schemata.
e.g. deleting an object may leave an ?empty? object rather than a ?null
reference?.
Missing Data When
different attributes are defined for the same concept.
Levels of Abstraction When
information about an entity is stored at dissimilar levels of detail.
e.g. ?name? versus ?first_name? and ?last_name?.
Identification of Related Concepts For
example, two entities belonging to two different databases may not be
equivalent but one entity may be a generalisation of the other
entity.
Scaling
Conflicts
When the same attribute of an entity is
stored in dissimilar units.
it is based on/taken
from
[1]
Aykut Firat, Information
Integration Using Contextual Knowledge and Ontology Merging. MIT (Sloan
School of Management) Ph. D thesis, September 2003.
[1] M. P. Reddy, B. E. Prasad, P. G. Reddy, Amar Gupta, A
Methodology for Integration of Heterogeneous Databases, IEEE Transactions
on Knowledge and Data Engineering, Vol. 6, No. 6, December 1994.
There are
some other papers dating from the mid-nineties, but they have not survived my
various office moves.
Sean
Barker
Bristol
|