Remembering the Future

Warning: many of these comments need to be taken within the context of the original messages (see links). Jan Algermissen [added from another thread for context] "Occurrences are essentially a specialized kind of association,..." (5.7) "Essentially, a base name is a specialized kind of occurrence,..." (5.5) Then you say it is ok and common practice to use occurrences to represent properties. In addition there are specialized properties in the model (subjectAddress, SubjectIndicators, SourceLoactors) that are *NOT* represented as occurrences. Why are all the specialisations in place? Why not use associations for everything since all the other stuff is *essentially* just an association? I see absolutely no reason for all the specialized items. Can you tell me (and hopefully convince me) why they are there? . . . > > So, why is the model more complex than it needs to be? > > > > Because if you don't you end up with RDF. Sorry, thats a flippant > answer. Please keep RDF out of here....it is really so different and has nothing to do with what I am talking about. . . . Well, you can simply get the core semantics by a core set of association types and simplyfy the model by throwing out occurrence and basename. IOW, if this can be done for class-instance and superclass-subclass (both are part of the core semantics, yes?) why for those and not for occurrence and basename? It would only make the model simpler. Isn't that a reasonable goal for a standard? Mourad OUZIRI Hello world, What are the advantages of the Topic Maps compared to RDF, RDF Schema and DAML in term of representing data/resource semantic ? Thank you in advance Thomas Schwotzer Try this: http://www.ontopia.net/topicmaps/materials/tmrdf.html Jack Park This, because I think there is a bit of tribal behavior going on and I also think that, sometimes, the two tribes (topic maps/RDF) don't really understand each other. First, a snippet of background as a means of revealing my own bias that both tribes belong on this planet and both need to learn to work with each other. I come to this point of view by means of my own work which has evolved to the suspiciion that I can perform such miraculous things as walking on water if I build a persistence mechanism which uses triples as the underlying abstract engine, and build what I call "cassettes" (read: cartridges, if you're an Oracle jockey) which perform the mappings between the many graph dialects which now or will exist 'out there' in knowledge manipulation land. * Lars Marius Garshol | | If you replace RM with TMCL here you've got it. RM itself is much | closer to what you said about RDF: RM "absent an [application] is just | a graph language, like GXL. It has almost no built-in semantics." It | certainly isn't a schema language. * Murray Altheim | | ...every possible opportunity to minimize the importance of the RM | it seems... why not give *that* a rest? Because I stand by what I said. The RM is not a schema language, and I think its creators would be the first to admit that it is not. I think they would also approve the rest of what I've said, given that they've by their own admission gone to great lengths to keep the ontological commitments of the RM to a minimum.