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.
Hint: Topincs never opens a new browser window or tab. You know best when you want to do that!
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
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.
Hint: Generally you should follow your train of thoughts when modeling. Linearity plays a minor role. Any error can be quickly corrected.
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.
For the Santa Claus system our main topic types are year, gift, country, and wish. They all need a name and any wish will have several occurrences. We will model the topic type wish last to make the demonstration clearer. We will start with Country and Gift in the video below.
Check it out
Hint: Cardinalities are not required, but it is recommended to provide them anyway. Use an asterisk (*) for maximum cardinality to allow an unlimited number of statements.
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.
Hint: Learn in depth how to to handle date and time information in Topincs.
The schematic information on occurrences is distributed over several topics of these types:
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.
Hint: It often makes sense to use topic types as role types! You can quickly make a topic type a role type on the page of the topic type.
Hint: You can reuse role types in different association types!
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.
Any wish instance will need to have exactly one association with instances of all the other topic types, so three associations all together. The next video will demonstrate how to model two associations types. From the perspective of the wish, all associations are mandatory, meaning minimum and maximum cardinality is 1. From the perspective of gift and country, they may or not be associated with a wish. They are independent that is why we could already create them. They also may be associated with any number of wishes. In this case maximum cardinality is set to the asterisk (*). By default Topincs creates an association type optional and unlimited in both directions. You need to adjust these defaults so that your requirements are met.
Check it out
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.
The children making a wish should be able to upload a foto, if they want to. So we create a topic type photo, make it a subtype of Topincs file, and create a filing constraint. By default Topincs opens a sub form (in case other information is necessary for the file). Not in our case, so we use simple file selection, which skips the sub form and goes right to the file selection dialog.
Check it out
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.
This page cannot be displayed in your browser. Use Firefox, Opera, Safari, or Chrome instead.
Before we continue …