Initially a Topincs store is empty. We need to model one or more topic types in order to see something in the index. 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 central to modeling your Topincs store. The schema sub menu has links to five sections: Types, Constraints, Programming, User interface and Miscellaneous. All schematic elements that define the online database and its behavior are listed and can be created in these schematic indices.
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.
By default the admin mode status message is hidden in the layout modes
tiny. In this case you cannot access any admin functionality through the admin menu. The keystroke
Alt-Shift-A displays the admin menu status message. Generally it is advised to use a big screen for development.
Modeling 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 additional statement types. There is no need to create them before hand, you can create all necessary topics along the way by entering sub forms.
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.
Topincs processes constraints in order to generate a form for instances of a topic type. The Topic Maps Constraints Language defines a set of constraint types and their meaning.
Instances of the topic type may or must have an occurrence of a certain type, e.g. a person has a date of birth.
Instances of the topic type may or must have a name of a certain type, e.g. a person has a first name.
Instances of the topic type may or must play a role of a certain type in associations of a certain type, e.g. a person may be an author in an authorship relation.
Declares 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 statement types can form hierarchies, but the behavior of Topincs is unknown for such cases.
In order for everything to work out, we need constraints for statement types as well.
Hint: Learn in depth how to to handle date and time information in Topincs.
Specifies the datatype of an occurrence type. Special value viewers and editors exist in Topincs for the standard datatypes
One or more such constraints specifies the form of an association, e.g. you need two role constraints to model the authorship relationship. The minimum and maximum cardinality of a role constraint is almost always one. In a symmetric relationship you will need one constraint for one role type with minimum and maximum cardinality of two.
Specifies which topic types can be scoping topics for statements of a certain type.
Hint: Most likely you will hardly ever need role combination constraints.
Specifies which topic types go together in an association type, e.g. books contain chapters and chapters contain sections.
There are several custom constraint types to achieve certain tasks which are not covered by the TMCL standard.
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.
A value space constraint can be used to restrict the value space of an occurrence type. The supported data types will appear formatted in the select box.
A list type constraint can be used in conjunction with the custom datatype topic-reference-list to create a list of topics of a certain type in an occurrence.
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. In order to get an association type working, you need to do the following:
This page cannot be displayed in your browser. Use Firefox, Opera, Safari, or Chrome instead.