hw>Mlink-rodrigue No edit summary |
No edit summary Tag: 2017 source edit |
||
| (2 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
<bookshelf src="Book:Getting started with Semantic MediaWiki" /> | {{Messagebox|<bookshelf src="Book:Getting started with Semantic MediaWiki" /> | ||
==Consistent naming of pages== | ==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.{{ | 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. | ||
{{Messagebox|boxtype=example|Note text=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 [[Manual:The concept of namespaces|namespace]] ''Customer''. | |||
[[Manual:The concept of namespaces]] | |||
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. | 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. | ||
| Line 20: | Line 22: | ||
Therefore, we capture the relationship to the page in the property name: ''Has location''. | Therefore, we capture the relationship to the page in the property name: ''Has location''. | ||
{{ | {{Messagebox|boxtype=note|Note text=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. | ||
Latest revision as of 15:40, 20 May 2022
{{Messagebox|
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.
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 namespace Customer. Manual:The concept of namespaces 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.
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".
