W3C home > Mailing lists > Public > semantic-web@w3.org > July 2007

update on vCard edits and The Compromise

From: Garret Wilson <garret@globalmentor.com>
Date: Tue, 24 Jul 2007 11:51:56 -0700
Message-ID: <46A64A4C.1020206@globalmentor.com>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 07:41:58 UTC