Re: [vcard] multiple names, multiple address lines

Sandro and David,

Sandro Hawke wrote:
> It sounds like your issue with rdf:Collection/rdf:List is based on an
> intuition about it having "all those triples".  But those are only there
> in the model...

But that's exactly where I don't want them! I can control the UI, but 
we're trying to find an elegant, semantically significant storage 
mechanism, here---and have it come out better than the current vCard syntax.

> So, my advise is to use lists and let the implementations catch up.

So yesterday I sat and visited a hypothetical world in which I accepted 
David and Sandro's proposal to simply use an rdf:List (and only an 
rdf:List) in every case in which multiple values could be accepted. I 
suddenly realized that this issue is not isolated to vcard:N subproperties.

Take a simple telephone number (David already discussed this somewhat). 
We want to have several of them, and mark one as "preferred". Do we 
require vcard:tel also to accept a list and only a list? We basically 
have the following options:

   1. <vcard:tel rdf:resource="tel:+15551212"/> This is the obvious way,
      and this is the sort of thing that was used to sell us RDF---the
      self-evident simplicity and consistency, resulting in a nice,
      pretty graph. We can even have more than one of these. But as
      David pointed out, if we mark one of these as "preferred", it gets
      marked as "preferred" everywhere in the graph, even if someone
      else uses that telephone number.
   2. <vcard:tel><rdf:Description rdf:value="+15551212"/></vcard:tel> So
      that solves the "global preference" problem, and we can have
      several of them, but what does the graph mean? If we go off the
      official definition of rdf:value, it doesn't mean much absent our
      vCard spec of what rdf:value means in this case. Things are
      starting to get ugly in the resulting graph, too.
   3. <vcard:tel rdf:parseType="Collection"><rdf:Description
      rdf:value="+15551212"/></vcard:tel> Now we even have more triples,
      but we have a benefit that we don't need to mark one of them as
      "preferred" because we can say that the first one is preferred.
      But since we have to stick the plain literal in a wrapper bnode
      anyway, we haven't really gained anything---we might as well add a
      "preferred" property to the bnode. We do have the benefit that all
      the values can be grouped together in a single list, but where did
      the simplicity of option #1 go? We were sold RDF with tidy
      examples like option #1, but are we finding out that in real life
      we must use an rdf:List of bnodes for everything? We might as well
      change the RDF specification to say, "An RDF statement consists of
      a resource subject, a resource predicate, and a list object!"

Then we run into the same problem with vcard:email---I want to have 
multiple emails for a contact, yet have one be marked as "preferred." 
Must <vcard:email rdf:resource=""/> be abandoned 
for the same reasons, and I must stick that email into a list?


Received on Tuesday, 3 April 2007 14:45:42 UTC