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

On Tue, 04 Jan 2011 11:49:43 -0000, Dave Reynolds  
<dave.e.reynolds@gmail.com> wrote:

> Hi Phil,
>
> On Tue, 2011-01-04 at 10:32 +0000, Phil Archer wrote:
>> I'm doing a bit of grunt work on some data about companies and want to
>> remodel relevant sections using the org vocabulary [1]. But... I'd
>> rather not be forced to use vCard for the address info (because UK
>> addresses don't fit the vCard model particularly well. You can make them
>> fit, but it's a metric peg in an imperial-sized hole).
>
> Is VCard that bad? It fits your example below just fine.
>
> Part of the design goals were to reuse existing vocabularies where
> possible. Since VCard is pretty widely used for contact details it
> seemed like the obvious choice and preferable to getting bogged down in
> defining another addressing vocabulary without a strong reason.
>
>> Further, does address info need to be in a separate class from the site
>> info? In other words, what's the argument for /not/ doing:
>>
>> [] a org:Site ;	
>>    ex:addressLine1 "Unit 5" ;
>>    ex:addressLine2 "Exemplary Industrial Estate" ;
>>    ex:town "Anytown" ;
>>    ex:county "Anycounty" ;
>>    ex:country "United Kingdom" ;
>>    os:postcode <...postcodeunit/EX11EX> ;	
>>    geo:lat "51.2569489" ;
>>    geo:long "-2.2007225" .
>>
>>
>> [1] http://www.epimorphics.com/public/vocabulary/org.html
>
> 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'm not sure it would make sense to drop the range restriction on
> org:siteAddress, given that it is there specifically to support the
> vcard style.
>
> So are there alternative addressing vocabs we should be supporting
> instead of, or as well as, vcard?
>
> Or is there a flaw in vcard sufficient to justifying creating an org
> extension to use for addressing instead of vcard?
>

I personally find these things tricky about vCard:

1. It often separates things into related nodes where it would seem more  
natural just to have them all as literal properties of the same node (as  
above, with addresses).
2. It's not clear how vcard objects (v:Address, v:VCard , v:Tel) relate to  
"real world" things like people, companies, etc.

If I remember right, the answer given before (I think on this list, by  
Harry Halpin) is to live with the inference that  you are both a  
foaf:Person and a v:VCard, as it is fairly harmless.
You could  do the same with org:Site and v:Address - why not?

http://ogp.me/ns#[1] defines properties that you can attach directly to  
your resource, but I'd hesitate to use it because the namespace URI  
doesn't dereference, and because I am wary of using a vocabulary with a  
lifespan bound so tightly to the protocol/application that consumes it.

I think the vCard RDF ontology authors did a fine job, but I suspect that  
vCard may not have been the best starting point for an RDF addresses  
vocabulary, because it is based on a format used by particular  
applications, not around describing things in the real world and how they  
relate. With RDF, we (mostly) want to describe the real world.


yours

Keith Alexander


[1]  
http://schemacache.test.talis.com/Schema/?uri=http%3A%2F%2Fogp.me%2Fns%23


> Cheers,
> Dave
>
> [*] I think of it as a vcard:Address representing an address label, a
> structured version of the vcard:Label formatted label, rather than a
> geographic entity. For example, in vcard the geo coordinates are
> associated with the VCard not the Address.
>

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