Well, I don't know if I agree that handling repeating events is "sorely"
needed, but it would certainly be nice to have. And your idea of
pre-calculating the dates is quite a good one - it would be better for
performance, it wouldn't require defining any new special properties (or,
worse, a new type), and it would mean that the date information would be
immediately visible across all formats. The only downside I can think of is
that the repeated-event information couldn't be exported via the iCalendar
format, which has its own notation for repeated events - but I think that's
an extremely minor issue at the moment.
So, how about a parser function called something like #set_repeated_event or
#set_recurring_event, with a call that might look like:
{{#set_repeated_event:property=Has date|start=January 4, 2010|end=June 7,
2010|unit=week|period=1|include=March 16, 2010;March 23, 2010|exclude=March
15, 2010;March 22, 2010}}
This would set the property "Has date" for a weekly frequency (every Monday)
from January 4 to June 7, with two of the dates replaced by the following
Tuesday.
This could be a really great solution, and it seems like it would be rather
easy to implement. Any thoughts?
-Yaron
On Fri, Apr 3, 2009 at 6:29 PM, John McClure <jmccl...@hypergrove.com>wrote:
> *1. My initial question -- I was asking for some realistic use cases,
> particularly having **'thousands' (or even hundreds) of repetitions.*
> **
> *2. The Book Use Case -- (ok, there's 3*20 = 60 meetings) -- why not
> pre-calculate the specific event dates using a template and or parser
> function, rather than re-calculating them each and every time the
> [[category:Event]] article is read by the {{#ask:}} extension? It's far,
> far better performance for the system, and it's as hidden from view as any
> other template-formulated property. *
> **
> *3. Multiple attribute instances - whew, I'm relieved to hear that!*
> **
> *4. Date arithmetic -- no I am instead talking about integrating function
> calls (like date arithmetic) directly into the {{#ask:}} format so that the
> result is displayed in a table column, for instance.*
> **
> *Thinking back, the reason I commented originally was that I believe a
> <calendar> widget is a more robust solution than {{#ask:}}. At the same
> time, I couldn't be in more agreement that a calendaring facility for
> repeating events is sorely needed. It's best though to remain as mindful as
> we can of the costs and consequences of any approach.*
> **
> *- **John*
>
> -----Original Message-----
> *From:* Yaron Koren [mailto:yaro...@gmail.com]
> *Sent:* Friday, April 03, 2009 9:54 AM
> *To:* John McClure
> *Cc:* semediawiki-devel@lists.sourceforge.net
> *Subject:* Re: [SMW-devel] Recurring Events Calendar Format
>
> I don't quite understand your initial question: a repeated event can have
> thousands of repetitions, so it wouldn't be practical to specify them all
> manually; meanwhile, #ask is just how data is retrieved within SMW.
>
> You do point out one weakness in the scheme I'm proposing, although I don't
> think it's a major one: that it doesn't let you have more than one data
> property on the page that's the recurring event. To show why I don't think
> it's a big deal, let me illustrate with your example: for a book, all the
> dates you listed are most likely single events. But let's say one of them is
> repeated, like there's a daily editing meeting for several months. In that
> case, you can create a page called "[Book name] editing meeting", and have
> all the necessary repeating-event properties on that page, instead of on the
> book's own page. Which I think is natural anyway: if any sort of event
> happens on a regular basis, it's probably important enough to have its own
> page.
>
> To your other question - I don't know about all the formats, but I think
> most handle multiple values per property. Semantic Google Maps does, and I
> think the 'calendar' format does as well - if it doesn't, it should.
>
> Date arithmetic can, and I think should, be done by parser functions
> outside of SMW - I don't know of any extensions that do it at the moment,
> but it would definitely be a good idea for an extension.
>
> -Yaron
>
>
> 2009/4/3 John McClure <jmccl...@hypergrove.com>
>
>> Hi Yaron,
>> It's not so much what sf/smw can or can't do -- it's about
>> whether {{#ask:}} is the right approach for repeating event. #ask is
>> presently used to query articles having *any* date-property. So what
>> benefit actually is there to having repeatable events handled by #ask? I can
>> think of just ONE BENEFIT: a user does not need to specify multiple
>> date-properties for an article. Maybe there are others?
>>
>> Here's the bigger problem though. Lets say we have an article about a
>> book. The article contains many, many dates -- dates for composition,
>> editing, proofing, publishing, shipping, distribution, etc. If
>> repeat-properties are present for the article, which action is being
>> "repeated"? Or maybe is the book itself somehow being "repeated"?
>>
>> So my concern is that -- yes while technically possible -- hardcoding
>> repeat-event properties for an article kinda leads to many questions about
>> the data model you're assuming/looking for.
>>
>> I'm curious, does #ask today handle multiple instances of a named property
>> for an article, or does it just look for a single instance? Does the
>> calendar format accurately show those multiple values?
>>
>> Hmm, if you'd like to bring #ask to a 'new level' that involves dates,
>> might I suggest that a useful generic function would be to perform date
>> arithmetic, eg difference(dated-property-1, dated-property-2,
>> units-selection), and output the result. Or something like that. I'm not
>> thoroughly knowldegeable about #ask, so maybe that's already there. Another
>> example that ties right into the calendar option would be
>> duration(dated-property-1, dated-property-2), which would bracket the two
>> dates in an interesting way. Maybe that's there with the timeline option --
>> I havent studied it all enough yet.
>>
>> Thanks
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Semediawiki-devel mailing list
>> Semediawiki-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
>>
>>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Semediawiki-devel mailing list
> Semediawiki-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
>
>
------------------------------------------------------------------------------
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
