I am now creating a calendaring mechanism for my wiki that is based on Kenyu's extension but which uses SFs to solicit parameters and content for a <calendar/> element. My [[form:Calendar]] writes the information to SMW properties of the [[calendar:page]]. This page, normally transcluded by another page, contains <includeonly><calendar/></includeonly>. The tag hook extracts the page's properties to build the calendar html. Shared & unshared calendars are distinguished: unshared calendars are <calendar> elements located on non-calendar namespace pages. Non-shared calendars' data is found within the attributes and content of the <calendar> element, meaning the tag hook operates in either mode -- upon data located in smw properties, and upon data located in the element itself.
 
My design permits naming [[event:page]] pages to be included in a calendar. The event pages have their own smw properties, such as those indicated below. Additionally, events can be specified for a calendar either in the content of a <calendar> element or in smw attributes of the [[calendar:page]]. A recurring event may only be specified in the context of an [[event:page]], not in the [[calendar:page]], in large part so that the [[event:page]] can have smw properties for non-recurring events developed from 'exploding' (i.e., resolving) recurring event specifications.
 
So my point is? The data for events to be displayed on a calendar can be located in a variety of places -- on an [[event:page]] included in a calendar, on the calendar's own page, and in a calendar element. Meaning there are at least two different smw property models needed, and these should be correlated with the attributes & content of a <calendar> element. Crucially, recurring events' smw properties should correlate as well with iCalendar's data model. 
 
OK, but what about {{#ask: |format=calendar}}? I concluded that the widget is a good choice for pure smw data-configs, but a bit inadequate for the shared/hybrid-calendaring tasks I have in mind. The #ask design does NOT contemplate a calendar page/resource, so no way to associate persistent properties with a calendar, meaning a different mechanism -- the predicates on the #ask command -- is necessary to identify which events are to be included on the formatted calendar.
 
Bottom-line is this. The #ask command is used to place wiki pages *which have a date property* as links in a calendar or on a timeline -- while immensely useful, it is not a general calendaring solution now, and arguably not ever.  An #ask command that incorporates processing of properties relating to "recurring events" seems a major contortion of its core mission; it suggests poor performance in the end to resolve recurring event data into non-recurring events; and distracts from more targeted and comprehensive solutions for calendaring.
 
Thanks, and comments appreciated!
John
-----Original Message-----
From: Yaron Koren [mailto:yaron57@gmail.com]
Sent: Monday, March 23, 2009 11:53 AM
To: David Raison
Cc: semediawiki-devel@lists.sourceforge.net
Subject: Re: [SMW-devel] Recurring Events Calendar Format

It would be great if calendars could support recurring events. I think technically, it could be pretty easy to implement: you could probably do it with four or five new special properties: "Has period unit", "Has period number", "Has first occurrence" and "Has last occurrence", and possibly "Has exception date", to handle dates on which the event doesn't happen but should, or the other way around.

The first two properties would handle the frequency, so a weekly event would have values "[[Has period unit::week]]" and "[[Has period number::1]]".

The big issue is whether such properties should be defined by the 'Calendar' format in Semantic Result Formats, or whether they should be defined by Semantic MediaWiki itself, and thus supported by all of SMW's date-handling tools.

(After that, the big issue is who will implement this feature. :) I probably could, if I have time for it.)

-Yaron

On Mon, Mar 23, 2009 at 3:11 PM, David Raison <david@hackerspace.lu> wrote:
Hi folks,

I've been reading your thread on "AnyDateTime" and stumbled upon this
quote from Markus:

For most purposes, we would like
to implement an idea of a totally ordered, "physical" time, i.e. every two
input times should be comparable and correspond to real time points of the
world. This excludes inputs like "May 1" which would describe an infinite
number of recurring intervals that we are not prepared to handle.

I was actually reading through the list because I'm quite interested in
a result format that could present recurring events on a weekly or
monthly basis.

When you say, you're not prepared to handle that, what are the issues
involved? Are there no efforts being put into a recurring events feature?
 I don't know whether I can find the time to work on it, but if you
could give me a few hints as to the problems, I might give it a try.

The background is that we're currently using semediawiki to handle our
events calendar (https://www.hackerspace.lu/wiki/Calendar and
https://www.hackerspace.lu/wiki/Main_Page)
Trouble is with recurring (weekly or monthly) classes or workshops. It'd
be very convenient to have such a feature.

Thanks,
David

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel