On Tue, 04 Jan 2011 11:49:43 -0000, Dave Reynolds
<dave.e.reyno...@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.
