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

Thanks Dave,

I'll use this, although, as you say, it's because of the re-use issue. 
VCard seems to have many of the problems that TimBL points to. And it 
does seem that encoding names and addresses in RDF is a recurring 
problem that has yet to be solved to everyone's satisfaction. Ah well... 
I'll have fun writing the script to do the conversion tomorrow ;-)

Phil.

On 04/01/2011 16:21, Dave Reynolds wrote:
> Hi Phil,
>
> My inclination is to simply use VCard as is (including the
> sub-resources) rather than try to short cut by collapsing the VCard and
> Address. So I'd tend to write your example as:
>
> <blah>  a org:Site;
>     org:siteAddress<blah/vcard>  .
>
> <blah/vcard>  a v:VCard ;
>     v:fn "Blah Ltd (Headquarters)";
>
>     geo:lat "51.2569489" ;
>     geo:long "-2.2007225" ;
>
>     v:geo [
>         v:latitude  "51.2569489" ;
>         v:longitude "-2.2007225" ;
>     ];
>
>     v:adr [
>         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>  ;
>
>         v:label
>           """Unit 5,
> Example Industrial Estate,
> Westbury,
> Wiltshire,
> EX1 1EX,
> United Kingdom"""
>     ];
>     .
>
>> Is this kind of modelling useful, over and above including address
>> info directly as properties of the site?
>
> The advantages are:
>
> o easy to consume by people who already know about (and have code for
> handling) vcard - no need to cater for some new one-off address
> vocabulary
>
> o an org:Site could have multiple address vcards (an outlier
> requirement, to be fair)
>
> Disadvantages:
>
> o slightly more complex to query (extra levels of indirection) and
> easier to work with if you have CBD support
>
>
> For me there was no other good option. Reuse trumps convenience. If I
> had included address properties in Org I'm sure I would have had a lot
> of "don't reinvent wheels, just use Vcard" comments :)
>
> Dave
>
> On Tue, 2011-01-04 at 15:30 +0000, Phil Archer wrote:
>> 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 16:44:20 UTC