Re: RDF Calendar todo list

I'd suggets that we use www-rdf-calendar@w3.org rather than a long cc
list for the rest of this thread.

Thanks Dan, this is great


> 
> 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

I'd agree with this. It isn't always clear how to map the iCalendar
constructs into RDF. Already we are beginning to move away from the 
closest representation by talking aboiut including UTC offsets, and part
of the motivation for that was inclusiveness and simplicity.

> So let's get a bunch of social practice (real world data and
> tools and services) going around this schema.
> 

sounds great.

> 
> 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?

thanks Dan. I'd love to do this, and I'm sure there are others out there
who would too.


> > 
> > 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.

ok. as  understand it there's a problem with using the XML schema
datatypes uri in RDF. Yes, there's an RDF issue:

http://www.w3.org/2000/03/rdf-tracking/#rdfms-qname-uri-mapping


[[
The algorithm for mapping a QName in the RDF XML syntax to a URI is to
concatenate the URI of the namespace with the localname part of the
QName. In the case of namespaces, such as the XML Schema datatypes
namespace, which do not end in a "#" character, then the URI reference
generated by this algorithm is not the same as the
conventional URI for the concept.
]]

does anyone have a sense of how important this is, and whether it is
likely to be resolved soon?


> 
> > * 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?
> 

I've a bunch of example data here
http://ilrt.org/discovery/2001/06/content/

e.g.

<ical:DTSTART> 
    <ical:DATE-TIME> 
	<ical:TZID rdf:resource="#CET"/>
	<rdf:value>20010525T114500</rdf:value> 
	<util:hour>11</util:hour>
	<util:minute>45</util:minute> 
    </ical:DATE-TIME>
</ical:DTSTART>

from track1.rdf

this example references a TIMEZONE object, and so UTC offset is
redundant and not allowed in Icalendar rfc 2445

[[
The form of date and time with UTC offset MUST NOT be used.
]]

However the XML datatypes document does allow this expresssion of date
times:

http://www.w3.org/TR/xmlschema-2/#isoformats

moreover this is actually the most convenient way for most cases
for writing down a datetime.

see 
http://lists.w3.org/Archives/Public/www-rdf-calendar/2001Jun/0034.html
http://lists.w3.org/Archives/Public/www-rdf-calendar/2001Jun/0032.html

for the reasons why this decision was made in iCalendar, which mostly
have to do with recurrance rules.


> 
> > 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.
> 

sounds like a plan. Any splitting would have to be done with a lot of
development input, I think.

cheers

libby

Received on Monday, 2 July 2001 11:50:45 UTC