FrontPage SiteMap RecentChanges HowTo Blog

Matching Pages:

RSS

Hungary, National Day

TopicMap

An ISO standard intending to provide back-of-the-book indices for hypertext. An introduction may be found at:

http://www.ontopia.net/topicmaps/materials/tao.html

Represents the structure of information resources (called Topics) that act as proxies for subjects (such as “dancer”, “Fred Astaire” or “dancing”), and relationships between those Topics (called Associations). Has standardized machinery for keeping clear the distinction between an object and, say, a web site having to do with the object (i.e. RDF is a standard, and here is a webpage with the spec). Was first conceived as a way to solve the problem of indexing hyperdocuments in an extensible, mergeable way. A "gentle" introduction to the concepts of Topic Maps, written by one of the clearest thinkers from the SGML community (who unfortunately remains anonymous) is included in the XTM 1.0 spec.

http://www.topicmaps.org/

If you understand RDF a little bit, it may be easier to learn about topic maps through their relation to RDF. See TopicMapsVsRDF. A good paper comparing and contrasting RDF and TopicMaps:

Living with topic maps and RDF

A wiki:

http://www.easytopicmaps.com/

dead link

CategoryWebTechnology

Discussion


These comments were originally parts of comments from TopicMapsVsRDF.

You can’t “do” Topic Maps in RDF without implementing the complete set of Topic Map semantics (adding a layer above RDF) and building a processing model compliant with the paradigm. Then you’d be implementing Topic Maps. XTM and RDF are just markup syntaxes. XTM isn’t even a representation of a Topic Map, it’s an interchange syntax (this leads people to think that they can edit an XTM file with a text editor – you can’t, at least not safely).

Topic Maps don’t operate at the syntax level, they’re a paradigm (in the words of its inventors). Now, some of us got together and created an XML interchange syntax for Topic Maps, and called it XML Topic Maps XTM. But XTM is just one possible Topic Map syntax; one could implement Topic Maps using any suitable technology. The formal model for Topic Maps is not included in its ISO Standard, and people are still arguing today over some of the details. Simply put, a Topic Map document is two things: (1) an internal graph structure; and (2) a map. I’ll try to explain this below. Bear with me.

A Topic Map is a graph, a complex one, that can be for convenience’ sake thought of as a document, which gives it boundaries. Its internal graph structure is composed of two fundamental kinds of things: Topics, and Associations between Topics. Some have even proposed that everything can be thought of as a Topic, and while that may be epistemologically correct, I think in practice it’s a reducto ad absurdem. Since this is all abstract representation, you can think of Topics and Associations as nodes and edges, or in any other way people describe graph structures, the question is where the meaning of relationship are represented (in RDF they’re commonly thought of as the edge connecting the nodes). I prefer to think of the Topic Map graph as a bipartite graph (i.e., having two types of node), with the Associations being full-blown graph objects in their own right, with “edges” being just connectors between the two kinds of nodes, having no semantics of their own.

http://www.altheim.com/ceryle/misc/tomjerry.png

So we can represent things like “Tom is a cat” and a “Cat is a kind of Living Thing”. In this model you’ll note that two Topics are never connected directly to each other via an edge, they’re always connected via an Association. The Association carries the meaning (the “semantics”, if you want to sound high-fallutin’) of the relationship between the Topics, such as its Type (e.g., “kind of” is a superclass-subclass relation) or Scope (i.e., context in which the Association is valid). In the Topic Map model, Associations contain Members, and it’s the Members that actually contain references to the Topics. The Members can specify roles, e.g., in a “marriage” Association, there would be two Members, one with a role of “husband”, the other of “wife” (this is of course a traditional view of marriage, and perhaps needs some revision). The Scope in this case could be the time period the marriage endured (and for some marriages, it is certainly endurance).

In this view, the Topics and Associations of Topic Maps are akin to another bipartite graph, the Concepts and Relations of Conceptual Graphs [1] [2], though Topic Maps on their own contain none of the semantics necessary to implement CG. But just like RDF (in this sense), this doesn’t stop anyone from stating their own semantics. In my application, I’ve built up a fairly complex set of semantics, similar to an informal, simplified Cyc [3] [4] ontology (sorry, the “C” word crept in).

The mapping part is where one takes a Topic Map graph that has been populated with Topics and Associations, and begins “mapping” an external domain, such as the web. This is where they are of potential value for wiki. Think for a moment about a traditional, printed atlas. An individual page maps a real place onto a piece of paper, identifying cities, rivers, mountains,train tracks, etc. There are many possible views: geographical, political, climate, historic, etc. Topic Maps enable you to first create a knowledge organization system (a KOS, the latest buzzword) describing some domain or thing, then connect the created map to the thing. This works particularly well when the things being mapped are addressable, i.e., they have a URI, an address. But even for things that aren’t directly addressable, we can create a proxy Topic and then they refer to the proxy. There’s no reason why you couldn’t have a “folder number” or use the ISBN number in a Topic Map system. I wrote a number on every PDF printout when I organized my lit review in a Topic Map, and used that. In Topic Maps there is a way to keep track of the type of relationship between a Topic Map Topic and a thing that it is mapping, its Occurrence. A Topic can have zero or more Occurrences, and they can also be scoped. So, I admit it, I lied. There aren’t two fundamental things in Topic Maps, there are three: Topics, Associations, and Occurrences. Steve Pepper wrote this idea up as The TAO of Topic Maps. The Occurrence is the mapping part, though one might consider that the internal relationships are also a form of mapping. In practice, the boundaries between in-the-map and external-to-the-map are completely blurred, especially when one builds a Topic Map document out of other Topic Map documents.

All of this scoping can be used to filter or provide views of a particular knowledge landscape, such as the geographic or political view in a traditional map.

I’m going to quit for now, but that should hopefully give you a running start. And BTW, to answer Danny’s comment above, anyone who thinks XTM syntax is messy hasn’t looked at RDF. XTM is admittedly verbose, but it’s very clean. Nobody in their right mind would want to edit either by hand. XTM uses one namespace (apart from XLink, which is only used for xlink:href) and it’s very straightforward XML. The hard part is understanding the depth of the paradigm, which in my experience a lot of people still don’t get even after repeated exposure. I’m not sure I even completely understand after all this time. I still catch a “eureka!” moment now and then. I find the recursively associative structure very similar to how I think human thought and memory operate. --MurrayAltheim

A TopicMap distinguishes two types of “thing”: things internal to the map, and things external. Anything inside the map is called a topic, and almost everything is inside the map. Unlike in RDF, URIs are not topics, and are external to the map. They are identified with topics using subject indicators, and any topic can have as many or as few indicators as desired. This implicit identification of multiple URIs can only be achieved in RDF using statements, as is associating more than one URI with a resource.

Associations look like RDF statements, except (a) they are bidirectional, and (b) they are multi-partite, not tripartite. Every association has an association type, and every topic involved in an association has an association role.

  • Instead of saying <dog, is-a-kind-of, animal> and <animal, has-kind, dog>, one might say that dogs and animals are associated, that the association is of type “kind”, that the role of dog in this association is “instance”, and the role of animal is “general”.
  • Instead of saying <job offer, employer, my dad>, <job offer, employee, me>, <job offer, offer, ten bob>, <job offer, date, Tuesday>, one can say that my dad, me, ten bob, and Thursday are associated, that the association is of type “job offer”, and that the roles of those associated are employer, employee, offer and date, respectively.

Occurrences describe resources pertinent to a topic. In RDF, this would be achieved with a specific statement connecting the resource of the topic with the resource of the occurrence.


See also TopicMapsVsRDF.

CategorySemanticWeb? (Murray’s gonna kill me…)

Define external redirect: CategorySemanticWeb

EditNearLinks: CategoryWebTechnology

Languages:

The same page on other sites:
MeatBall:TopicMap