Whenever a user completes a form in Topincs, he makes statements about a topic. Some of the statements belong to one topic only, and some connect two topics. In the technology that Topincs is based on, Topic Maps, the latter are called associations and are composed of roles. The prior are called names and occurrences. Don't let yourself be confused by those terms. Think of names and occurrences as properties. A name is just a special kind of property: one that is used by humans to refer to the topic during information exchange by natural language.

When you put a collection of topics and statements together, you have a topic map. Every Topincs online database, short store, is a topic map and assigns every topic automatically the next available positive integer, its system id. When you access the URL composed of store url and system id in the web browser, you will see the factsheet of this topic. Every association is rendered as a hyperlink to the fact sheet of the connected topic, the counter player.

Store URL, system id and subject identifier

A topic is a digital representation of a subject, which can be anything that can be talked about. It does not matter whether it exists in the real world, in the digital world, or is a product of imagination. To make the distinction between topic and subject clearer: when a topic is deleted, it disappears from the store, yet its subject remains untouched. A subject may be destroyed by an explosion, which has no effect on the topic, it still exists.

Instance information

Which subjects of your universe of discourse, your domain, will become topics is a design choice. There is no rule of thumb. The advantage of a topic is that you can make any number of statements about its subject. Names, occurrences, and associations are dead ends in this aspect. Therefore they introduce less complexity in the system. When there is a small chance that you might want to say more about a subject at a later stage, rather treat it as a topic from the beginning. Later remodeling is tied to the risk that you have to take the system partially or completely offline.

A name in Topic Maps is a simple string value. It belongs to exactly one topic. An occurrence is similar to a name: it is also a string value, but has a datatype in addition. This way we can easily transform the value and perform computations with numbers, dates, times, and durations. There is no limit on how many names and occurrences a topic can have. It is not difficult to decide whether to use name or occurrence. People use names to refer to subjects in communication, thus they are usually short and easy to remember.

An association is a connection between two topics A and B. Topic A plays a role and topic B plays a different role. A topic can be a player in any number of roles. Thus, the number of associations for a topic has also no limit.

Now there is a couple of ingredients still missing to make this approach really powerful. The most important one is typing. Everything we have discussed so far has a type. Every topic has a type, a topic type, every name has a type, a name type, and so on. Since there is only a single thing that can be referred to in Topic Maps, types are also just topics. When speaking of a topic in relationship to its topic type, we use the term instance.

This last choice illustrates something very important. Every concept can become a topic type, if it fits your needs. Consider this statement: Mary wants a new ball this year. The information about the wish is in the verb, yet we construct a topic type from it. We could have modeled it as an association type as well. But that would limit what else we can say about the wish. Has it been fulfilled? When was it stated? All this becomes trivial when we model it as a topic type.

In order to specify how an instance of a certain topic type should or may look like, we use constraints. They also help us to specify which role types are used with an association type and instances of which topic types can play the roles. And how many times. All the topic types combined with the constraints form the schema. The complexity of a system increases with the number of topic types and constraints. Topincs uses the schema to power the base components and the API for data manipulation and aggregation.

A topic type can be a sub type of another topic type. This way it inherits all constraints and you do not have to duplicate them. There is no limit on depth. Sub types can have sub types, and so on. Also multiple super types are supported.

Another ingredient that makes Topic Maps powerful and unique is scope. This can be explained best with names, but applies to occurrences and associations as well. Every language has its own name for the country Switzerland. So we attach multiple names to the topic and additionally specify in which scope the name is valid. So the name Switzerland will be scoped with English and Schweiz with German. Topincs uses scope for selecting the right name for a topic depending on the Accept-Language HTTP header, given that a store supports more than one language.

Scope is equally important when we specify names for association types when modeling the schema. Given the association type Fatherhood between two people. From the perspective of the person playing the father role, this association would be phrased: Carl is the father of Maria. From the perspective of the child, the same association is worded: Maria is the child of Carl. In Topic Maps we can take care of this easily. We create two names for the association type and scope them accordingly by language and by role type. Such names are called perspective names in Topincs.

Every topic may hold any number of subject identifiers. Every subject identifier is a URL, ideally resolvable. These come in handy when integrating information from other sources. When the subject is digital in nature, its URL can be attached as a subject locator to the topic representing it in the store. It still might identify a different subject, so it is important to keep that distinction in mind.

The idea of Topic Maps has been around since the early nineties and has matured into two ISO standards, the Topic Maps Data Model and the Topic Maps Constraint Language. These two standards are the theoretical foundation on which Topincs is built. Together with the traditional corner stones of the World Wide Web HTTP, URL and HTML.

This introduction to this technology focuses on the aspects that are essential for Topincs. There is other concepts in Topic Maps, like variants and reification which are left out here, since they are not supported in Topincs.