No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
==Consistent naming of pages== | ==Consistent naming of pages and properties== | ||
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.}} | {{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 | It makes sense to name the required pages consistently. In our example, we would create the pages | ||
For the properties, you have to consider that the property ''location'' could also be used outside the context of customer pages. There could be locations for partners or vendors, for example. | * <code>Template:Customer</code> to show the customer information, | ||
* <code>Form:Customer</code> to enter the values for the customer data, | |||
* <code>Category:Customer</code> to collect all pages that use the template "Customer". | |||
To maintain a catalog with all your customer information, you can | |||
* consider putting the pages in their own [[Manual:The concept of namespaces|namespace]] <code>Customer</code>'','' or | |||
* collect the pages as subpages of the page <code>Customer.</code> | |||
The choice where to maintain your customer pages depends on the setup of your wiki and how you organize content for your specific use-case. | |||
=== Organizing your properties === | |||
For the properties, you have to consider that the property ''location'' could also be used outside the context of customer pages. There could be locations for partners or vendors, for example. You need to decide if they are related or not. Based on your decision, you can collect the values for the customer locations in the following properties: | |||
* Property:Location (collects all location information in the wiki) | |||
* Poperty:Customer location (collects specifically the location information of customers) | |||
* Property:Customer/location (collects specifically the location of customers, but seen as one of multiple "grouped" properties for customers such as Customer/contact, etc...) | |||
==Classification of information== | ==Classification of information== | ||
| Line 14: | Line 31: | ||
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:<pre>Customer Technicon has location Regensburg. | 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:<pre>Customer Technicon has location Regensburg. | ||
(page) (property) (value)</pre> | (page) (property) (value)</pre> | ||
Therefore, we capture the relationship to the page in the property name: ''Has location''. | Therefore, we can 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 named "location" if its intended use is clear. | {{Messagebox|boxtype=note|Note text=It is not required to express this relationship function of properties (as predicates). The property can also simply be named "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.}}<br /><bs:drawio filename="Semantic MediaWiki/Nomenklatur-86700495" /><br /> | 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.}}<br /><bs:drawio filename="Semantic MediaWiki/Nomenklatur-86700495" /><br />{{Box Links-en|Topic1=[https://www.semantic-mediawiki.org/wiki/Help:Classification https://www.semantic-mediawiki.org/wiki/Help:Classification]}} | ||
{{Box Links-en|Topic1=[https://www.semantic-mediawiki.org/wiki/Help:Classification https://www.semantic-mediawiki.org/wiki/Help:Classification]}} | |||
[[de:Handbuch:Semantic_MediaWiki/Nomenklatur]] | [[de:Handbuch:Semantic_MediaWiki/Nomenklatur]] | ||
[[en:{{FULLPAGENAME}}]] | [[en:{{FULLPAGENAME}}]] | ||
Latest revision as of 10:44, 23 March 2026
Consistent naming of pages and properties
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:Customerto show the customer information,Form:Customerto enter the values for the customer data,Category:Customerto collect all pages that use the template "Customer".
To maintain a catalog with all your customer information, you can
- consider putting the pages in their own namespace
Customer, or - collect the pages as subpages of the page
Customer.
The choice where to maintain your customer pages depends on the setup of your wiki and how you organize content for your specific use-case.
Organizing your properties
For the properties, you have to consider that the property location could also be used outside the context of customer pages. There could be locations for partners or vendors, for example. You need to decide if they are related or not. Based on your decision, you can collect the values for the customer locations in the following properties:
- Property:Location (collects all location information in the wiki)
- Poperty:Customer location (collects specifically the location information of customers)
- Property:Customer/location (collects specifically the location of customers, but seen as one of multiple "grouped" properties for customers such as Customer/contact, etc...)
Classification of information
Categories
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
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 can 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 named "location" if its intended use is clear.
