Re: vCard/iCalendar RDF process document 2007-04-06

Bruce D'Arcus wrote:
>> If your choice is the former, don't you find it unsettling that "van 
>> Buren" is ambiguous as to whether there is one family name of "van 
>> Buren" or two family names of "van" and "Buren"? The situation is 
>> Arabic is analogous.
>
> But this is a really slippery slope, isn't it?

To where? What's at the bottom of the hill?

>
> Consider that both "van" and "bin" are not in fact either family or 
> given names, but rather articulars, often not included in sorting.

Again, sorting is not my issue here.

>
> Yet vCard has no support for articular names. So isn't the question in 
> this case which representation is more wrong, rather than which is right?

vCard supports articular names just fine:

N:bin Muhammad,bin 'Awad,bin Laden;Osama;;;

I would propose that this be modeled exactly as it would be in vCard, 
with multiple values for family name and a single value for the given name:

<vcard:n>
  <vcard:N>
    <vcard:givenName>Osama</vcard:givenName>
    <vcard:familyName rdf:parseType="Collection">
      <rdf:Resource rdf:value="bin Muhammad"/>
      <rdf:Resource rdf:value="bin 'Awad"/>
      <rdf:Resource rdf:value="bin Laden"/>
    </vcard:familyName>
  <vcard:N>
</vcard:n>

>
>
> And if we assume order in a list denotes preference,

I don't want to assume that, because in the context of family names it 
would be an incorrect assumption most of the time. (In the above 
example, "bin" literally indicates family lineage, which isn't 
surprising as this is the "family name" property.)


> what does that do for this example ("Osama bin Muhammad bin 'Awad bin 
> Laden"), where the last family name would be the preferred?

I was talking about preference in the context of telephone numbers and 
email addresses. The idea of "preference" for family names isn't present 
in the vCard spec, and I don't see a need to add it here. (I realize 
that the vCard name representation is probably not the best 
representation that there is---I  just don't want to create one that is 
worse.)


>
> Would be interesting to pull out of those tricky real world examples 
> and see how they look in the different approaches.

OK, here we go (if you'll excuse my camelCase, which is a separate 
discussion altogether that can safely be deferred):

My preferred approach (A):

<vcard:n>
  <vcard:N>
    <vcard:givenName>Osama</vcard:givenName>
    <vcard:familyName rdf:parseType="Collection">
      <rdf:Resource rdf:value="bin Muhammad"/>
      <rdf:Resource rdf:value="bin 'Awad"/>
      <rdf:Resource rdf:value="bin Laden"/>
    </vcard:familyName>
  <vcard:N>
</vcard:n>

Your and Norm's preferred approach (B):

<vcard:n>
  <vcard:N>
    <vcard:givenName>Osama</vcard:givenName>
    <vcard:familyName>bin Muhammad bin 'Awad bin Laden</vcard:familyName>
  <vcard:N>
</vcard:n>

My devil's advocate approach (C):

<vcard:n>bin Muhammad,bin 'Awad,bin Laden;Osama;;;</vcard:n>


>
>> So... what is your answer to question #6? ;)
>
> You want to know what I would do with:
>
> <vcard:n>Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P.</vcard:n>
>

I didn't ask, "What would you do with this?" I asked, "Is this an 
approach that you would advocate, and if no, why not?" My point here is 
that, if you advocate form (B) above, why don't you go all the way and 
advocate the devil's advocate approach (C)? That's simpler, and it seems 
to follow the logic you used to get to form (B).


>>
>> P.S. The whole problem here is that we are using RDF to model 
>> real-world data. :)
>
> Actually, the problem isn't really RDF. The same problems attend to 
> form GUIs, relational databases, etc. The problem is trying to 
> represent real world data in all its culturally-specific variabiliity 
> in ways that machines don't butcher :-)

...compounded by the fact that we're using a modeling framework that 1 ) 
creates an artificial distinction, with restrictions, between string 
literal resources and non-string-literal resources, 2 ) does not 
inherently support order of properties, 3) creates semantic indirection 
for referring to property values with plural cardinality, and 4 ) 
provides no formal semantics for structured values. (See 
http://www.w3.org/TR/rdf-schema/#ch_value , for example; paraphrased: 
"rdf:value is meaningless, but cool to use!")

Received on Tuesday, 1 May 2007 19:19:19 UTC