Working With MediaWiki
call to #set_internal is more compact than the one to #subobject, though that’s a relatively minor detail. But Semantic Internal Objects is notably superior to #subobject in at least one way: there are two additional parser functions that make use of SIO, #set_internal_recurring_event and #store_external_data. The former is covered in the next section, and the latter is defined in the External Data extension ( see here ). This functionality will all presumably be added for #subobject at some point, but that hasn’t happened yet.
Recurring events
There’s one case within Semantic MediaWiki where you can store values via a formula, instead of just manually entering them, and that’s for recurring events. A recurring event is any event that happens on a regular basis: a birthday, a weekly meeting, a once-a-month deadline, etc. The standard way to store a recurring event is to use the #set_recurring_event parser function. Let’s take an example: let’s say you plan to have a weekly sales meeting every Monday, for a year and a half. To complicate things, let’s also say that, for scheduling reasons, on two of those weeks the event should instead be held on Tuesday. On a page called “Weekly sales meeting”, you could accomplish that with the following call:
{{#set_recurring_event:property=Has date
|start=January 7, 2013
|end=June 9, 2014
|unit=week
|period=1
|include=March 19, 2013;March 26, 2013
|exclude=March 18, 2013;March 25, 2013
}}
This defines a weekly event, by setting a property called “Has date” to a large series of values. The parameter “property” takes in the name of a property, which has to be of type “Date”. The parameters “unit” and “period” together define the frequency of the event. “unit” can be any of the values ’year’, ’month’, ’week’ and ’day’, while “period” is an integer. If this were an event that happened every two weeks, the unit would be ’week’, and the period value would be 2.
The “include” and “exclude” parameters let you manually change the set of date values, if necessary.
What if this event happened on, say, the 3rd Wednesday of every month? For that, there’s an additional parameter, “week number”. If you have “
unit=month
”, and add “
week number=3
” to the call, then, if the start date falls on a Wednesday, every automatically-generated date will fall on the 3rd Wednesday of the month.
There are several limitations for #set_recurring_event; one is that it doesn’t allow for defining a duration of the event, so that you can, for instance, specify that your weekly meeting always runs one hour, between 12 and 1 PM. This is a weakness that will hopefully get addressed in upcoming versions.
Another limitation of #set_recurring_event is that, because of the syntax of #ask queries, there’s no easy way to display only certain instances of an event: you can run an #ask query to find all the events that have an instance next week, but you can’t display only those instances that are happening next week. In our example, suppose you want to display, on the wiki’s main page, a list of the next four weekly sales meetings. If this information were stored with #set_recurring_event, there would be no easy way to do that.
This problem has a solution: the #set_internal_recurring_event function, which is defined by the Semantic Internal Objects extension. It works like #set_recurring_event, but stores each event instance as its own internal object, which makes it easy to display only those dates you want to.
To do such a thing for our example, you would first need to create a property that would be used to point from each event instance to the page on which the recurring event was defined. You could call it “Is instance of” (a safe choice) — to do that, you would just need to create a property with that name, and make it of type “Page”.
You would then replace that #set_recurring_event call with this:
{{#set_internal_recurring_event:Is instance of
|property=Has date
|start=January 7, 2013
|end=June 9, 2014
|unit=week
|period=1
|include=March 19, 2013;March 26, 2013
|exclude=March 18, 2013;March 25, 2013
}}
The only difference in the syntax is that first, unnamed parameter, which holds a property pointing from each internal object to the page. Now, to display a list of the four next weekly sales meetings, you could have a query like the following:
{{#ask:[[Is instance of::Weekly sales meeting]]
[[Has
Weitere Kostenlose Bücher