more musings on RDF vCard and iCalendar

Harry and others,

I've put together a document, attached, which sets forward principles 
and processes to be used in creating one or more RDF ontologies for 
directory/vCard/iCalendar. My point here is, rather than trying to start 
with an RDF ontology and try to make it fit vCard data, I've instead 
looked at the representation needs of directory/vCard/iCalendar to see 
where it leads us regarding an RDF ontology. This is a work in progress, 
and I'll be updating it in the coming days.

I believe I've covered most of the components of 
directory/vCard/iCalendar, and it's leading me to some interesting 
conclusions:

1. I'm now even more convinced that it would be inappropriate to address 
vCard separate from other Directory types such as iCalendar. Certain 
properties (e.g. GEO, UID, PRODID) are identical across specifications. 
It would be a shame to have distinct and perhaps even incompatible 
properties RDF vCard and RDF iCalendar, when they derive from the 
essentially the same source.

2. The issue regarding components (such as with the vCard N property) is 
very important yet luckily rare. There are only four so-called 
structured values across all three specifications (and GEO is not even 
really a problem), so we can safely create somewhat specialized 
solutions for these classes.

3. I'm starting to become uncomfortable with the idea of having 
specialized properties for different vCard TYPEs, such as vcard:homeTel, 
for several reasons. First, and not insignificantly, is the extent to 
which this will make translating from Directory vCard to RDF vCard more 
convoluted---a simple vcard:telType would be simpler to understand, and 
would allow for future processors to automatically work with new types. 
Secondly, the idea of "type" in vCard is semantically weak; currently 
TYPE for TEL means everything from location ("home", "work"), technology 
used ("msg", "video"), to whether the telephone number is the preferred 
one ("pref"). As there are few cases in all three RFCs that actually use 
such a "type", I think it better just to create a straightforward 
vcard:telType property and leave in the legacy values for now---perhaps 
a more comprehensive solution can be added later, rather than rigging a 
complicated scheme now over what was inelegant to begin with.

4. Lastly, I've looked around and it seems that most other ontologies 
are using CamelCase rather than hyphen-separated names; I recommend we 
do the same.

Note that some Directory properties in this document are duplicated out 
of consistency, and will be collapsed when they are converted to RDF 
ontologies. Likewise, if some properties are unnecessary (syntax 
properties, for example) or redundant (a language property, for 
example), they will be removed at a later stage.

Again, this document is not yet an ontology specification in 
itself---rather, I hope that everyone will think it logical and, after 
some discussion, agree to incorporate some or all of its conclusions 
into the actual specification. I welcome your thoughts.

Best,

Garret