- From: Dan Connolly <connolly@w3.org>
- Date: Mon, 02 Jul 2001 09:43:33 -0500
- To: Libby Miller <Libby.Miller@bristol.ac.uk>
- CC: Dan Brickley <danbri@w3.org>, Jan Grant <Jan.Grant@bristol.ac.uk>, Aaron Swartz <me@aaronsw.com>, Alan Davies <aland@steltor.com>, Michael Arick <marick@cse.ucsc.edu>, brian_mcbride <brian_mcbride@hp.com>, d.m.steer@lse.ac.uk, Owen Ambur <Owen_Ambur@fws.gov>, bill.morgan@gsa.gov, RDF Calendar <www-rdf-calendar@w3.org>
Libby Miller wrote: > > Hi all, > > I think that we're really getting somewhere with the RDF version of > iCalendar. I thought it might be useful to have a think about what we > want to/need to do in the next few weeks. > > Please tell me what you think, and let me know about anything else you'd > like to be on this list. I'm not sure I'm completely up to speed, but I've read at least some of the discussion of this schema. It's given me lots of interesting things to think about, and yes, it seems to be coming together. For me, coming up with an exact RDF model for iCal isn't a goal. For one thing, I don't know what an exact model would be; you can always model things in more detail, give more axioms, etc. For me, the goal is a *working* RDF model for iCal; i.e. an RDF schema with lots of tools and data and services available. The semantics of an RDF schema are grounded in one of two places: -- mathematics -- social practice Most of the concepts in calendaring are not mathematical; there's no math formula for computing the organizer of a meeting; the organizer of the meeting is the one who claims to organize the meeting, provided that claim is accepted by other folks. So let's get a bunch of social practice (real world data and tools and services) going around this schema. A couple other relevant principles come to mind: * data that isn't consumed rots. and the corollary: * model only those distinctions that you can exploit. So... what's a use-case we can work on together? How about the SWWS event? http://www.semanticweb.org/SWWS/ There are lots of relevant sources of data -- OAG flight schedules -- my palm pilot -- the meeting organizers -- local night-life event calendars If folks provide data about any of the above in iCal/RDF format, I can (almost certainly) map it into and out of my palmpilot schema. By the way: I have palm datebook->HTML, so that would give us iCal->HTML, indirectly. Oh... another tool I wrote recently: extract RDF from Navigant travel itineraries, which come in a plain-text database export format: http://www.w3.org/2001/07dc-bos/grokNavItin.pl and rules to map the results to palmpilot RDF: http://www.w3.org/2001/07dc-bos/itin2datebook.n3 I'm not comfortable sharing the data that I used to develop that tool, but for the SWWS, I'm probably willing to make my travel info public (unless we can come up with a working access control toolset real quick!) Who wants to set up a query service for this event? i.e. one that can grab RDF from (near) my home page and the meeting page etc. on the fly, run rules, and query the results? > I will put these up in a webpage when we've > had some discussion about them. I have time to do some or most of this > work, although I would be very grateful for any help. Whoever does > the work, I'd like some confirmation that we are heading on the right > track. > > all the best > > Libby > > 1. Datatypes > > * make sure that the DAML syntax is used for all datatypes I suspect this means the DAML syntax and the XML Schema Part 2 URIs. The URIs are at least as important as the syntax we use to connect them. > * decide the issue of whether we allow UTC or not in the rdf:value of > datetimes (XML datatypes does; iCalendar doesn't, although you can have > a UTC property on datetime). I don't know exactly what you mean by that; pointer to an example or something? > 2. Namespaces > > * think about splitting up the hybrid iCalendar schema into a few > different namespaces, for example: > > - dates, times > - repeating properties and classes > - timezone properties and classes? > > -.... > > with the intention of making using part of the schema as simple as > possible. I doubt we have enough experience to know what "as simple as possible" looks like for those modules; I wouldn't be confident until I'd used them in at least three different contexts. I suggest an orthogonal approach: let's make a namespace specific to this (SWWS) event; if it works out, we can keep using it. If not, we can map it to other namespaces. > * think about the links between namespaces and iCalendar > properties and classes, e.g. dc:description, > dc:date; foaf:Person; daml:duration > > * think about utilty namespaces, which have classes and properies to do > with icalendar, but are not part of it, for example, presenter (of a > conference paper); output (a document, of a meeting); input (maybe a > reading list for a tutorial, or a document for a meeting) > > * find a permanent home for the namespaces themselves > > 3. Documentation and examples Perhaps a short version of my input is: do this (doc/examples) first. > * compare models of events using examples: daml, palm, rss event, > skical, iCalendar > > * write some how-tos, using plentiful examples > > * write up the reasoning behind the choices we made in the RDF schema > > * write some implementations > > anything else? -- Dan Connolly, W3C http://www.w3.org/People/Connolly/
Received on Monday, 2 July 2001 10:44:11 UTC