Naming conventions

Consistent naming of pages

Before you create a semantic template, you first need to define which data to collect. Usually the data can be seen as a data set.

Example: We want to collect customer data. All customers get their own wiki page. On each page we enter information about the company location, the primary contact person and the date of first contact with the company.

It makes sense to name the required pages consistently. In our example, we would create the pages Template:Customer data, Form:Customer data and Category:Customer data. You can even consider putting the pages in their own namespace Namensraum Customer.

For the properties, you have to consdier that the property location could also be used outside the context of customer pages. There could be locations for partners or vendors, for example. Each context could get their own property (e.g. Customer location) or share the same property location and then use a different category (Customer data, Partner data, ...) on the wiki pages to distinguish them.

Classification of information

Categories

Generell unterscheiden wir bei der Klassifizierung von Seiten zwischen Kategorien und Attributen. Mit Kategorien wird die Seite an sich beschrieben. Am Beispiel Kunden kategorisieren wir jede Kundenseite mit dem Schlagwort Kundendaten. Die Kategorie sammelt also alle Seiten, auf der sich Kundendaten befinden.

When classifying pages, we generally differentiate between categories and properties. The page itself is described with categories. Using the example of customers, we categorize each customer page with the keyword Customer data. The category therefore collects all pages on which customer data is located.

Properties

In den Kundendaten werden nun bestimmte Eigenschaften gesammelt, die jeden Kunden genauer beschreiben. Hierzu werden Attribute erstellt. Im Normalfall stehen diese Attribute in einer direkten Beziehung zur Seite selbst. Daher kann es hilfreich sein, die semantische Beziehung über das Attribut auszudrücken:

Certain properties that describe each customer more precisely are now collected as customer data. Normally, these properties are directly related to the page itself. It can therefore be helpful to express the semantic relationship directly in the property:

Customer Technicon has location Regensburg.
         (page)   (property)    (value)

Therefore, we capture the relationship to the page in the property name: Has location.

Note: It is not required to express this relationship function of properties (as predicates). The property can also simply be names "location" if its intended use is clear.

There is, however a difference between "Has location" and "Is location of". For example, the customer Technicon has the location Regensburg. The city of Regensburg, on the other hand, is the location of the customer Technicon.

[Edit]

Subpages

We can also work with a subpage system and work with properties like Property:Customer/Has_location, Property:Customer/ Has_First_contact, and so on. If the property "Location" is also to be used elsewhere, it is advisable to define Property: Has_location instead of Property:Customer/Has_location.

When properties can be clearly assigned to a use case or have several use cases, it makes sense to name them accordingly. For example, Property:Customer/Contract_number can be a sequential, whole number, but Property:Partner/Contract_number can contain entries such as "1.1.5" or "4.3.7".

Related info

• https://www.semantic-mediawiki.org/wiki/Help:Classification