(A) I have seen these before. Some minor nits:
Many of the VALARMs have an ATTACH property that is not valid:
ATTACH;VALUE=URI:Ping
Extra CR LF's in them between components.
Sorry, could you clarify? the ics files in that directory are all generated from tools which export iCalendar.
Yes incorrect. When they have the METHOD property for example. See the restrictionSome VEVENTs have no SUBJECT or DESCRIPTION.
Descriptions and summaries are optional, as I understand it - is that incorrect?
(B) RDF issues I have noticed in the examples:How do you handle VALUE=x-user-type ?
I noticed that the RDF format drops the 'VALUE' parameter completely.
VALUE (as in VALUE=BINARY, VALUE=DATE) is handled in various ways within the RDF model. So in RDF whether something is text or a uri is a crucial distinction handled by the RDF syntax. Whether something is a DATE or a DATETIME is handled using different RDF properties.
I think the main thing is that we can roundtrip between the RDF and
iCalendar versions, so we aren't losing information - inevitably there
will be differences in the syntactic representation that are difficult
to explain as we are translating between two different representational
languages.
Okay, perhaps because it looked different from the way the other property valuesThe RDF-cal has a 'class' tag, that is not the same as the iCAL 'class' tag.
hm, it's not intended to be different. All we have done is create uris to represent the possible values for class, i.e. public, private, confidential become
<class rdf:resource='http://www.w3.org/2002/12/cal/ical#private'/>
etc
this just fits in better with the way RDF works - it's much better at matching URIs than strings.
Maybe ... still thinking about this.The examples drop the CLASS property nd its PUBLIC, PRIVATE, and CONFIDENTIAL values completely.
The RDF-cal does not distinguish between property values and parameters.
this distinction doesn't really matter to RDF :) We don't think that matters as long as we can get back to the iCalendar format as required.
I have yet to see an example of how multivalued values are treated.
Is the XML tag replicated or is the value just put in 'as is'?
Which properties were you thinking of? If there were (say) two descriptions then you would just repeat the tag. I don't think we have come across any iCalendar data with repeated tags yet. RDF has an underlying model of object->property->object, so the syntax would depend on whether the repeated tag translated into an RDF object or property.
Multi valued means two or more values for ONE property, not the same property repeated twice. CATAGORIES for example allows one or more values separated by a comma.
Thanks again for taking a look at what we've been doing - it's very useful to get such detailed feedback from the iCalendar community.
Doug Royer | http://INET-Consulting.com
-------------------------------|-----------------------------
Doug@xxxxxxxxx | Office: (208)520-4044
http://Royer.com/People/Doug | Fax: (866)594-8574
| Cell: (208)520-4044Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature