Re: Is vCard range restriction on org:siteAddress necessary?

On Tue, 2011-01-04 at 12:38 +0000, Alexander Dutton wrote: 
> On 04/01/11 11:49, Dave Reynolds wrote:
> > The separation between the Site and the address isn't necessary in
> > general, but it is necessary in order to reuse vcard. An org:Site isn't
> > a vcard:Address [*] hence the need for the indirection.
> 
> I think there's some confusion between the vCard and the address. 

You are right, my response wasn't clear - my head is not properly
rebooted after the holidays :)

At one point we had considered having org:siteAddress point directly to
a vcard:Address, hence my confusing response.  However, in the end we
wanted to allow all the vcard properties (not just addresses) without
conflating a site with its vcard.

> I 
> would have said that:
> 
> [] a org:Site, v:VCard ;
>     v:adr [
>       ex:addressLine1 "Unit 5" ;
>       # or (if you prefer)
>       a v:Address ;
>       v:street-address "Unit 5" ;
>       …
>     ]
> 
> I agree that addresses are not the same as sites, but I'm not sure that 
> there's any need to use the org:siteAddress property to distinguish a 
> site from its v:VCard. Using v:adr with an org:Site maintains that 
> separation without needing the intermediate resource.

It's arguable either way.

The semantics of what it means to be a vcard:VCard aren't that precise
but I've tended to regard is as a representation of a glorified business
card (i.e. a description of an information record, a "directory" entry
to use the IETF terminology) rather than a representation of a physical
or virtual location. 

I can't see a clear cut practical problem with the conflation but prefer
the conservative approach of keeping them separate. That makes it easy
to extend org:Site without worrying if that fits with the dual
interpretation as a VCard. For example, an extension which talked about
the physical size and population of an org:Site would be natural but I'm
not sure they would make sense as attributes of a vcard.

In principle, a Site could also have multiple vcards for different uses
(e.g. a Goods-in back entrance with its own street address, map and
phone number separate from the main reception but part of the same
physical site).
> The vCard ontology doesn't give a general property for linking a thing 
> to its v:VCard, which suggests to me that the only way to discover 
> addresses in the general case is when properties in the vCard namespace 
> are applied directly to people, places, etc. (In other words the v:VCard 
> class simply means "a thing to which addresses, phone numbers, etc are 
> attached".)

I think it reflects more the nature of the vcard IETF spec (i.e. a
specification of a content type for directory information) separate from
the RDF usage of associating a directory entry with some entity.

Cheers,
Dave

Received on Tuesday, 4 January 2011 13:40:57 UTC