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

Thanks everyone for the replies. OK, I'm going to try and use vCard like 
it says!

Dave R - thanks for the example of one location having 2 addresses. I 
thought that such a thing might be possible but couldn't think of an 
example. I was thinking about shared office space but that didn't lead 
to separate address labels for a single site within an org chart.

Keith - yes, the RDF encoding of vCard is very good... at encoding vCard.

Here's a repeat of my (very close to real world, Dave C) example:

<blah> a org:Site ;
   ex:addressLine1 "Unit 5" ;
   ex:addressLine2 "Example Industrial Estate" ;
   ex:town "Westbury" ;
   ex:county "Wiltshire" ;
   ex:country "United Kingdom" ;
   os:postcode <.../postcodeunit/EX11EX> ;
   geo:lat "51.2569489" ;
   geo:long "-2.2007225" .

If my understanding of vCard is correct then what follows is a valid 
conversion (I don't claim that this is the only valid interpretation):

<blah> a org:Site;
   org:siteAddress <blah/vcard> .

<blah/vcard> a v:Address ;
   v:extended-address "Unit 5" ;
   v:street-address "Example Industrial Estate" ;
   v:locality "Westbury" ;
   v:region "Wiltshire" ;
   v:postal-code "EX1 1EX"
   v:country-name "United Kingdom" ;
   os:postcode <.../postcodeunit/EX11EX> ;
   geo:lat "51.2569489" ;
   v:latitude  "51.2569489" ;
   v:longitude "-2.2007225" ;
   geo:long "-2.2007225" ;
   v:label
     """Unit 5,
     Example Industrial Estate,
     Westbury,
     Wiltshire,
     EX1 1EX,
     United Kingdom""" .

(btw I've gone back to the RFC for vCard [1] to find out that the order 
of elements for an address is:

post office box;
extended address;
street address;
locality (e.g., city);
region (e.g., state or province);
postal code;
country name.)

I've used the top level class of 'Address' since it doesn't feel right 
to call this a work address. Is it OK to go straight from an org:site to 
v:Address without going through v:VCard first?

Dave suggested using Label, which seems sensible, but that gets 
confusing, I think anyway, when considering the label property, the 
value for which is a pre-formatted string that can be printed and stuck 
on an envelope (the triple quotes come courtesy of the Turtle spec at [2]).

I've included the OS postcode data (which is one of the drivers for this 
work in the first place) as well as the geo Lat/long.

I guess the underlying question here is: is this what you have in mind, 
Dave? Is this kind of modelling useful, over and above including address 
info directly as properties of the site?

Phil.

[1] http://www.ietf.org/rfc/rfc2426.txt
[2] http://www.w3.org/TeamSubmission/turtle/#longString

On 04/01/2011 13:39, Dave Reynolds wrote:
> 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
>
>
> Please consider the environment before printing this email.
>
> Find out more about Talis at http://www.talis.com/
> shared innovation™
>
> Any views or personal opinions expressed within this email may not be those of Talis Information Ltd or its employees. The content of this email message and any files that may be attached are confidential, and for the usage of the intended recipient only. If you are not the intended recipient, then please return this message to the sender and delete it. Any use of this e-mail by an unauthorised recipient is prohibited.
>
> Talis Information Ltd is a member of the Talis Group of companies and is registered in England No 3638278 with its registered office at Knights Court, Solihull Parkway, Birmingham Business Park, B37 7YB.
>
> Talis North America is Talis Inc., 11400 Branch Ct., Fredericksburg, VA 22408, United States of America.
>

-- 


Phil Archer
Talis Systems Ltd
Web: http://www.talis.com
Tel: +44 1473 434770
Twitter: philarcher1
LinkedIn: http://uk.linkedin.com/in/philarcher
Personal: http://philarcher.org

Received on Tuesday, 4 January 2011 15:32:03 UTC