- From: Shannon J. Clark <shannon@jigzaw.com>
- Date: Wed, 30 May 2001 11:57:06 -0500
- To: "www-rdf-calendar" <www-rdf-calendar@w3.org>
Libby, A couple of your last points/questions I think are already or could already be addressed within the context of iCal. iCal has a concept of Parent/Child relationships - this might be a way to define the relationship between the conference and the seminars at the conference for example. There is also a RELATED_TO, and a SIBLING property for lateral relationships (SIBLING is within the same tree, RELATEDTO is across trees). Time related databases tend to store dates in some standardized way (usually measuring increments from some fixed point - i.e. in Unix seconds since the Unix epoch) - these are then converted back to Day/Month/Year/Hour/Min/Second/microseconds dependant on the system. At this point there are functions to extract this information. The issues arise in that there are some NON-transformable elements. i.e. it is NOT the case that ONE DAY == 24 hours (twice a year in areas with Daylight Savings there are days that break this), nor can you state that ONE MONTH == N Days - it depends on the Year and the Month in question (and further, you can't equate ONE MONTH to hours, minutes, or seconds) Storing each field - Year, Month, Day, Hour, Minute, Timezone as separate fields may lead to less connection between these elements - the time really is ALL of the above working together (i.e. there are some times that simply don't exist at all - just saying 2:30 AM is not enough to know this, you also have to know the Year, Month, Day, and Timezone to determine if the time is or not (see Daylight Savings) There are many defined schemas for storing time, I do NOT suggest that for this effort we reinvent the wheel, the issues involved are VERY complex. Shannon Shannon J. Clark CEO - JigZaw, Inc 1.800.4.JIGZAW (454.4929) shannon@jigzaw.com www.jigzaw.com -----Original Message----- From: www-rdf-calendar-request@w3.org [mailto:www-rdf-calendar-request@w3.org]On Behalf Of Libby Miller Sent: Wednesday, May 30, 2001 5:55 AM To: Greg FitzPatrick Cc: 'Libby Miller'; www-rdf-calendar Subject: RE: RDF calendar schemas > > That is great - I would like to know your opinion of Jonas's work > > http://lists.w3.org/Archives/Public/www-rdf-interest/2000Aug/0109.html > > How much of this do you find usable? Some background: this url points to an RDF representation of Skical by Jonas Liljegren. Skical [1] includes a representation system for public events such as concerts, sports events. It builds on iCalendar and extends it with information needed for public events such as information about disabled access, availability of alcohol etc. Jonas' work on Skical is highly relevant to work turning icalendar into RDF. I've described a strawman calendar schema [2] in order to have something to play with which looks a lot like Jonas's description of Skical in RDF, except for the dates. My schema uses rdf:label, which is wrong. Otherwise, I'd agree that the structure of the RDF representation can be essentially flat. Jonas' work is a good place to start. However, in trying to query and use data like this, I have some issues I'd like to bring up, concerning dates, repeated events and sub-events. Dates Should we be using XML schema datatypes to define dates? Especially given the difficulties with the XSD namespace in RDF? In addition querying anything which requires regexes or just partial string matching as jonas's schema does within any of the current RDF apis isn't possible, although query languages for RDF may well have these capacities. This affects the form which dates can take. Ideally we would want to have the option of separating out hour, minute, date, month, year, into separate nodes as I started to do. Repeated events Repeated events are the most problematic area of calendaring. I haven't looked into representating repeated events in RDF at all, so I can't evaluate what Jonas has done yet. sub events Finally, I found it very useful in modelling the XMLEurope data to have the notion of one event being contained within another. For example, a track is a kind of event which might be spread over one or more days at a conference, which contains various presentations, also events. Or is a track is too broad for you, a session might contain more than one event, and may plausibly be considered an event in itself. The vaclendar is a container for events as I see it. We'd still need an RDF property to indicate somehow that there was more data about the event available (maybe rdf:seealso would do?). Does this make sense? cheers Libby [1] skical: http://ski.finns.nu/ [2] strawman RDF calendar schema: http://ilrt.org/discovery/2001/05/ical/index.rdf sample instance data http://swordfish.rdfweb.org/discovery/2001/05/xmlecal/track1.rdf XML Europe demo: http://swordfish.rdfweb.org/discovery/2001/05/xmlecal/ > > > You have both the Dawson and Reddy DTD's as reference I hope? > > > > Greg > > >
Received on Wednesday, 30 May 2001 12:57:24 UTC