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

    It seems from my perspective that we have two distinct use-cases, as
mentioned by Bruce: "RDF vCard Core, which is the hCard subset, and RDF
vCard Full", mapping to:

1) Mapping hCard/Simple VCard use-cases. This is what Norm does.
2) Mapping full VCard with round-tripping. i.e. Garrett Also, to express
preferred names, multiple phone numbers of different types, etc., this
requires much more extensive use of class names and various

The distinction seems to be:

1) Properties with a range of only literal values for vcard attributes.
2) Properties with a range of (multiple) resources distinguished by
their use of classes.

These aren't mutually exclusive. While I haven't sat down and hammered
it out, one could just remove the range constraints for the vCard RDF
Schema so one could use the same ontology to do both, as Garett
mentioned.  But it makes processing a bit more tricky. And a third
option would be to:

3) Attempt not to use classes and subclasses, but instead use
sub-properties, and so one I think gets the best of both 1) and 2).

I've e-mailed Richard Ishida asking for some internationalization
use-cases for VCard, hopefully he responds and these can be our
"test-cases" for the spec. I'd like for everyone interested to try to
model these test-cases, and then from there it should probably be
obvious which of the paths is the right one to take.

I'm pro-keeping it all in one namespace.

However, I am also pro-keeping the spec for VCard separate from
iCal/RDFCalendar. Garrett - I suggest you e-mail your Directory
suggestion to the RDFCalendar task force [1]. It seems sort of inactive,
so I think your suggestion would possibly boot-things back into gear.

As for a #swig discussion, I'm out of town (as is almost all W3C Staff
such as Dan Connolly and others who I know are interested in this for
WWW2007 next week, so I suggest 1:00 PM EST (which should map decently
well to people in Europe) in #swig for a meeting.

[1]http://www.w3.org/2002/12/cal/


Bruce D'Arcus wrote:
>
> Good questions Garret :-)
>
> I'll answer where I can ...
>
> On May 1, 2007, at 12:59 PM, Garret Wilson wrote:
>
>>> ought to be literal properties restricted to a maximum cardinality
>>> of 1.
>>
>> To understand the implications of your and Norm's position, let me
>> ask a few followup questions:
>>
>> 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.
>
>> 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. I'd
> defer for sorting logic to the sort string property.
>
>> 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. 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).
>
> I think personal name parts are somewhat unique, because they have
> (often simply assumed) expectations about using them for sorting and
> display. It's this significance of order that is such a pain in general.
>
> 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.
>
>> 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.
>
>> 5. Do you believe that vcard:email should also have a maximum
>> cardinality of 1, considering the need to support multiple email
>> addresses with a "preferred email address" designation?
>
> As above.
>
>> 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? For
> example, how is the fragment "Philip,Paul" understood? Does the spec
> say this is a comma-delimited list of given (or "other"?) names? Is a
> notion of ordered list included in the spec?
>
> Bruce
>
>


-- 
		-harry

Harry Halpin,  University of Edinburgh 
http://www.ibiblio.org/hhalpin 6B522426

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