Initially a Topincs store is empty. We need to model one or more topic types in order to see something in the index and start recording information. Nothing in this chapter requires any coding skills, but it lays the foundation for your system by specifying the schema with forms. All you need is a good understanding of Topic Maps and the generic work flows in Topincs. But before we continue, a short introduction to how an administrator works in Topincs.

For modeling you need to sign in as an administrator. After this you will notice the admin mode status message to the lower left. By moving your mouse pointer over this message the admin menu becomes visible. It is the starting point of any development activity in your Topincs store. If you are not able to find it, make sure your screen and the browser window are wide enough. By default the admin mode status message is hidden in the layout modes small and tiny which are primarily for handheld devices. In this case you cannot access any admin functionality through the admin menu.

The first two entries Topic types and Services are used most frequently. They link to the index pages of these two central schematic topic types. The next entries in the admin menu link to specialized index pages giving access to all schematic topics that define the online database. Since it is all connected there is multiple ways to find anything. In various sub menus there is plenty to explore. In Documentation you find links to this manual and to the reference, the primary sources of information about Topincs.

You also notice a switch to turn on admin mode. In admin mode all schematic page elements are highlighted and react to right-click with the modeling context menu for viewing, editing, or deleting the topics involved in the definition and behavior of that element. The keystroke Alt-Shift-A toggles the admin mode as well.

Defining a topic type requires you to name it and create one or more constraints which roughly correspond to input fields in the form for editing instances of that type. When modeling a topic type you will need to create new statement types. There is no need to create them before hand, you can create all necessary topics along the way by entering sub forms.

Topic occurrence constraints help you bring more life into your form and into your schema. An occurrence belongs to one topic only, has a type, a value and a datatype. Think of it as a property. We call them occurrences to stay in line with the standard documents. Names are simplified versions of occurrences, they do not have a datatype, that is why we do not treat them separately. We have already seen in the video above how they are modeled.

The schematic information on occurrences is distributed over several topics of these types:

• The occurrence type holds mainly the name, e.g. Date of birth or Age.
• The occurrence datatype constraint determines which datatype occurrences of that type have. If not given it defaults to string. Special value viewers and editors exist in Topincs for the standard datatypes date, time, dateTime, duration, boolean, anyURI, integer, positiveInteger, nonPositiveInteger, negativeInteger, nonNegativeInteger, and decimal.
• There can be any number of topic occurrence constraints for one occurrence type tying them to topic types. They also hold a minimum and maximum cardinality to control how many occurrences a topic must (minimum) or may (maximum) have.

By using a regular expression you can easily make sure that strings follow a certain form, e.g. hold an email address or a zip code. Since this approach is limited to one form field, there is a more sophisticated methods to ensure user input adheres to rules. There is complete section on form validation, explaining how to use tiny JavaScript code fragments to validate input, even across several fields.

A value space constraint can be used to restrict the value space of an occurrence type. The supported datatypes will appear formatted in the select box.

An association is like a hyperlink between two topics. But it has a type and is named differently depending on the perspective. To create an association type is more difficult than name or occurrence types, but you will quickly get the hang of it.

Topincs defines its own extension to achieve certain tasks which are not covered by the Topic Maps standard. To easily integrate files into you model, you need to define a file topic type. This is just an ordinary topic type which subtypes the predefined topic type Topincs file. The filing contraint helps us to specify more restrictions on what kind of files or even if the browser should downscale images them before uploading.

When a filing constraint is present at a topic type, the form editing an instance of that type will require to upload a file to the server where it will be stored and published at an URL. This URL will be the subject locator of the instance edited. It is required to make this topic type a subtype of Topincs file. The file upload field only appears when creating new instances since the connection between the topic and the file cannot be changed. A different file is a different topic. If you should upload the same file twice you will notice that Topincs recognizes the file and avoids to create a new topic but rather attaches all additional statements made to the existing topic which already represents this file.

The filing constraint takes any number of file extensions and media types. The file extensions will be used client side to restrict the files that can be selected in the file selection dialog, if the web browser supports this. The media types will be used server-side to deny the storage of files that do not match the media type. This only happens after the server has received the complete file. File extension and media type are optional for a filing constraint.

Images and videos are directly supported in Topincs. The factsheet and the form display them inpage. This manual uses both types. The video above is a Topincs file. In this manual all paragraphs, images, videos, headlines, code examples, etc. are in fact topics.

By creating an abstract constraint, we declare a topic type abstract. Its constraints will be inherited to all sub types. Topic role constraints can point its topic type to an abstract topic type which allows easy extensibility at later stages. Abstract topic types cannot be instantiated. Theoretically a topic type can have more than one super type and even statement types can form hierarchies, but the behavior of Topincs is unknown for such cases.