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)
|