Remembering the Future

Dec 19 2003 Lars Marius Garshol | | What TM offers, IMHO, is a pattern where certain structure are | pre-defined. They happen to be convenient structures (I mean for | the type of modeling that we are likely to be interested in with | TM), but you can pretty much build them in RDF if you want to. That's true. However, there are things in topic maps like scope and reification that become very awkward to handle in RDF. You can do it, but there's no pretty way to do it. | But in RDF, it would be a matter of convention, and so an ordinary | RDF processor would not be able to understand and use those patterns | to good advantage. Yep. | This gives TM a lot of power for topic-map-like tasks. But if you | want to accumulate a lot of atomic facts, RDF is simpler. Also true, and I think this is pretty much the essence of the comparison. Topic maps are high-level, RDF is low-level. Compare the Omnigator and BrownSauce for one illustration of that. Lars Marius Garshol | | Consider a service that translates a topic map document, e.g., XTM, | into this internal model and the re-serializes it, e.g., as a | "consistent topic map" using the XTM syntax. I would say that this | is a "topic map processor". So would I. The plan is that ISO 13250-3: Topic Maps -- XML Syntax will pretty much say that, though it will word it differently. In other words: so long as you interpret the syntax correctly, and detect all invalid topic maps, you are a conformant processor. | Perhaps this was one of the points of the topic maps reference model | (or the topic maps processing model) -- that you can re-represent | the XTM syntax as a set of assertions using an ARCx (assertion node, | role node, casting node, player node). I know. Rik Morikaw fix