I'm looking back at this thread now, because I want recurring events to be handled by SMW in one way or another.

John: I didn't really understand your issue; what's an example of something that the #ask calendar format can't do?

CNIT: that would work, although I hope there's a way to do it that doesn't involve creating a new database table; which would be a fairly big step.

My current thinking is that the way to go is to declare a set of new special properties for recurring events, and that they should be declared directly within SMW.

-Yaron


On Wed, Mar 25, 2009 at 5:06 AM, CNIT <cnit@uniyar.ac.ru> wrote:
John McClure :
> *
> *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-----
> **
>
Every re-occurrence of dates can be simply explained by Ordinal date:
1..365 for non-leap year, 1..366 for leap year.
There are simple formulas for that, freely available.
The same Ordinal date can be calculated for months (1..31/30/29/28) and
weeks(1..7), if someone wants to.

If you introduce an additional SQL table, these values can be calculated
and stored for each [[Type::Date]]
when the property value is stored by SMW.
`ordinal_leap`
`ordinal_nonleap`
`ordinal_month`
`ordinal_week`

Then you can simply select an interval of ordinal dates (let's say
between 100th and 130th day of the year) and it
will return SMW's internal numerical date values that occured during
these days.

Just one extra table and no additional properties. I believe that Date
is a just Date and it's re-occurence
can be stored as a part of it, just in another table. "Incomplete"
re-occurent dates just have their Ordinal
dates without internal numerical value (since year 0).

Then, special kind of #ask can be created to select date properties for
re-occurring dates.
I was thinking of such extension, but currently no time to implement.
Also, I am not sure my
coding skills are up to MW/SMW standards. Maybe I'll try in the future.
Dmitriy

------------------------------------------------------------------------------
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