A topic map is a set of topics and associations between them. This module implements topic maps as a data-driven generic graph structure of typed associations between topics embedded as markup in Drupal node data. (For example, "Homer is married to Marge" can be marked up as an association between Marge, the wife, and Homer, the husband, whose type is marriage.) The embedded markup, processed into the graph structure, drives navigational and analytical tools. Thus, topic maps may be seen as a generalized way of implementing indexes, glossaries, thesauri, taxonomies, ontologies, and other systems of creating, collecting, curating, and navigating topics and associations that are of interest to communities of users.
Application areas can be found where there is rich, highly granular content whose relationships cannot be adequately represented or navigated with fielded data or "tags": document dumps, large corpora, fan sites, political or economic blogs, litigation services, etc.
Novel features of this topic map implementation:
1. Wiki-like markup to create topic map associations embedded in content. Clicking on links created from this markup drives the creation of topic pages, indexes, and other representations.
2. The topic map markup can be validated against a schema, at administrator option, and errors thrown.
3. Plug-in architecture and API enable expanded functionality by topic subject matter. Plug-ins are Drupal modules, and can be created for:
a. Notations (URLs, case law citations, lat/lon, etc.)
b. Association types (association types, like class/instance, supertype/subtype, and so on)
c. Finding aids (against topic map associations)
d. Topic maps
e. Scope (for example, Time and place)
f. Affordances (value add to user interface elements)
4. Data-driven application architecture.
And novel for topic mappers:
5. LAMP stack implementation.
6. Content management, moderation, and social networking features -- all for free.
System requirements: The module is written for D7, and there are no plans to backport to D6. Contributed module requirements: jquery_plugin. The module also supports advanced help. Contributed topic map modules may have additional requirements.
I'm using the module with success to create topic maps today. However, development was begun under D6, and then continued under D7. So I'm sure the module doesn't fully partake of the D7 nature, so now I want to refactor it! In particular, the only field that really matters is the body, which is very D6 -- but also very much a content creators attitude, which is where the use cases come from.
There's also a pitfall in the installation process: The topicmap module must be installed, then a topicmap Text Format installed and/or checked, and only then can the topicmap_data module installed, which then installs everything needed to create topic maps. This isn't a typical installation pattern, but I think it's necessary; since the modules are data driven, the Text Formats must be correct, otherwise the modules installed by topicmap_data will fail.
Finally, if you need a topic map with millions of topics, this is not (right now) the application for you, at least on a single site. If you want a topic map of the human genome, look elsewhere! The fundamental use case is markup as an editorial value add created by humans, which is appropriate for the CMS world. (Since the module is RESTful, it might be possible to distribute across a cluster; it would also be possible to contribute a module that uses NoSQL storage).
If advanced advanced help is installed, the README includes a tutorial. Otherwise, visit the demo site. Finally, each plugin, when installed, also installs documentation and an example, as Drupal nodes. In brief:
Content creators using the topic map module enter associations between topics in post data with a simple, wiki-like [[ ... ]] syntax. Like a wiki, this topic map application is data-driven, but this topic map syntax is richer, and its functionality is far greater. Here is a topic map association as entered:
[[test:marriage:The Simpsons[husband:Homer] is [wife:Marge]]'s better half.
(The association displays as: Homer is Marge's better half). Test is the name of the topic map that contains the association. Marriage is the association type. A marriage has two roles: husband, and wife. In this association, whose name is The Simpsons, the husband role is played by Homer, and the wife role is played by Marge. Because this implementation is data-driven, a page for each of these topics can be created automatically (at administrator's option), and all occurrences of the topic Homer, for example, will be collocated on Homer's page, with links out to the pages where Homer is a subject of conversation in the community. An dynamic index is created for each page, which enables navigation to and from topics on the page, and elsewhere. In addition, a dynamic master site index is created for each topic.
The topic map community, for many years of patient work.
Under correction, there are not many similar projects. simplewiki has the philosophy of using markup to drive the creation of pages, but lacks the topic map module's data structure and modular architecture, as well as the other features listed above. Token modules perform string substitution, but have no notion of a set of tokens conceived of as property/pairs. RDF, at least in the implementations I have seen, is granular to the node level; contributed modules shipping with the distribution can represent topic map associations as RDF. (Although my skills in RDF are not what they could be, the tools are there!)
Call for developers
The topicmap module has a plug-in architecture that enables developer-created association types to be processed, validated, reported on, navigated, and, depending on the implementation, reasoned about. For example, association type plug-ins for super- and subtypes, classes and instances, among others, are included with this distribution:
[[test:is_a[i:Homer] is a [c:man]]. A [[test:su[sub:man] is a kind of [sup:human]].
(The association displays as: Homer is a man. A man is a kind of human.) Just as Homer is a topic, has his own page, is collocated, etc., so too is_a (class/instance), c (class), i (instance), and so forth, are topics, have their own pages, are collocated, etc. In addition, type plug-ins allow associations to be validated; for example, instances of the is_a association type must have a single c (class) role player, but may have more than one i (instance) role player, maintaining the integrity of the class hierarchy. Implementors may also generate reports for types (for example, tree-like representations of the su (supertype) forest).
Besides type plug-ins, the topicmap module also has data plugins, so that role players in a particular notation may be formatted. For example:
[[test:is_a[i:123 Any Street, Yourtown, MD=mapping] is your [c:objective]].
(The association displays as: 123 Any Street, Yourtown, MD is your objective). The mapping plug-in included in this distribution geocodes the address, and then uses the geocode as input to an online mapping service to display a map to the address in a floating box on the page next to the address.
Finally, the topic map module includes an implicit business model. Because the topic map addresses to the subject, not the resource, advertising (for example) can be targeted with micrometer-like precision. This distribution demonstrates the ability to advertise based on pinpoint links to interface elements driven by the citation of a particular legal case. [NOTE: This is dependent on the ad module being upgraded to D7.]
NOTE The application also includes a drag and drop interface to create topics associated with content, without embedded markup. One of the first refactoring tasks is to move that functionality to a contributed module, as an affordance, so developers can swap in their own editors.