- From: Paul Buhler <pbuhler@cs.cofc.edu>
- Date: Wed, 11 Sep 2002 12:34:59 -0400
- To: www-rdf-calendar@w3.org, "'Jose M Vidal'" <vidal@sc.edu>
Hello to all. I am doing research in the domain of semantic web services. My initial project targets the use of FIPA compliant calendaring agents that use RDF as a content language for message exchange. In doing this work, I have come to appreciate the value of the hybrid.rdf document; however, it appears that no work has been done on it in a little over a year. After reading Libby's update from May 21, 2002 it appears that complete iCalendar may be overkill for the types of tools and ideas that are being experimented with. Obviously the hybrid.rdf is useful in its current form; however, I believe it may be worth putting some more effort into. I have generated the following to start a discussion. Suggested recommendations and improvements to the iCalendar hybrid.rdf document. 1. Structure the document using the ordering found in sections 2.7 - 2.9 of the iCalendar DTD Document (xCal) found at http://www.ietf.org/internet-drafts/draft-ietf-calsch-many-xcal-02.txt 2. As indicated in Libby's post, RFC2445 is long and unwieldy. I suggest that for each element defined in the iCalendar namespace, a comment containing the url to the appropriate sections in the RFC be made. As in the following example: <!-- BINARY http://xml.resource.org/public/rfc/html/rfc2445.html#anchor48 --> <rdfs:Class rdf:about="&iCalendar;BINARY" rdfs:label="binary" rdfs:comment="Used to identify properties that contain a character encoding of inline binary data."> <rdfs:subClassOf rdf:resource="&xmlsdt;base64binary" /> </rdfs:Class> 3. Generate a consolidated list of open-issues with the schema. Ideally placed as a comment at the beginning of the document. 4. Institute some form of configuration management for the document. If it is decided that changes and improvements should be made; they should be tracked. 5. Rename the document to be more descriptive, like ical.rdf. A stub referencing the new document can be left at the old URL. I can perform numbers 1 and 2 in preparation for an initial check-in to a configuration management system. After an initial revision exists, I would like to correct several issues to bring the schema into closer conformance with RFC2445. Perhaps discussions can be had regarding some of the issues regarding date formats, et.al. Regards, Paul Buhler College of Charleston Charleston, SC USA
Received on Wednesday, 11 September 2002 12:41:23 UTC