- From: Garret Wilson <garret@globalmentor.com>
- Date: Tue, 24 Jul 2007 11:51:56 -0700
- To: Semantic Web <semantic-web@w3.org>
I got a chance to sit down and start editing the vCard RDF spec (now that I've found a decent editor that understands this newfangled language called XML...) I've just sent a new version to Harry, which he can transfer and publish whenever he feels appropriate. As we discussed on SWIG IRC, this new version will switch to camelCase and will use The Compromise to specify that v:Name has one v:givenName, one v:familyName, and an rdf:List of v:additionalNames. (Constraints on the number of v:honorificPrefix and v:honorificSuffix will be dropped.) And therein lies the rub that I consistently forget: because additional names will be literals, the rdf:List of v:additionalNames will have to contain bnodes, each with an rdf:value containing the actual additional name. (The same goes for v:extendedAddress.) Damn RDF! When can RDF just go ahead and say that an rdf:List can hold literals? This irritates me to no end. Moving right along... If you read the transcripts from Harry and my SWIG IRC discussion, you'll see that I had doubts about using v:n property with a v:Name class, with my preferring a v:N class. I've caved on this, and here's why: My original argument was that, as we're not creating a new ontology but instead retrofitting an old non-RDF ontology, we should stick with existing vCard identifiers as much as possible. My current characterization is that technically vCard doesn't have a name for the "name" class---it has an N property (which becomes v:n), and has an anonymous class constrained with constraints. In other words, vCard doesn't specify a class for the N (v:n) property, so we have to make one. As Harry pointed out, a v:Name class would be less confusing with a v:n property than would a v:N class. The same goes for v:Address and the like. The arguments are almost 50/50 in my mind, so because Norm already has v:Name I'm leaving it in. Having said that, where do we get the v:Location name? Why isn't it v:Geography? Note also that the source code of the spec brings in the http://www.w3.org/2003/01/geo/wgs84_pos# namespace, but never references it. So what shall we do about v:geo? One person has mentioned that location information is a high priority, so perhaps we could nail this down soon. Garret
Received on Tuesday, 24 July 2007 18:52:05 UTC