Calendaring and K2

[Clay Fenlason]

Has there been any thinking about event data for K2? I was running
through the list of things that still need doing, I know CalDAV is on
the list, and I know Georgia Tech has an interest in seeing that
accomplished, but I have more questions than answers and so wanted to
raise the topic to see what's currently imagined by Cambridge, if
anything.

My naive architectural guess would be that event data would not be
represented in JCR, but that we should instead assume an independent
event store/calendaring server, though for the purpose of a Sakai
release/demo we'd probably bundle this into a single distribution
(e.g. Bedework, assuming issues like memory footprint, etc. are
tolerable). But then that leaves the problem of how to relate this
event data to content objects (e.g. when the assignment is due, who's
coming to office hours on Thursday). My vague impression is that this
is what ICOM should be helpful for, though we'd need to do a lot of
our own legwork around use cases.

My other thought is that calendaring functionality might not be on the
critical path for a first milestone. We'd still need to understand the
architectural assumptions - if there is a belief that event data
should be stored in JCR, for whatever reason, it would be good to know
it - but perhaps we don't have to work out the implementation just
yet.

But I'm just thinking out loud right now. wdyt?

~Clay

[John Norman]

I don't have clear ideas either. I do know that OpenCast Matterhorn is
wrestling with the exact same issues right now.

I believe it may be helpful to distinguish time/date trigger
information from enterprise calendering functionality. I can imagine
that we want to hold timetable information in an enterprise calendar
so free/busy calculations for meeting arrangements can take advantage
of others having solved the problem. However, I am less clear that
simple time/date event triggers need this treatment (and potential
performance hit). I can imagine working copies of time/date triggers
in Sakai with data going over the service/event bus to a calendaring
system for calendaring use of the same information.

But then what do I know? :-)
John

[Laura James]

With a rather user-level perspective:

I couldn't speak for overall Cambridge expectations, or what might be
needed for a first milestone release, but our user research and design
work did point to events and shared calendaring being an important
aspect of scholarly networking (and academic life); they feature
fairly heavily in our initial design wireframes.

Going rather more off-topic, I'm also currently responsible for
Talks.cam, and whilst this is currently an established standalone
service with heavy use within Cambridge, it's interesting to ponder
how well it has been adopted by academics, and what the next step
along its development path might be. Talks.cam is a system which lets
seminar organisers publicise their events easily, and talks attendees
to track events and seminar series of interest. It uses entirely user-
generated content. You can see the system in action at http://www.talks.cam.ac.uk
(although note many users use the system almost entirely via RSS/
iCal/email/syndicated web content, not the website!) and there is
limited information about our recent work on Talks here: http://egret-project.blogspot.com
including a brief outline of the data structures used.

I can imagine a future in which Talks.cam-like functionality might
exist in one form within Sakai3, or utilised within Sakai3 in some
way, but have not yet given any thought as to how that might work out.

Laura

On 11 Aug 2009, at 18:36, Clay Fenlason wrote:

>

[Ray Davis]

And from a Groups-n-Roles perspective: When talking to people and
surveying comparable products, I've found that a combined personal view
of events (along with activities like "what if?" comparisons of schedule
conflicts) is considered an important benefit of group membership
integration. Ideally -- that is, in terms of providing maximal user
benefit for minimal user effort -- Sakai 3 would be able to integrate
calendars even from external sources which didn't yet have collaborative
spaces explicitly devoted to them. An interesting hypothetical target,
at any rate...

Best,
Ray

[Ian Boston]

The intention was to investigate putting CalDAV ontop of the existing
JCR webdav implementation and allow event stores to appear at URL end
points.

The motivation is 2 fold:
1. Having spent some time looking at the OSX CalDav Server
implementation, I came to the conclusion that a significant amount of
the effort was in webdav and not caldav itself, leading me to think
that layering Caldav on JCR would not be too hard.

2. We the ability to provision many event stores, access controlled,
we would be able to start to model how those event stores would relate
to the other entities we have in the system, and perhaps do something
sensible with them.

I think, just as we are able to locate all my messages in an outbox,
it would be possible to locate all events of a certain type. This may
also relate to the Activity Store and Activity Feed work that Lance is
well progressed with after a week at cambridge.

------------------

It would be useful to have some clearer use cases of what we are
trying to achieve abstracted from technology so that we can create a
wide reaching and generic solution to this space, rather than getting
stuck addressing one narrow aspect of the problem space.

Ian

On 11 Aug 2009, at 18:36, Clay Fenlason wrote:

>

[Clay Fenlason]

Thanks, Ian. It's also been our experience (with prior CalDAV work)
that the difficult part ends up being with WebDAV's sphere, and not
the extra bits that CalDAV introduces. That makes sense. But it also
of course seems well-advised to leverage mature calendaring software
with a compatible license rather than create our own event services,
which seems to be the implication of the approach you've indicated.
Perhaps I'm misinterpreting.

I don't think this is a proper use case, but the simple situation is
that our campus has a central calendaring system, while at the same
time our users would like to see all their important events in a
single view (aggregable and filterable by adding and removing certain
calendars). It's currently a source of some frustration that Sakai
calendars are siloed off from other calendars of interest. By the
same token there is a desire that data from other calendars also be
represented within Sakai contexts. e.g. a faculty member wants to be
aware that they have a conflict with a planned class activity when
they attempt to schedule it. The blue-sky vision would be some sort of
federation of calendar stores, while a less complex solution involves
consolidation of event data in some central repository - in one
imagined configuration Sakai might not store any event data of its
own, but rather always ship it off to a separate repo and pull from
there when needed.

Other use cases involve Google calendar, or some other preferred
interface, and thumbing one's nose at the parochial campus calendar
system which is also to that extent siloed.

In any event, there would seem to be some advantage in standardized
integration points with external calendar stores, perhaps not unlike
user data, just with a different protocol. I take John's point about
not all event data being of the same class, but that may only firm up
the analogy. User and calendar data may be both externally provisioned
(though, again, the calendar use cases suggest to me both push and
pull), and yet there is also value in local storage for data
supporting Sakai-specific capabilities.

Have I mangled that sufficiently?

~Clay

[John Norman]

I'm not sure it helps to treat this as a single problem. I am more
sure it doesn't help to refer to the data represented in the calendar
as event data when 'events' has more than one meaning in Sakai. I
think it would be better to refer to 'calendar data' recognising that
some calendar data refers to a real world Event and some of it will be
derived from an internal Sakai event.

I suggest Calendar data should be thought of as simply, information
that is usefully represented in a calendar format (which confusingly
would include an Event list).

From there we consider what we might want to be able to do with
Calendar information.
1. Sync it with Calendar information in a Personal Information Manager
(Outlook, iPhone, etc.)
2. Present a filtered view for a specific group or course
3. Maintain the information for a specific group or course (by named
individual, role, or open)
4. Announce or publicise an Event (or series of Events) and make it
easy for an interested party to add the event to a personal or group
Calendar information store/view
5. Merge and unmerge one source of Calendar information with one or
more other sources
6. Choose a set of individuals or a group(s) and get free/busy time to
arrange a meeting, save the chosen date/time to a personal or group
Calendar or to the personal Calendar stores/views of all participants
etc.

In an ideal world I would like to see projects like Bedework offer an
OSGi bundle so that we could support the majority of use cases from
within Sakai for institutions without a separate enterprise calendar.
Then for the institution that has an enterprise calendar, perhaps we
would have an alternative bundle that handles the integration via
(probably) CalDAV according to some agreed rules about which system
has the master copy of which data (e.g. Sakai has the master copy of
course timetable information, but Enterprise Calendar has the master
copy of an individual's free/busy information).

So perhaps if we were to agree on this general approach the question
might become different - which scenario to tackle first? That in turn
might depend on external factors (e.g. can we find a useful enterprise
calendar OSG1 bundle that is compatible with Sakai?)

John

[Stephen Marquard]

Our local survey data suggest that task-related date information is very important to students, i.e. what is coming up that they need to work on or do this week, next week, etc.

I would say the key improvements over Sakai 2 would be to make this seamless (any activity, task, assessments etc. with a due or activity date should show up in a calendar without the creator needing to do anything extra), and to put the event visibility options under the user's control rather than site owner's, e.g. every context should have an iCal feed, and within Sakai users can manage their own personal calendar (=event list) in various ways, including setting filtering options (which contexts/sites do I want to see events for), and subscribing to and exporting iCal feeds.

So long as the iCal support is robust and comprehensive, people don't need to worry too much about which calendar is primary and which ones secondary (e.g. Sakai calendar, Google Calendar, institutional calendar like Groupwise/Outlook, etc.)

We haven't seen much demand for use case # 6 below locally, i.e. in a Sakai context people are more interested in event calendaring than availability calendaring.

Regards
Stephen

>>> John Norman <jo...@caret.cam.ac.uk> 8/12/2009 4:41 PM >>>

[Daphne Ogle]

Just to chime in that previous user research that I've been involved
in (course management in Sakai, content management with Fluid) also
pointed to the importance of a calendar that knows about all my
classes, events, due dates, social meetings, etc. (basically anything
I have to do with the ability to bring in things I might want to do as
well). And as others have said, we should let the computers do their
thing here and minimize the user effort for keeping things up to date
and managing multiple calendars. Users also need to see a context
specific view of their calendar. So they might have a view of
everything but also need to see just what's going on with a
particular, project, class or community. Doing this well, could
really attain user delight.

On #6 use case below, I've heard of this need also as it pertains to
groups. Scheduling meetings for student project teams are an easy
example of when this capability could make our user's lives much easier.

-Daphne

Daphne Ogle
Senior Interaction Designer
University of California, Berkeley
Educational Technology Services
dap...@media.berkeley.edu
cell (925)348-4372

[Michael Feldstein]

My recommendation is to invite the Bedework guys to participate in
this thread. I'll ask my friends in the Beehive group as well, but
they're up to their eyeballs right now and may not be available at
this moment.

Calendaring, particularly when you get into meeting scheduling and
availability, really is rocket science. Mike Douglass on the Bedework
team has been heavily involved in the calConnect standards effort and
a terrific grasp of the complexities involved with these use cases.
He's also an excellent communicator.

I don't think we want to assume too much here without having a
calendaring expert in the conversation.

> >>>> John Norman <j...@caret.cam.ac.uk> 8/12/2009 4:41 PM >>>

[Clay Fenlason]

You anticipate me :)

I started this thread because I'd just gotten off a call with the
Bedework guys about an integration, and realized that I couldn't speak
about this subject intelligently. I still can't, but the thread has
been a help. There is a real interest in working out an integration,
and I was just trying to pave the way by coming to an understanding of
how it might fit into our collective effort.

~Clay

[Bertrand Delacretaz]

On Wed, Aug 12, 2009 at 10:35 PM, Clay Fenlason<khom...@gmail.com> wrote:
> ...I started this thread because I'd just gotten off a call with the
> Bedework guys about an integration...

Note that such an integration might be might be worth having in Sling
if that's possible - at least for the core parts like using JCR and/or
Sling as a backend for the Bedework stuff (if that makes sense - I'm
totally ignorant about Bedework).

-Bertrand

[John Norman]

I don't know if this is worth a wiki page or not. My simplistic
thinking is that it would be useful not to have to write lots of code
for calendar-specific functionality. If we were to rely on a 3rd party
solution of some kind we should be able to write down the sort of
information we would expect to send to the 3rd party code and what
information we would expect to get back. Can we collect such
interactions? Here is a contribution:

1. Store calendar data. A place we could send time/date (Event)
information to with a context . A key issue for 3rd party code
therefore is whether it can 'understand' the context information
needed for Sakai use cases. This service will need to store
information securely/reliably (transaction support on transmission/
receipt?) and allow editing/overwriting of individual data elements

2. Return aggregated data for a given a context and support different
aggregations for different contexts. It is interesting to consider
whether we would want to have this returned as html or whether we
would want/need to handle presentation issues in our UX code. It
implies that the 3rd party code would need to be capable of modelling
Sakai contexts. (e.g. give me the official timetable for this course,
or give me all the important events for this course such as assignment
deadlines; give me a personal calendar i.e. all the Events that affect
me, or give me a summary of important deadlines that affect me)

Possible additional features that make using third party code more
likely to be desirable.

3. Provide aggregated data by context to other applications (Google,
iPhone) in a suitable format

4. Accept time/date (Event) information from other applications within
a specified context. An issue I can imagine cropping up is that if we
aggregate multiple contexts on the server before delivering an
aggregated context (all my Events) to a client, then the client may
not be able to specify which of the original contexts a client-
generated event should be identified with.

My understanding of the current Sakai calendar service is that it has
some attractive features (e.g. ability to associate Sakai resources
with events) that would be a shame to lose, that the basic calendar
service is probably easier to re-implement than work out integration
with 3rd party code, that basic calendar functionality has a rapid
inflection point of difficulty when you get into features like
repeating events, notifications and PIM integration where there is no
substitute for accumulated experience.

So I would like to see some consideration of what the current Sakai
Calendar api supports and how that maps to Bedework apis (if there are
any - I couldn't see a lot of application integration documentation on
the Bedework site) and (maybe) to Google apis. I would also like to
see more developed use cases (or at least some collecting together of
existing documentation of use cases) to get a better handle on what we
think this all means in terms of end-user functionality.

John

[Michael Korcuska]

Hi Bertrand,

Bedework is a shipping product built with Hibernate and therefore
doesn't use the JCR model. It would be tough for them to migrate to
Sling. Perhaps there is another alternative (extending Bedework to put
certain data into JCR in addition to putting it directly in the DB?
This comment likely shows I'm clearly a manager, not a developer).

And Bedework as an enterprise calender back-end and front-end is
likely to be too heavyweight to embed in Sakai (certainly Sling). It
might not even run in the same JVM. Certainly in an enterprise
configuration you would be very likely to run them inside separate
containers. And there would be other enterprise applications that
would want to integrate with a calendaring system as well.

The tough part for Sakai is that we would ideally have a thin slice of
calendar functionality "built in" but (a) more complex functionality
is out of our scope/area of expertise and (b) users usually want to be
interacting with a central calendar that contains all of there data.

More comments in reply to John's email...

Michael

--
Michael Korcuska
Executive Director, Sakai Foundation
mkor...@sakaifoundation.org
phone: +1 510-859-4247 (google voice)
skype: mkorcuska

[Bertrand Delacretaz]

Hi Michael,

Thanks for the clarifications - what would make sense at the Sling
level is calendaring services, which store their data in JCR so as to
make it interoperable easily with other content. But from your
description I understand that's probably out of scope for Bedework.

-Bertrand

[Michael Feldstein]

My highly limited understanding of the technical issues involved is
that Bedework's use of Hibernate does not necessarily preclude a
common calendar object store with a JCR-based application like Sakai
3. Bedework could pull data from the store using Hibernate and Sakai
could pull data from the same store using JCR. So one area to explore
in terms of integration would be to set up the model in JCR to store
the calendar event objects in a format that will also make sense to
Hibernate. That may mean nothing more than implementing the calDAV
extensions, but I'm really over my head here. The Bedework guys will
know better.

- m

On Aug 13, 10:25 am, Michael Korcuska <mkorcu...@sakaifoundation.org>
wrote:

> Hi Bertrand,
>
> Bedework is a shipping product built with Hibernate and therefore  
> doesn't use the JCR model. It would be tough for them to migrate to  
> Sling. Perhaps there is another alternative (extending Bedework to put  
> certain data into JCR in addition to putting it directly in the DB?  
> This comment likely shows I'm clearly a manager, not a developer).
>
> And Bedework as an enterprise calender back-end and front-end is  
> likely to be too heavyweight to embed in Sakai (certainly Sling). It  
> might not even run in the same JVM. Certainly in an enterprise  
> configuration you would be very likely to run them inside separate  
> containers. And there would be other enterprise applications that  
> would want to integrate with a calendaring system as well.
>
> The tough part for Sakai is that we would ideally have a thin slice of  
> calendar functionality "built in" but (a) more complex functionality  
> is out of our scope/area of expertise and (b) users usually want to be  
> interacting with a central calendar that contains all of there data.
>
> More comments in reply to John's email...
>
> Michael
>
> On Aug 13, 2009, at 00:34, Bertrand Delacretaz wrote:
>
>
>

> > On Wed, Aug 12, 2009 at 10:35 PM, Clay Fenlason<khomo...@gmail.com>  

> > wrote:
> >> ...I started this thread because I'd just gotten off a call with the
> >> Bedework guys about an integration...
>
> > Note that such an integration might be might be worth having in Sling
> > if that's possible - at least for the core parts like using JCR and/or
> > Sling as a backend for the Bedework stuff (if that makes sense - I'm
> > totally ignorant about Bedework).
>
> > -Bertrand
>
> --
> Michael Korcuska
> Executive Director, Sakai Foundation

> mkorcu...@sakaifoundation.org

[Michael Korcuska]

I started a wiki page although it doesn't have much content on it. It
does point to this thread so those not following K2 can see this
discussion and potential join in. We should get those (e.g. Beth) who
worked on the in Sakai 2 to chime in on lessons learned. If the
discussion comes to some conclusions and/or starts to pick up more
momentum we should probably move this to sakai-dev. In any case, wiki
page at:

http://confluence.sakaiproject.org/x/dQbtAw

There is a deployment/implementation issue here as well. To state it
simply, there are Sakai adopters who have an enterprise calendar and
the ability to integrate Sakai with it and there are users who don't
or can't. The former probably want to lean on the enterprise calendar
(maybe this is a false assumption?) and the latter want Sakai to have
a fairly rich set of calendaring capabilities.

To me this suggests, like we're doing with Jackrabbit, shipping Sakai
with at least a light-weight calendaring system (could we help
Bedework to create Bedework light?) or, dare I say, integrating it
with Google calendar out of the box. This would allow someone to try/
pilot Sakai without having to configure a separate calendar server.
But then lets them move to an enterprise solution later, either by
integrating with their enterprise calendar or at least moving Bedework
to a separate server.

Ideally there would be a standards-based API for this type of thing
but currently there is not. Bedework is working, inside the context of
CalConnect (http://www.calconnect.org/) to produce a draft for
consideration by the end of the year. This is good news but there are
no guarantees that becomes accepted or adopted in the form it will
take this year. This probably means a fairly significant Sakai-side
layer to insulate us from the particulars of individual calendars.

I need to run to the OER conference in a minute. So a few more
comments inline.

On Aug 13, 2009, at 03:06, John Norman wrote:

>
> I don't know if this is worth a wiki page or not. My simplistic
> thinking is that it would be useful not to have to write lots of code
> for calendar-specific functionality. If we were to rely on a 3rd party
> solution of some kind we should be able to write down the sort of
> information we would expect to send to the 3rd party code and what
> information we would expect to get back. Can we collect such
> interactions? Here is a contribution:
>
> 1. Store calendar data. A place we could send time/date (Event)
> information to with a context . A key issue for 3rd party code
> therefore is whether it can 'understand' the context information
> needed for Sakai use cases. This service will need to store
> information securely/reliably (transaction support on transmission/
> receipt?) and allow editing/overwriting of individual data elements

There are other date/event-based functionality that Sakai will need
natively to support a variety of things (like conditional release...is
this the kind of "context" you mean?). Whether these events appear on
a particular calendar seems to me to be very context specific (do we
need a "show this on the site calendar" option)?

I wonder if there is a way to draw a fairly clear line between time/
date-based information we would want to store externally and that we
would want to have present natively.

>
> 2. Return aggregated data for a given a context and support different
> aggregations for different contexts. It is interesting to consider
> whether we would want to have this returned as html or whether we
> would want/need to handle presentation issues in our UX code. It
> implies that the 3rd party code would need to be capable of modelling
> Sakai contexts. (e.g. give me the official timetable for this course,
> or give me all the important events for this course such as assignment
> deadlines; give me a personal calendar i.e. all the Events that affect
> me, or give me a summary of important deadlines that affect me)
>
> Possible additional features that make using third party code more
> likely to be desirable.

Ideally both. In most cases we'll simply want to display what the
third party system provides. In any casein the long run it is probably
a mistake to think that Sakai will be able to do this kind of calendar
display management better than the calendar systems themselves. But
sometimes we may need a filter on this information that isn't
currently supported. So the ability to get the data, rather than just
embedding the calendar, is certainly nice.

>
> 3. Provide aggregated data by context to other applications (Google,
> iPhone) in a suitable format

I don't get this, quite. I would think this is primarily the
responsibility of the third-party calendaring system. Or are you just
saying we need to have a way to provide, for example, iCal feeds,
regardless of how we do it? If so, then absolutely.

>
> 4. Accept time/date (Event) information from other applications within
> a specified context. An issue I can imagine cropping up is that if we
> aggregate multiple contexts on the server before delivering an
> aggregated context (all my Events) to a client, then the client may
> not be able to specify which of the original contexts a client-
> generated event should be identified with.

Can you give an example or use case here?

I don't know that iCal truly supports aggregated calendars here--I
know I manage by mixing multiple calendars into a single display and
would love to be able to create aggregates. There are some services
that provide this kind of thing (http://www.mashical.com/) but this
capability isn't built into the calendars I currently use.

In any case this is the kind of thing we shouldn't be in the business
of doing. I know you agree with that (at least I hope you do).

>
> My understanding of the current Sakai calendar service is that it has
> some attractive features (e.g. ability to associate Sakai resources
> with events) that would be a shame to lose, that the basic calendar
> service is probably easier to re-implement than work out integration
> with 3rd party code, that basic calendar functionality has a rapid
> inflection point of difficulty when you get into features like
> repeating events, notifications and PIM integration where there is no
> substitute for accumulated experience.

I note that google calendar now allows you to add attachments to
events. Not everything we would want, but interesting. There is also a
bunch of display-side functionality that we would be expensive to
replicate.

--
Michael Korcuska
Executive Director, Sakai Foundation

mkor...@sakaifoundation.org

[Ray Davis]

Staying completely agnostic about the Bedework question itself, I want
to point out what seems to me an important difference between the
current K2 source tree and the Sling project. (I also want to check my
understanding, since it may be out of date or otherwise delusional.)

Sling (like Jackrabbit) gives the option of using either its own
hand-crafted file-system-hosted persistence mechanism or a SQL database
for storage. Taking advantage of that flexibility, K2 _assumes_
underlying use of SQL. As a result K2 can integrate with EclipseLink to
provide access to JPA (the Java standard interface for the sort of DB
mapping Hibernate provides).

On the minus side, this adds another "persistence layer" to tune. But
the plus sides far outweigh this concern, IMO.

For one thing it gives an "escape hatch" when/if K2 services themselves
would benefit from use of a relational database. (I remember this being
mentioned in the pre-Sling days as an approach to auxiliary big flat
key-value storage, but my impression is that Ian's development of
BigStore (tm) has taken most of the pressure off there.)

Even more excitingly (to me, anyway), it should make it easier to
integrate efficiently with with non-Sling / non-Jackrabbit applications
and with service libraries that rely on relational databases for storage.

In other words, it makes "We will build everything Sakai 3 needs on a
Jackrabbit foundation" a less risky proposition. Being a rather
risk-adverse engineer, I find this reassuring.

Best,
Ray

[Michael Feldstein]

My impression is that ICOM could help with a lot of this (e.g.,
integrating w/Google Calendar and Bedework, providing context to
calendar objects, etc.) but, like the calConnect work, much of it is
not available today. That said, the Beehive REST APIs, which will be
submitted to the ICOM working group as the basis for the ICOM REST
APIs, will be available very soon and could form the basis of any
Sakai-specific calendaring capabilities that would need to be
implemented. This could save the community time.

What is the general sense of when you realistically hope calendaring
will be in a release in some form? The December 09 milestone? Summer
2010? Summer 2011?



On Aug 13, 12:19 pm, Michael Korcuska <mkorcu...@sakaifoundation.org>
wrote:

> ...
>
> read more »

[Carl F. Hall]

K2 assumes that all things content will go into JCR. While JPA is available via EclipseLink, the only use I know of was for search indices to speed up digging data out of JCR. I don't know that this is an issue any more but the intention has always been that data lives in JCR and a relational provider/RDBMS is not brought into the picture unless absolutely needed. There have even been talks to make sure RDBMS support is less attractive, so that they rethink their model and are encouraged to use JCR.

[John Norman]

> What is the general sense of when you realistically hope calendaring
> will be in a release in some form? The December 09 milestone? Summer
> 2010? Summer 2011?

The first thing is to answer the question originally posed and
reinforced by Ian's request for use-cases: What do we mean by having
Calendaring in Sakai 3?

From this thread I have a tentative picture:
- We will determine a set of data items that contain date/time
information that might usefully be represented in Calendar format
(Events with capital E) and we will support the creation and editing
of such Events. Events can include point events like an assignment
submission deadline as well as time-range events like a meeting start/
finish. We will want a classification of Event types that users would
find useful for filtering purposes.
- Sakai will want to maintain sets of Events for groups. So there will
be a way of associating Events with groups. There will be an interface
for maintaining the list of Events associated with a particular group.
If possible the storage of these events lists will use a standard
Calendar api, such as iCal, CalDAV, etc. We will need to resolve
whether an external store is used by default and if so how search is
handled.
- There will be an interface for aggregating Event lists into a single
Calendar presentation (myCalendar/myEvents) for Sakai-generated
content and ideally an option to subscribe to external Event lists of
relevance (probably iCal). The personal aggregated Calendar data
widget will be placeable in multiple Sakai locations

This should be all we do in Phase I

- Ideally we would be able to demo use of an external store for the
Event lists and that External store (Bedework/Google) would support
onward integrations with personal information managers (Outlook, iPhone)

In a Phase II we would look at providing an OSGi bundle for
Calendaring in Sakai that provided some of the basic functionality of
the external store (Bedework lite?) for those institutions that want
more sophisticated Calendar support without deploying and enterprise
calendar solution.

With that hazy picture in mind, I think we should aim for Phase 1 by
summer 2010 and Phase II by summer 2011 (if we can get help from
Bedework or similar)

All subject to contract!

Within that broad and hazy picture it is interesting to speculate
about the ICOM standard for Event information (as well as CalConnect
efforts) and how they fit in with other standards. It seems like we
might want ICOM as a native format and iCal/CalDAV for interfacing to
more loosely coupled systems - but I don't yet know enough to speak
confidently about that.

Make sense?

John

PS not really addressed because this is the K2 list, but there has
been some good work at GaTech on CalDAV in Sakai 2, which could mean
an external CalDAV store might help with transition from 2 to 3. But I
haven't looked into that aspect of the picture and it might involve
more Sakai 2 development work.

[Michael Feldstein]

One of the interesting aspects of ICOM is the strong emphasis on
separating the artifacts from the transports (nouns and verbs). ICOM
properly representing artifacts and their containers upon which it can
perform basic CRUD operations. It then deduces from the kind of
artifact being manipulated and the container in which it lives what
kinds of actions should be taken. For example, it would deduce from a
calendar Event object being created in an Out Box container that a
meeting invitation should be sent to the Event invitee list via, say,
iCal. So, in the ICOM world, this would mean focusing first on
representing the objects and containers in JCR nodes, properties,
and...whatever other thingies that JCR has for representing objects
(including metadata) and their containers. Ideally, you'd want to be
able to represent everything in JCR so that it gets stored in such a
way that an ORM-based system like Bedework could call the same data
and find something that it understands (which wouldn't preclude Sakai
from continuing to call it via JCR). My understanding is that ICOM is
largely transport-agnostic, so iCal (or RSS, IMAP, XMPP, etc.) should
be compatible with ICOM rather than competitors to it.

Regarding "types" of events (e.g., assignment deadline), these are
represented in ICOM as relationships. So, for example, Event A
(represented by a URL) is a Due Date for Assignment B (also
represented by a URL). I'm getting over my head again, but my
understanding is that you can think of these (and represent them) as
RDF triples, although that's not the only way it can be done by any
means.

ICOM and calDAV integrations between Sakai and Bedework aren't
mutually exclusive. If you want to store all your events in Bedework
via calDAV, but you also want to be able to, say, filter for only
those that are assignments, I'm not sure that calDAV can help you
there. ICOM can--but only if/when you implement the full object
model.

For now, my sense is that the ICOM REST APIs (or, to be more accurate,
the BDK APIs) could provide you with REST interfaces for manipulating
calendar Events in the data store, possibly (probably) including
calling a number of events for the purposes of aggregating them in the
UI. You'd need to add the transport interfaces separately.

I could be wrong about any or all of this, though. I'm going to try to
get one of the Beehive guys to look in on this thread and comment.

[Michael Korcuska]

On Aug 13, 2009, at 11:02, John Norman wrote:

> - Sakai will want to maintain sets of Events for groups. So there will
> be a way of associating Events with groups. There will be an interface
> for maintaining the list of Events associated with a particular group.
> If possible the storage of these events lists will use a standard
> Calendar api, such as iCal, CalDAV, etc. We will need to resolve
> whether an external store is used by default and if so how search is
> handled.

Not to be splitting hairs, but groups or sites or both? I was
wrestling with this a bit this morning. I *think* the answer to this
is sites (under the assumption that most groups will have a site
associated with them).

[John Norman]

I *think* the right relationship is with a group - any group may wish
to have some specific Events just for them. When the group is the
membership of a Site, then the group Event is naturally a site Event.

If I think of the site as the virtual equivalent of a place where
things come together. The Event of the cricket match that takes place
(or not) on the 2nd of July from 11:00 to 18:30, is an event for the
two teams involved more than for the cricket pitch. A dodgy metaphor I
know, but what are we to do without Chuck Severance's golden touch in
the art of the metaphor?

:-) John

PS sort of interesting if you look ahead to room bookings, etc.
(another sort of date/time info store that would benefit from a
Calendar view presentation), but I'm not going there for now.