Re: [vcard] multiple names, multiple address lines

Hi Garret,

> David Powell wrote:
>> Is there any reason why we can't just space separate multi-valued N
>> components like this:
>>
>> []    rdf:type ex:N ;
>>       ex:familyName "Geldof" ;
>>       ex:givenName "Peaches Honeyblossom Michelle Charlotte Angel Vanessa" .
>>   

> As I mentioned before, one certainly *can* do that, but if we do, what's
> the point of RDF? Why don't we just stick everything in a single ex:N 
> literal value? In fact, why don't we just use normal vCard format---why
> RDF? Note the problem: RDF can handle distinct properties just fine, but
> has real problems with optionally plural values. That scares me 
> somewhat, as the use case here is neither complicated nor uncommon.

I don't like values flipping from using a list syntax to a single value
syntax depending on how many items there are.  I guess that this
leaves something like:

    <v:N>
      <v:givenName rdf:parseType="Seq">
        <rdf:li>Peaches</rdf:li>
        <rdf:li>Honeyblossom</rdf:li>
        ...
      </v:givenName>
      <v:familyName rdf:parseType="Seq">
        <rdf:li>Geldof</rdf:li>
      </v:familyName>
    </v:N>

Always using a list structure for these values. A bit verbose, bit
that's not such a huge problem is it?

> I think the issue comes up more in family names than in given names. I
> would think that we would want to distinguish that "van Buren bin Laden"
> is actually two family names, "van Buren" and "bin Laden".

OK, so space-separation of name items won't work.

>> I guess that additionalNames doesn't necessarily have a correct
>> position in the formatted name and is just a catch-all for
>> everything else.

> I would think that this is for what Americans call "middle names".

OK, I was a bit unsure about whether additionalNames meant middle
names from reading the RFC.  I guess that it probably does, although
it isn't stated explicitly.

>> For addresses the intent is clearly for multiple items in each
>> sub-component to represent multiple lines in the address, so why not
>> just represent them as a line-feed separated value?

> It is certainly possible to do that. But again, is RDF so impoverished
> that we have to define a sub-syntax? "This field uses spaces to separate
> values. This other field uses LF to separate values. But remember to 
> collapse CRLF into a single LF, and consider a single CR to be 
> syntactically incorrect. Oh, and don't forget a / to indicate a 
> continuation of a next line, unless of course we encode the / 
> somehow..." Didn't we move beyond all that once we got into the RDF data
> model? Are we going to define entire new grammars just to get stuff out
> of Directory vCard into RDF? That's the problem I have with this sort of
> thing, although it is certainly possible.

vCard addresses aren't ideal, and are a bit US-centric.  If you
wanted to search for people on a given street, then you are already
going to have to hunt around in streetAddress to guess where the
house number or name ends, and the street starts (or vice-versa in
Europe) - and whether house names are on a separate line or not.

Is it any harder to find people from a certain village if they are
represented as:

      <v:streetAddress>1 High Street,
Village</v:streetAddress>

than:

      <v:streetAddress rdf:parseType="Seq">
        <rdf:li>1 High Street</rdf:li>
        <rdf:li>Village</rdf:li>
      </v:streetAddress>

...?
      
What about if the streetAddress consisted of 3 components, perhaps the
name of a block of flats on a street. There isn't a single place to
look for the value as it is, so maintaining the separation in the RDF
isn't that important. If you were using a richer address vocabulary,
like this one: <http://rdfweb.org/topic/AddressVocab>, then searching
would work better, but vCard isn't rich enough to avoid heuristics and
guesswork.

[It would be nice if you could enrich vCard/RDF addresses with an
S42-3 level of information, but it looks like that would be difficult.]


I was thinking that as vCard addresses aren't at all semantically
tidy, then there is little that you can do with multi-item components
other than concatenate them with newlines for display. I suppose this
isn't entirely true with something like HTML, where having separate
items makes it marginally easier to create multiple <div> tags or
whatever for display - but that seems like a fairly minor advantage.

-- 
Dave

Received on Monday, 2 April 2007 14:59:38 UTC