Subject: [VCARDDAV] More types for RELATED

From: Cyrus Daboo <[email-masked]>
Date: Thu, 05 Mar 2009 10:18:27 -0500

Hi folks,
The RELATED property currently has the following types defined:

- parent
- child
- sibling
- manager
- assistant
- agent

Apple's Address Book allows users to specify:

- father
- mother
- parent
- brother
- sister
- child
- friend
- spouse
- partner
- assistant
- manager
- other

Given that these are currently in use I would like to see them in the base 
spec rather than have to register them separately. I think they will be of 
general use to other apps too.

-- 
Cyrus Daboo

---

From: Simon Perreault <[email-masked]>
Date: Thu, 05 Mar 2009 13:13:22 -0500

> - mother

"father" and "mother" are special cases of "parent" where the GENDER property of
the referenced vCard is M or F. Therefore I don't think a special type of
RELATED is necessary.

> - sister

"brother" and "sister" are special cases of "sibling" where the GENDER property
of the referenced vCard is M or F. Therefore I don't think a special type of
RELATED is necessary.

> - other

I have no objection to including these 4.

Simon
-- 
STUN/TURN server    --> http://numb.viagenie.ca
Interplanetary news --> http://reeves.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org

---

From: Dan Brickley <[email-masked]>
Date: Thu, 05 Mar 2009 19:24:12 +0100

> of the referenced vCard is M or F. Therefore I don't think a special type of

(nods...)

> I have no objection to including these 4.

Will there be an extensibility mechanism for additional relationships to 
be allowable?

If so, how does does this relate to "other"? Is other just the broadest 
all-inclusive interpersonal relationship type? Are there any pairs of 
people for whom "other" would be an incorrect relationship?

cheers,

Dan

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 05 Mar 2009 11:29:24 -0700

> people for whom "other" would be an incorrect relationship?

XFN also defines:

acquaintance
colleague
co-worker
co-resident
neighbor
muse
crush
date
sweetheart
met (someone you've met in real life)

[supposed to be at http://www.gmpg.org/xfn/1 but that page yields a 404]

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 05 Mar 2009 13:56:43 -0500

Hi Simon,

--On March 5, 2009 1:13:22 PM -0500 Simon Perreault 
<[email-masked]> wrote:

>> - father
>> - mother
>
> "father" and "mother" are special cases of "parent" where the GENDER
> property of the referenced vCard is M or F. Therefore I don't think a
> special type of RELATED is necessary.
>
>> - brother
>> - sister
>
> "brother" and "sister" are special cases of "sibling" where the GENDER
> property of the referenced vCard is M or F. Therefore I don't think a
> special type of RELATED is necessary.

That is reasonable if the value is a reference - URI seems to be the 
default. But it should also be possible to just use text (yes one could use 
a data: URI but that is a little awkward).

Also, I noticed that we no longer have the VCARD value type - i.e. there is 
no way to embed a vcard as a value. Was that a deliberate choice, or a 
side-effect of removing the AGENT property (in favor of RELATED) - AGENT 
was the only one previously allowing vcard embedding I think.

-- 
Cyrus Daboo

---

From: Simon Perreault <[email-masked]>
Date: Thu, 05 Mar 2009 15:00:14 -0500

> met (someone you've met in real life)

Hmrf. I'd like to keep the core to a list of basic, clear, unambiguous, and
uncontroversial items. The "muse", "crush", "date", "sweetheart" don't fit these
criteria. Also, what's the difference between "colleague" and "co-worker"? Some
of them have a vague meaning, e.g. "co-resident" which could be confused with
"neighbor". "partner" could be a euphemism for "spouse" or could describe any
other kind of partner. Finally, what's the difference between "acquaintance" and
"met"?

Unless we can clearly define these terms, we might as well allow any string...

Simon

---

From: Simon Perreault <[email-masked]>
Date: Thu, 05 Mar 2009 15:04:06 -0500

Cyrus Daboo wrote:
> default. But it should also be possible to just use text (yes one could
> use a data: URI but that is a little awkward).

I'm not sure I want to optimize for this use case...

> Also, I noticed that we no longer have the VCARD value type - i.e. there
> is no way to embed a vcard as a value. Was that a deliberate choice, or
> a side-effect of removing the AGENT property (in favor of RELATED) -
> AGENT was the only one previously allowing vcard embedding I think.

Both. Embedding vCards in vCards was ugly and fragile. I (and others if I
remember correctly) was happy to see the construct go away.

Simon

---

From: Dan Brickley <[email-masked]>
Date: Thu, 05 Mar 2009 21:10:51 +0100

> other kind of partner. Finally, what's the difference between "acquaintance" and

I've never been a fan of this particular set of relations (although in 
Web context, rel='me' can be very useful). But having an extension 
mechanism for identifying relationships (by URI) could be useful.

In FOAF we were pretty conservative on this topic and kept only 
foaf:knows in the core, preferring to express friendship, collaboration 
etc indirectly through providing mechanisms for describing associated 
artifacts  (photos, publications etc.). However, co-worker/colleague is 
useful information to have about a contact. As with the family relations 
discussed earlier, many of these relationships can be derrived from 
other information. It isn't clear how much belongs directly in an 
addressbook entry. I see value in some basic family vocab though.

> Unless we can clearly define these terms, we might as well allow any string...

Or any URI?

cheers,

Dan

---

From: Simon Perreault <[email-masked]>
Date: Thu, 05 Mar 2009 15:11:27 -0500

>From the current draft:

      Other types may be registered to IANA as described in
      Section 12.1, and private extensions starting with "X-" may be
      used.

> people for whom "other" would be an incorrect relationship?

Correction on my previous statement: "other" will not be added. Just do not
include the TYPE parameter if the relationship cannot be qualified.

---

From: <[email-masked]>
Date: Fri, 6 Mar 2009 10:54:37 +0100

>- sister

Remember that it's specific to English.
In other languages there are words that also tell you whether he is older or younger than you.
Here's are the examples from Hungarian:
Male:
http://en.wiktionary.org/wiki/b%C3%A1ty
http://en.wiktionary.org/wiki/%C3%B6cs
Female:
http://en.wiktionary.org/wiki/n%C5%91v%C3%A9r
http://en.wiktionary.org/wiki/h%C3%BAg

---

From: "Alexander Mayrhofer" <[email-masked]>
Date: Fri, 6 Mar 2009 10:57:46 +0100

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] 
> [mailto:[email-masked]] Im Auftrag von 
> [email-masked]
> Gesendet: Freitag, 06. März 2009 10:55
> An: [email-masked]; [email-masked]
> Betreff: Re: [VCARDDAV] More types for RELATED
> 
> >- brother
> >- sister
> 

Hmm.. i guess that if we dive into that, we might need to look into genealogy terminology.. i bet there's some standard out there to describe such relations..

Alex

---

From: <[email-masked]>
Date: Fri, 6 Mar 2009 10:58:50 +0100

>met (someone you've met in real life)

Do we really need these? I would rather has a short list with static info.

Also, what happens when I mark someone as "neighbor" and my address changes?
Similarly, what happens to "co-worker" and "colleague" when the workplace changes?

---

From: Dan Brickley <[email-masked]>
Date: Fri, 06 Mar 2009 11:19:02 +0100

> Do we really need these? I would rather has a short list with static info.

Static is a good point. Relations like "parent" don't change (well, I 
remember articles about kids "divorcing" their parents, but generally...).

And once you've "met" someone, you can't un-meet them.

> Similarly, what happens to "co-worker" and "colleague" when the workplace changes?

It's tricky. In FOAF we also have schoolHomepage, defined as a school 
the person attended. This is timeless and static and therefore data that 
doesn't directly go stale (even though School websites move around, the 
intent is clear).

But we also have workplaceHomepage, 
http://xmlns.com/foaf/spec/#term_workplaceHomepage

The current definition is "A workplace homepage of some person; the 
homepage of an organization they work for."

(ie. defined as currently-true that this is their workplace's homepage)

I am inclined to change this to be static, like School homepage. That 
way it can't go stale. And since FOAF is a hypertext / linked data 
system, the intent is that you can then explore the Web from the 
homepage of the workplace (or school) to find more related information.

So in my case,

http://www.w3.org/ as a workplaceHomepage value, could have a hyperlink 
trail leading to http://www.w3.org/People/Alumni where embedded RDFa or 
microformats give my former employers version of the story (eg. that I 
was there 1999-2005). So something like linked-in functionality but 
built over a decentralised hypertext dataset. Obviously not every org is 
going to want to publish this in the clear, but using URIs here is a 
hook for various ways of looking up more timely data at a later date.

My suggestion for what to have in-line within vcards: take only those 
pieces of XFN that never change ("met", "parent", ...more?). Add 
something like a static version of FOAF's workplaceHomepage, which takes 
a URI that could be used for later Web-based discovery.

If this direction is of interest I'll propose an amendment to FOAF such 
that ""A workplace homepage of some person; the homepage of an 
organization they work for."" becomes  ""A workplace homepage of some 
person; the homepage of an organization they work (or worked) for.""

cheers,

Dan

--
http://danbri.org/

---

From: <[email-masked]>
Date: Fri, 6 Mar 2009 12:23:02 +0100

Dan,

>If this direction is of interest I'll propose an amendment to 
>FOAF such that ""A workplace homepage of some person; the 
>homepage of an organization they work for."" becomes  ""A 
>workplace homepage of some person; the homepage of an 
>organization they work (or worked) for.""

This sounds like we encourage a list of current and past workplaces.
Again, if that is the direction of interest, I would recommend an additional clause:
"A workplace homepage of some person; the homepage of an organization they work (or worked) for at the time when the contact information was last updated."

---

From: Dan Brickley <[email-masked]>
Date: Fri, 06 Mar 2009 12:33:18 +0100

> This sounds like we encourage a list of current and past workplaces.

Yes, or at least, allow for this scenario; and encourage use of URI 
identifiers that can be used for cleaner data-joins than plain text.

> "A workplace homepage of some person; the homepage of an organization they work (or worked) for at the time when the contact information was last updated."

I like the intent here, but I think the details don't quite go through.

Assume that today, I'm 99.9% sure you work for Nokia, because I believe 
Nokia only give @nokia.com addresses to current staff. And you've 
replied to a message I wrote this very day. So in my Thunderbird 
addressbook, I might fill out fields indicating this belief. Actually 
I've added you to a group NokiaPeople, since I have a few contacts there 
and I'm interested in Nokia things.

The problem with "at the time when the contact information was last 
updated" is that the record could be updated by me (or by software) in 
many ways and environments in the future, without fact-checking of the 
entire record.

In particular, other unrelated fields, eg. phone number. So I guess we'd 
have to say, "at the time this relationship was originally asserted", 
since changes to eg your phone number are irrelevant to knowing whether 
you still work at Nokia (I'm not likely to fact-check every field 
whenever I change anything). Since every field is (hopefully) believed 
at time of creation and on each update, I'd suggest we can avoid 
including such a truism within the field definitions.

cheers,

Dan

---

From: <[email-masked]>
Date: Fri, 6 Mar 2009 12:57:36 +0100

Hi Dan,

>Assume that today, I'm 99.9% sure you work for Nokia, because 
>I believe Nokia only give @nokia.com addresses to current 
>staff. And you've replied to a message I wrote this very day. 
>So in my Thunderbird addressbook, I might fill out fields 
>indicating this belief. Actually I've added you to a group 
>NokiaPeople, since I have a few contacts there and I'm 
>interested in Nokia things.
>
>The problem with "at the time when the contact information was 
>last updated" is that the record could be updated by me (or by 
>software) in many ways and environments in the future, without 
>fact-checking of the entire record.

Right. In this case, if I left Nokia, you would need to do the update yourself, manually.

>
>In particular, other unrelated fields, eg. phone number. So I 
>guess we'd have to say, "at the time this relationship was 
>originally asserted", since changes to eg your phone number 
>are irrelevant to knowing whether you still work at Nokia (I'm 
>not likely to fact-check every field whenever I change 
>anything). Since every field is (hopefully) believed at time 
>of creation and on each update, I'd suggest we can avoid 

I understand what you are trying to say is that: it depends on how the information is used or updated - and since we can't plan for all possible uses, it's better not say anything at all.
Is this correct?

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 06 Mar 2009 10:33:38 -0500

Hi [email-masked],

--On March 6, 2009 10:58:50 AM +0100 [email-masked] wrote:

> Also, what happens when I mark someone as "neighbor" and my address
> changes? Similarly, what happens to "co-worker" and "colleague" when the
> workplace changes?

Right. I think we need to keep the scope to contact information only (i.e. 
the key relationships needed). For social "networking" relationships a 
pointer to the social network homepage for the user would do fine.

On that front another type just came to mind: TYPE=emergency-contact - the 
person(s) to contact in case of an emergency related to the vcard user. 
That could be a "mix-in" type i.e. typically applied in conjunction with 
TYPE=parent or TYPE=spouse etc. In the real world a lot of "contact" forms 
you have to fill out have a field for "who to contact in case of 
emergency", so I think this is a valid type.

-- 
Cyrus Daboo