W3C home > Mailing lists > Public > www-rdf-calendar@w3.org > May 2001

Re: Why do we need RDF calendaring?

From: Libby Miller <Libby.Miller@bristol.ac.uk>
Date: Tue, 8 May 2001 14:39:34 +0100 (BST)
To: "Reza B'Far" <rbfar@cienecs.com>
cc: Libby Miller <Libby.Miller@bristol.ac.uk>, www-rdf-calendar <www-rdf-calendar@w3.org>, "d.m.steer" <d.m.steer@lse.ac.uk>
Message-ID: <Pine.GSO.4.21.0105081110010.4550-100000@mail.ilrt.bris.ac.uk>

Ok, this is a very interesting approach. So rather than describing
calendar events themselves in RDF, you want to describe software
interfaces and configuration in RDF. This is quite general, but
calendaring might be a good application of it. 

I reckon one of the most interesting applications of this might be a
distributed scheduling system in which you could describe your personal
or organisational calendar service in RDF and have other software
communicate with it to organise meetings and so on. This is rather like
what the ietf were aiming for with email with the iCalendar
Transport-Independent Interoperability Protocol (iTIP)


My colleague Jan Grant is interested in this sort of thing - Jan has
pages at



On Mon, 7 May 2001, Reza B'Far wrote:

> Libby:
> I've been looking at RDF as a way to describe software components.  I
> arrived at this because I saw no non-proprietary way of putting software
> components together.
> The reason I joined this group is to see how people are thinking of creating
> ubiquitous software components the do the business logic for calendaring and
> are described with RDF.
> The language the the software component is written in (for example
> C++/Java/etc.) and the container that runs the program (for example J2EE
> appserver, COM/DCOM infrastructure of Windows, etc.) are both proprietary.
> Those mechanisms should not be used to describe what the component is
> because otherwise cross-platform component development is impossible.
> XML itself is not sufficient because the resources that a component uses may
> be require meta data that is very complicated and/or resources that are not
> text (for example streaming media, voice, etc.)
> So, I'm looking into writing a P2P framework using Java as its default
> language which uses RDF as the mechanism that describes the components.
> That way the actual components wouldn't have to be in Java.  They could be
> in  C/C++/Perl whatever.  The input and output to them could be XML and the
> way you configure them is exposed through RDF.  RDF is also used for the
> framework to understand a given component, what it can do, how it interacts
> with other components, etc.
> One of the most widely used applications of computing is Calendaring.  So,
> this is one of the first pieces I need to look at.
> But, I might be wrong.  So tell me if I am :-)
> Reza
> ----- Original Message -----
> From: "Libby Miller" <Libby.Miller@bristol.ac.uk>
> To: <www-rdf-calendar@w3.org>
> Cc: <d.m.steer@lse.ac.uk>
> Sent: Monday, May 07, 2001 5:50 AM
> Subject: Why do we need RDF calendaring?
> >
> >
> > Hi all,
> >
> > This list has been very quiet recently, partly because lots of people
> > have been at W10. I'd like to get some ideas flowing on this list now
> > that people are getting back. I want to start with a biggie: Why do we
> > need RDF calendaring and scheduling?
> >
> > I've been reading a lot of rfcs about iCalendar and there are a lot of
> > products already using the IETF's iCalendar[1] format and protocols,
> > such as Outlook Express, Netscape Communicator Professional and
> > Palm. Basically, the interchange format of iCalendar is just fine for
> > most calendaring and scheduling purposes. The IETF have spent a great
> > deal of time and effort getting it right. It wouldn't be very useful
> > simply to convert iCalendar into XML. Is there any point in converting
> > it to RDF?
> >
> > Well (you might argue) RDF can give you
> >
> > * extensibility (but iCalendar is extensible)
> > * unique identifiers (but iCalendar uses email addresses and urls to
> > identify people and locations)
> > * tools for parsing (RDF tools are not mature; XML tools are more
> > mature; iCalendar tools are very mature)
> >
> > I've been thinking about this and chatting with Dan Brickley and Jan
> > Grant among others. I'd agree with Dan that the answer lies in the
> > connections we can make with other kinds of data if we are able to
> > convert iCalendar to RDF.
> >
> > One example might be: I'm learning about SMIL; I find the W3C
> > recommendation for SMIL; from this document and other RDF documents on
> > the W3C site and elsewhere I can find meetings at which the document was
> > produced and altered. I can then find out who attended the meetings and
> > more about their connections and affiliations from other RDF databases
> > such as RDFWeb. I can also find other documents that were inputs to the
> > meetings and also other outputs from the meetings such as minutes and
> > photos.
> >
> > Much of this data is already available on the web. Putting all these
> > types of information, including meetings and other events in an RDF
> > calendar format connects up this information to make my life easier when
> > I start doing research on SMIL. Putting calendar information in RDF is
> > only a part of the project of putting all these different kinds of
> > information in RDF.
> >
> > any thoughts?
> >
> > Libby
> >
> > [1] IETF Calendaring and Scheduling (calsch) WG
> > http://www.ietf.org/html.charters/calsch-charter.html
> >
> > (see links at the bottom for calendar-related RFCs)
> >
> >
> >
Received on Tuesday, 8 May 2001 09:41:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:43:46 UTC