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

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

From: Bruce D'Arcus <bdarcus@gmail.com>
Date: Tue, 1 May 2007 15:49:18 -0400
Message-Id: <623cceff84f57d350e8d1e804e328443@gmail.com>
Cc: Kjetil Kjernsmo <kjetil@kjernsmo.net>, semantic-web@w3.org
To: Garret Wilson <garret@globalmentor.com>


On May 1, 2007, at 3:18 PM, Garret Wilson wrote:

...

>> 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.

But it IS an issue. Why do we bother with breaking apart names like 
this except to be able to know how to order them in a list or table, 
recompose them for different kinds of display, and so forth?

>> 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 mean in the sense there is no such structure in the spec; "bin" is a 
meaningless piece of text.

...

>> 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):

No problem; I was just deferring to how Norm did it.

> 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>

Agreed these are the three options.

>>> 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).

Not really. The logic I use to get to form B is that we in essence 
recognize the major semi-colon delimiter and chop the string up into 
the requisite literal properties. In doing that, order is not 
significant.

If the consensus is that we also ought to chop up those properties 
according to the comma delimiter into lists, then so be it, but I 
thought it might bear some in-depth discussion before going down that 
road. Your note that the approach was "controversial" seemed to 
recognize the same.

>>> 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,

Relational databases also don't support order by default. And I've 
never actually seen a GUI that could handle these cases well (if Osama 
bin Laden filled out a contact record somewhere, I am betting he would 
have a single family name field!), but ...

Bruce
Received on Tuesday, 1 May 2007 19:49:15 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:41:03 UTC