ontolog-forum
[Top] [All Lists]

Re: [ontolog-forum] Avoiding Hobson's Choice In Choosing An ntology

To: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: Patrick Durusau <patrick@xxxxxxxxxxx>
Date: Sun, 30 Apr 2006 10:52:42 -0400
Message-id: <4454CF3A.4060203@xxxxxxxxxxx>
Matthew,    (01)

Replies on the portions of your post I did not reach yesterday.    (02)

West, Matthew R SIPC-DFD/321 wrote:    (03)

>Dear Colleagues,
>
>I was unfortunately not able to attend this talk, but Peter asked
>me to comment on it. So here goes.
>
>The talk essentially proposes Federating ontologies (rather than
>integrating or merging them) and using Topic Maps for the purpose.
>  
>
I may be misreading your post so apologies in advance but I get the 
impression that you are implying that ontological structures when 
represented in a subject map have some status unlike those of other 
subjects.    (04)

While it is certainly true that the TMRM enables that sort of 
representation of ontological structures, it is not the case that the 
TMRM compells it. In face, from the standpoint of the TMRM, all subjects 
and their representatives (subject proxies) enjoy the same status as far 
as the TMRM is concerned.    (05)

In other words, if I were to choose to represent SUMO, Cyc, or any other 
ontology in a subject map, their representatives would be subject to 
merging rules just like any other subject that I choose to represent in 
the subject map.    (06)

One point that raised a question in the presentation was the nature of 
keys in the key/value pairs that are the properties of subject proxies.    (07)

A "key" is by its very nature a reference to a subject proxy that 
represents that subject. That is to say the "machinery" itself is 
represented by subject proxies in a subject map.    (08)

Unlike any of the systems of whicih I am aware (being mindful I have to 
refresh my memory on ISO 18876), subject maps enable the machinery 
itself to be represented by proxies in a subject map. In other words, in 
order to integrate information about a particular set of subjects, I 
need not start of with ISO 18876 or any other particular system for the 
information I wish to integrate.    (09)

Why? Because the subjects of the machinery itself can also be 
represented by subject proxies. There is no privilege, aside for a user 
designing a system to allow them, that prevents the representation 
merging of even the machinery as subjects.    (010)

>Federation is nothing new, and you don't need Topic Maps to do it
>(though it is one way). Federation basically says that you can map
>(interface) different ontologies instead of merge/integrate them.
>
>  
>
Yes, there are a number of ways to integrate information, but the 
question that subject maps answer is how to integrate those systems?    (011)

In other words, say that three different systems are picked to integrate 
information by members of this list. And they integrate related 
information that we then wish to integrate from the three groups. 
Outside of subject maps the only way to accomplish that task is to 
translate/transform each of those separate efforts into a common system.    (012)

Which of course loses the perspectives that were represented in the 
individual systems.    (013)

What Jack and I were attempting to present was a method that allows the 
subjects in each system to be preserved even though they had been 
integrated, on the basis of the subjects they represent.    (014)

A subject map merges the descriptions of diferent subjects, which in the 
case of ontologies results in their "federation" since the properties 
ascribed to any subject persist into the merged proxies. Well, more 
accurate to say that Jack and I were proposing merger that had that as a 
characteristic. You can have any merging rules you like.    (015)

>This is of course true. There are however disadvantages, in that
>you have to "hop over" into another ontology to do the things it
>does, so you can find yourself having to understand multiple
>ontologies, rather than just your favourite one. The overall
>capabilities are also more limited, since not everything is visible
>everywhere.
>  
>
I am not sure what you mean by '..."hop over" into another ontology..." 
so it would be helpful if you could say a bit more about that issue.    (016)

I think that is where I got the impression that you were treating 
ontologies as having some different status from other subjects. What you 
find at a subject proxy is all the descriptions of that particular 
subject. From whatever ontologies have been merged.    (017)

Recall that the merging that Jack and I were describing is based upon 
the subjects that are being represented and so when you arrive at a 
subject proxy, atom in the example we gave, you have all the information 
about that subject. Which includes the properties that subject has in 
the respective ontologies.    (018)

At a minimum you have all the information about a given subject, 
whatever ontology was used as the basis for the entry of that information.    (019)

It is not clear why you say "...overall capabilities are also more 
limited, since not everything is visible everywhere." What information 
is visible at any given subject proxy is a matter of design and I don't 
doubt there will be poorly designed subject maps. But I am hopeful that 
nothing in the TMRM compells the construction of poorly designed subject 
maps.    (020)

Recall that keys are references to other proxies so for whatever 
properties are recorded at a subject proxy, there is a mechanism that 
allows for the description of those subjects as well (including values).    (021)

>History shows that we integrate as much as we can, and then
>interface between the bits we can't (don't have time) to integrate.
>It is the old islands of automation story, with interfaces between
>the islands where you continuously try to make the islands bigger. 
>Federation tries to make this a virtue. I was always
>expecting that we would federate the main ontologies, but with 
>some integration/cross over as well.
>
>  
>
Sorry, I am not sure of your distinction between federation and 
"integration/cross over." If you could say a few words about that it 
might be helpful.    (022)

Jack used the term federation, I think, to distinguish subject maps from 
approaches that result in the translation/transformation of one ontology 
into another.    (023)

In other words, the properties of subject "a" in ontology A and the 
properties of the same subject in ontology B could be merged into a 
single subject proxy, where the properties of the subject from the 
respective ontologies are preserved. In other words, if I get to subject 
"a" via ontology B, I will see all the properties not only of the 
respective ontologies but other information that was recorded for that 
subject, whether under ontology A or B.    (024)

The important point of federation being that I have not lost the 
information about how that subject was identified in either ontology, 
which would be the case were I forced to map to a reference ontology, 
which is another way to integrate information.    (025)

>If you want a different view on this, I could give a talk on
>ISO 18876 - integration of industrial data for exchange access
>and sharing (IIDEAS). This provides an architectural framework
>for integrating/federating and what it involves.
>
>  
>    (026)

I for one would enjoy such a presentation but being a standards sort of 
person I suppose that is not surprising. ;-)    (027)

Note my comments above on being able to represents the subjects of the 
architectural framework itself with subject proxies, which enables 
merging of the framework with any of the other frameworks which exist 
for that purpose. All while preserving the information about the 
individual frameworks.    (028)

>I don't follow the worked example they have from the slides, but
>it looks a little simplistic to me. Also, to form aribtrary mappings
>my experience is you need FOL, and Topic Maps falls short of this,
>so I would expect some limitations to what could be mapped.
>
>  
>
As I noted in the presentation, the worked example was on the simple 
side simply to fit it onto the slide format and to allow for explanation 
of the material within the time allotted.    (029)

There was discussion following the presentation about exploring the use 
of subject maps in the effort to "ontologize" the Ontolog website. Both 
Jack and myself are very interested in that prospect and I think very 
early in that process we will have more than enough complex examples. 
One of the problems with complex examples is that is you are not a 
member of the community for who the example is meaningful, then the 
complexity aspect defeats conveying the basic principles.    (030)

Hmmm, still, it is a valid criticism. Jack and I will be working on the 
examples later in May and as work goes forward on the Ontolog site, I 
think we can endeavor to create examples that start with fairly 
"simplistic" examples and then expand those to more complex examples. 
The easy ones to simply get the principles down and perhaps establish a 
color coding that makes the argument easier to follow and then do the 
same but with more realistic examples.    (031)

Hope you are having a great day!    (032)

Patrick    (033)

-- 
Patrick Durusau
Patrick@xxxxxxxxxxx
Chair, V1 - Text Processing: Office and Publishing Systems Interface
Co-Editor, ISO 13250, Topic Maps -- Reference Model
Member, Text Encoding Initiative Board of Directors, 2003-2005    (034)

Topic Maps: Human, not artificial, intelligence at work!     (035)


_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Subscribe/Unsubscribe/Config: 
http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/ 
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx    (036)

<Prev in Thread] Current Thread [Next in Thread>