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.
Hint: Notice the difference in writing: Topic Maps is used to refer to the technology. There is only one. A topic map denotes a collection of topics and statements adhering to the above technology. There is many.
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 https://www.topincs.com/santaclaus/ // System id of a topic 342 // Subject identifier of topic 342 https://www.topincs.com/santaclaus/342
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.
Maria, a child of age 8, makes regular wishes to Santa Claus. She lives in Switzerland, in an town called Russin. This year she wished for a new ball. In these sentences a number of subjects occur: Maria, Santa Claus, Switzerland, Russin, the age of 8, Maria's wish in 2021, the year 2021. In our system only four are represented as a topic, namely it is Switzerland, Maria's wish in 2021, the year 2021, and ball, not the particular ball Maria gets, but ball as a gift option. The rest of the information is present in our system, but not as topics.
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.
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.
Hint: Sometimes it can be hard to find the right name for a topic type. Your users might not have a way of referring to that. Make one up: simple is better!
Above we identified these four topics in our domain: Switzerland, Ball, the year 2021 and Mary's wish 2021. We can now determine their topic type. This is completely up to us, but we should keep in mind that these terms will be visible to some or even all users. So, if we want to make it easy for them, we should use names they use and understand. For Switzerland we choose the topic type Country, This is pretty straight forward. Other instances of this topic type are France and Poland. 2021 is a Year. For Ball we choose Gift and for our last topic Mary's wish 2021, the topic type is Wish.
Hint: Many languages can make non-noun words into a noun. Then they can become a subject in a sentence and be associated with properties through adjectives.
This last choice illustrates something very important. Every concept can become a topic type, if it fits your needs. This is not limited to nouns or the Aristotelean essential. 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.
Let us look at our topic type wish. A child can pick exactly one option (no more no less) from the gift options this year. So the wish needs to play the role in the association exactly once, while gift options can be used any number of times. This is the typical information a Topic Maps schema is made of. Furthermore a wish should have the age of the child, so it needs exactly one occurrence of occurrence type Age of datatype positiveInteger. We need an address in textual form and in which country the address is in.
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 an 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.
Hint: Above documents are very technical. We suggest you use them later to deepen your understanding.
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.
This page cannot be displayed in your browser. Use Firefox, Opera, Safari, or Chrome instead.