[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [geolang-comment] First proposals for ISO 639 and 3166 available
Lars Marius Garshol wrote: > * Murray Altheim > | > | "710" is not an information resource relevant to the country South > | Africa, > > I don't see how you can dispute that. Name strings are information > resources, and they are clearly relevant to the things the name. So > names are a specialization of occurrences. Your conclusion does not logically follow from your thesis for a number of reasons. Non-transitivity of instance-of relations and such. Everything in the Web world can be considered an information resource. Since every part of an XTM/XML document is addressable, it can be considered an information resource. Therefore, name strings are certainly information resources, *and* can be certainly considered "relevant" to the things they name, but relevancy here is ambiguous. All components of a topic might be considered by the same token "relevant" to a topic. We are trying to disambiguate those components. The definition of "occurrence" obviously is pretty ambiguous if taken as just that first sentence, and not the whole spec. In the topic map model names are not occurrences of the topic, they are the names (or labels) of the topic. Do you not make any distinction between a topic name and a topic occurrence? If your argument were correct, everything in a topic map, being resources, could be some specialization of occurrence of a topic. We could have designed topic maps so that there were no topic names, that topic names were simply an occurrence within the scope of "topic name." That's not how it was done, nor does that make sense within the topic map model. Steve Pepper's "The TAO of Topic Maps" [TAO] says that an "important point to note here is the separation into two layers of the topics and their occurrences. This separation is one of the clues to the power of topic maps [...]." While it is possible that occurrences can be within a topic map, the point of topic maps is really to map that external territory, ie., the separation. > | it is a coded name for that country, the context (or scope) of that > | name being within the set of codes as published by the UN. > > What's your definition of 'name', then? A name is a way of referring to a topic within a specified scope. An occurrence of a topic is an addressable information resource that is, yes, relevant to the topic's subject, but is not a way of referring to a topic, but the thing that the topic is referring to, the thing being mapped. You use the name to locate the topic, you use the topic to locate the occurrence, ie., the resource. I don't think the definition of "name" in the scope of topic maps is in question, as it seems to be represented in ISO 16250, XTM 1.0, and in proposals for the TM model in very similar language. Conceptually, I don't see conflict. I'm not interested in entering into a debate over nominalism vs. realism here. I hope this is not meant as a philosophical discussion. While Bernard and you and I may agree philosophically on this issue, that's not really germane to the subject at hand. We're not here to reinvent the topic map paradigm. > | I think the XTM specification is starting to be read like the bible, > | wherein one can seemingly prove anything. > > True, and that's why we are replacing it. When the Protestant Reformation occurs and you publish your New Testament, I'll likely stay a Catholic if it causes all existing software to break. I hope the changes are by way of clarifications, not redefinitions. > | In this instance it should be remembered that occurrences in the > | topic map paradigm are meant to be out in the world, not in the > | map. Names of topics reside in the map, and "710" is an alternate > | name for "South Africa", not an occurrence of a resource about South > | Africa. If we begin populating our topic maps' occurrences with > | things that should be in the map, where will the "real" occurrences > | live? The clean separation between map and territory mapped is lost. > > Sure, but who says topic maps are about that separation? As far as I > know, only you. Personally I don't agree that that is a consideration > in this case. Then perhaps you should talk to Steve Newcomb and Michel Biezunski. If you can't do that, read Jack and Sam's book, which has a chapter written by Steve on this subject. During one of the TopicMaps.Org AG meetings, Steve N. drew a diagram of a big gulf between that map and its territory, his whole point about global information interchange being reflected in how humans attempt to represent knowledge being the need to bridge that gulf, and that topic maps attempt to do just that. Ask Steve P. about it, I believe he was there. Or look at Steve Pepper's [TAO] or Steve N's [SN] Michel Biezunski's diagrams [MB] showing topic occurrences being down in "the territory" (eg., the Web), with names and the associations (interrelations) between topics being up in the map. Is there some difficulty in understanding why topic maps attempt to create a bridge between the map and the territory? It's reflected in everything that topic maps have been about since the beginning. It's why they're called maps. I'm not sure how we're disconnecting here, as these definitions are hardly mine, nor do I think I'm alone in my understanding of them. Murray [TAO] "The TAO of Topic Maps: finding the way in the age of infoglut" Steve Pepper, XML Europe 2000. http://www.gca.org/papers/xmleurope2000/papers/s11-01.html#N20068 [MB] "Understanding Topic Maps", Michel Biezunski. http://www.infoloom.com/whitepaper.htm [SN] "Topic Maps and XTM: A Manager's Overview" Knowledge Technologies 2001, Austin, March 5 2001. Steve Newcomb and Michel Biezunski. http://www.topicmaps.net/tm4managers/Slide17.JPG ...................................................................... Murray Altheim <http://kmi.open.ac.uk/people/murray/> Knowledge Media Institute The Open University, Milton Keynes, Bucks, MK7 6AA, UK
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC