Initially a Topincs store is empty. We first 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 Graphs 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 to the lower left. By moving your mouse pointer over this 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 is hidden in the layout modes fpr handheld devices – small and tiny. There you cannot perform any admin functions.

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 link to specialized index pages for 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 context menu for viewing, editing, or deleting the relevant topics. 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. These correspond to input fields in the form. 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 attribute constraints help you bring more life into your form and into your schema. An attribute belongs to one topic only, has a type, a value and a datatype. Names are simplified versions of attributes, 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 attributes is distributed over several topics of these types:

• The attribute type holds the name, e.g. Date of birth or Age and the datatype.
• 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 attribute constraints for one attribute type tying them to topic types. They also hold a minimum and maximum cardinality to control how many attributes 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. 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 attribute 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. Creating an association type is more difficult, but you will quickly get the hang of it.

To easily integrate files into your 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 constraint helps us to restrict which files types, e.g. only PDFs. In addition you can specify that images are downscaled before uploading.

When a filing constraint is present at a topic type, the form for a new instance requires file to upload. It will be stored in Topincs 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. File extension and media type are optional.

Images and videos are supported in Topincs. They are embedded in factsheet and form. 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.

We declare a topic type abstract by using the corresponding checkbox in the form. Abstract topic types cannot be instantiated. As usual its constraints will be inherited to all sub types. Topic role constraints can use abstract topic types for simple extensibility.