Subject: [VCARDDAV] New property: Subject differentiator (Issue 162)

From: Andy Mabbett <[email-masked]>
Date: Mon, 14 Jul 2008 23:12:09 +0100

Issue 162, "New property: Subject differentiator" says:

        [In microformats] The use of [classes] "fn" and "fn org"
        differentiate between hCards for people and for other entities,
        but we perhaps need some further differentiator, between, say,
        organisations and venues (including buildings, governmental
        divisions, waypoints, etc.) at a level of granularity to be
        determined.

        <http://www.vcarddav.org/issues.xhtml#162>

The response is:

        Well, LABEL is to ADR what FN is to N. So just put whatever
        human-readable text that doesn't fit the ADR structure in LABEL.
        Or did I miss something?

I fear that the latter is the case ;-)

The issue speaks to that fact that some vCards (and, in microformats,
hCards) are not for individual people, but for groups, companies or
venues, with no person as a named contact.

At the least three types are, I suggest, needed:

        person
        organisation
        venue

though additional granularity could be catered for (or free text could
be accepted, though I think this would greatly reduce usefulness).

-- 
Andy Mabbett
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 14 Jul 2008 21:07:08 -0400

Hi Andy,

> be accepted, though I think this would greatly reduce usefulness).

There is a new KIND property defined in the draft that has values 
"individual", "group" and "org". "venue" would be another interesting 
option but I think that should be an extension because there are likely 
venue-specific semantics that need to be encoded as possibly new properties 
along with that. Take a look at 
<http://tools.ietf.org/html/draft-norris-ical-venue-00> to see the thinking 
of the calendar folks on this, but note that is not being pursued anymore - 
instead they (we) are looking towards the new VCARD to fill this role.

-- 
Cyrus Daboo

---

From: Andy Mabbett <[email-masked]>
Date: Tue, 15 Jul 2008 22:48:44 +0100

In message <[email-masked]>, Cyrus Daboo 
<[email-masked]> writes

>Hi Andy,

Hello again!

>--On July 14, 2008 11:12:09 PM +0100 Andy Mabbett <andy at
>pigsonthewing.org.uk> wrote:
>

>option but I think that should be an extension because there are
>likely venue-specific semantics that need to be encoded as possibly
>new properties along with that.

Again, I must confess my ignorance - what do you mean, in this context, 
by an "extension"? As opposed to what?

I have several entries for venues in my address book, and see many, many 
more posted online as hCards (like "Symphony Hall", "Shea Stadium", 
"Green Street Post Office", "Paddington Station"). I don't have, or see, 
any special semantics outside those already catered for in vCard/ hCard.

They are certainly not individuals or groups, and "organisation" is a 
poor fit, because they are usually run by organisations, which have 
separate identities (and which may run many venues).

Perhaps the label "venue" is not helpful, and an alternative name (say, 
"structure", "point", "place", "location" or suchlike) would help?

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 15 Jul 2008 22:15:01 -0400

Hi Andy,

> "structure", "point", "place", "location" or suchlike) would help?

Just calling something a "venue" is fine. But there is a lot more 
potentially useful information about that venue that would be good to have 
in there too. Think in terms of calendaring and scheduling of rooms. You 
want to find a room with a minimum capacity, a projector and a 
teleconference system. Being able to encode those additional attributes as 
part of the room's vCard "schema" would make that much more useful.

Having said that, I think it would reasonable to include "location" as a 
KIND value in the base spec. The additional attributes for types of 
location can be done later.

-- 
Cyrus Daboo

---

From: "Javier Godoy" <[email-masked]>
Date: Thu, 17 Jul 2008 02:43:32 -0300

Cyrus Daboo wrote: 

> KIND value in the base spec. 

+1

>The additional attributes for types of  location can be done later.

+1 (I think it is out of scope for the core spec.)

Javier

---

From: Simon Perreault <[email-masked]>
Date: Sat, 26 Jul 2008 14:27:43 -0700

> location can be done later.

I've added to the effect that "location" stands for "a named 
geographical place". Comments?
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Andy Mabbett <[email-masked]>
Date: Sat, 26 Jul 2008 16:26:20 +0100

In message <[email-masked]>, Simon Perreault 
<[email-masked]> writes

>Cyrus Daboo wrote:
>> Having said that, I think it would reasonable to include "location" 
>>as a  KIND value in the base spec. The additional attributes for types 
>>of  location can be done later.
>

Thank you; that seems good to me,.

"+1"

---

From: Andy Mabbett <[email-masked]>
Date: Sun, 27 Jul 2008 16:45:26 +0100

>geographical place". Comments?

On giving this further thought, I wonder if some sort of "object"
identifier would also be useful, as a catch-all for things which are not
people, organisations or locations?

Consider vCards for:

        Stonehenge
        The Cutty Sark
        Brooklyn Bridge
        some roadworks
        Street-lamp number 43
        The telephone box whose number is +44 121 555 5555
        The Trevi Fountain
        Nelson's Column
        a tree

all of which might have a street address, coordinates, URI, etc. which
need to be transferred from one application to another; and which might
be the "location" of an iCalendar event (such as a being a meeting
place, or the subject of a piece of maintenance work).

Or does "location" cover these?