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? 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.
