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

Bruce,

Bruce D'Arcus wrote:
>
>> 1. Do you believe that multiple honorific suffixes should be placed 
>> into one literal value, such as 
>> <vcard:honorificSuffix>BS,JD,MBA,JR"</vcard:honorificSuffix>?
>
> I guess no.
>
> I'm not sure I'd call the first three proper honorific suffixes (more 
> like "holds degree"). I'd say if someone really insisted on calling 
> them that, it wouldn't hurt to have them as separate properties.

...and here my point doesn't get very far, because the order of 
honorific suffixes usually is not significant. In RDF we can have 
multiple vcard:honorificSuffix properties. So let's move on to 
vcard:familyName, for which order is important.

>
>> 2. Which of the following representations do you prefer: 
>> <vcard:familyName>bin Muhammad bin 'Awad bin Laden</vcard:familyName> 
>> or <vcard:familyName>bin Muhammad,bin 'Awad,bin 
>> Laden</vcard:familyName> (i.e. the family name components separated 
>> by some delimiter)?
>
> I'm fairly ignorant of Arabic, but would tend to say the first.

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.


> I'd defer for sorting logic to the sort string property.

Sorting is not my worry here---it's in losing semantics that were 
present in the original vCard.

>
>> 3. Do you believe that vcard:adr should also have a maximum 
>> cardinality of 1, considering the need to support multiple addresses 
>> with a "preferred address" designation?
>
> No.
>
> I'd say if there's a need to denote a preferred address, perhaps there 
> ought to be a preferredAdr property? It is a relation, after all.

It *is* a relation, but it's not a specialization of the vcard:adr 
relation, I've decided. It's actually a separate relation that has as 
its object the reification of an existing vcard:adr relation, i.e. the 
triple [VCard, vcard:preferred, (VCard, vcard:adr, theaddress)]. But we 
don't want to go there! :) (RDF's support of statements about statements 
is horrible.)

It seems simpler to me to simply allow a list of addresses, with the 
first address being the preferred one. (I'm still perplexed as to why is 
it so hard to allow the object of vcard:adr to be vcard:Adr or a 
rdf:List of vcard:Adr.)

> In fact, what address I prefer you use is all about context anyway (if 
> we're doing business, use my business address, and if personal, send 
> to my home).

Sure, but you've merely moved the question to another level. (Sort of 
like, "That things exist imply that something created them", which 
implies, "That a Creator exists implies that something created the 
Creator.") How do I indicate my preferred home address (surely many 
people will have multiple home addresses)?

>
> Mind you, I'm not dismissing the real world difficulties here. I want 
> to use this stuff for bibliographic data for citation purposes, where 
> display and sorting is very important. But I'd much prefer a simpler 
> approach if at all possible.

No arguments there. In fact, I'd like to use a simple framework, if at 
all possible---and RDF is not a simple framework. (It's arguably 
horribly convoluted.) But my creating my own semantic framework won't 
help interoperability. My feeling is that a single-cardinality-or-list 
is the simplest we can get *and* work with real-world data using the 
semantic framework we've been thrown.

>
>> 4. Do you believe that vcard:tel should also have a maximum 
>> cardinality of 1, considering the need to support multiple telephone 
>> numbers with a "preferred telephone number" designation?
>
> As above.

To me it seems *more* complicated to have vcard:preferredTel, 
vcard:homeTel, vcard:preferredHomeTel, and 
vcard:secondPreferredHomeTelIfFirstPreferredHomeTelIsn'tWorkingToBeCalledBeforeThirdPreference 
than it is to simply have a list of telephone numbers. But I don't want 
to force *everything* to have a list if it isn't warranted, so I want to 
still allow single cardinality.


>> 6. Would you support abandoning the class vcard:N in favor of simply 
>> using the property vcard:n in the form 
>> <vcard:n>Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P.</vcard:n>? If 
>> no, then why not? (i.e. I'm curious to know whether your answers to 
>> #1 and #6 are different, as the questions are very similar.)
>
> Let me step back a bit:
>
> In the vCard spec, what do the commas and semi-colons mean?

The semicolons separate what's called a "structured text value" in to 
its separate "components", some components of which can have multiple 
values. Specifically, "The structured type value corresponds, in 
sequence, to the Family Name, Given Name, Additional Names, Honorific 
Prefixes, and Honorific Suffixes. The text components are separated by 
the SEMI-COLON character (ASCII decimal 59). Individual text components 
can include multiple text values (e.g., multiple Additional Names) 
separated by the COMMA character (ASCII decimal 44)." RFC 2426 Section 
3.1.2.


> For example, how is the fragment "Philip,Paul" understood?

...as "multiple text values" of an "individual text component".


> Does the spec say this is a comma-delimited list of given (or 
> "other"?) names? 

See the specification text above.


> Is a notion of ordered list included in the spec?
>

The specification doesn't *say* that the order of the subcomponents are 
important, but surely it is self-evident that "bin Muhammad bin 'Awad 
bin Laden" should be distinguished from "bin 'Awad bin Laden bin 
Muhammad" as far as family names go.

So... what is your answer to question #6? ;)

Garret

P.S. The whole problem here is that we are using RDF to model real-world 
data. :)

Received on Tuesday, 1 May 2007 18:08:54 UTC