RE: Is vCard range restriction on org:siteAddress necessary?
The only problem I see with the example is that we don't have counties in Scotland, we have districts. In Quebec and Louisiana and other historically catholic places we have parishes. Is Scotland a state in the American sense, not really. You could use things like vc:county and vc:state and just say that the naming is bad, I guess. Geonames tackles this problem in a language-neutral way by having several levels of administrative areas but they also construct a hierarchy which might be a little verbose for this use case. As it's a Friday: six non golden rules of geo: 1. Any attempt to codify a series of geo rules into a formal, one size fits all, taxonomy will fail due to Rule 2. 2. Geo is bizarre, odd, eclectic and utterly human. 3. People will in the main agree with Rule 1 with the exception of the rules governing their own region, area or country, which they will think are perfectly logical. 4. People will, in the main, think that postal, administrative and colloquial hierarchies are one and the same thing and will overlap. 5. Taking Rule 4 into account, they will then attempt to codify a one size fits all geo taxonomy. 6. There is no Rule 6, see Rule 1. Source: http://www.ygeoblog.com/blog/2009/02/23/uk-addressing-the-non-golden-rul es-of-geo-or-help-my-county-doesnt-exist/ John This email is only intended for the person to whom it is addressed and may contain confidential information. If you have received this email in error, please notify the sender and delete this email which must not be copied, distributed or disclosed to any other person. Unless stated otherwise, the contents of this email are personal to the writer and do not represent the official view of Ordnance Survey. Nor can any contract be formed on Ordnance Survey's behalf via email. We reserve the right to monitor emails and attachments without prior notice. Thank you for your cooperation. Ordnance Survey Adanac Drive Southampton SO16 0AS Tel: 08456 050505 http://www.ordnancesurvey.co.uk
Re: Is vCard range restriction on org:siteAddress necessary?
:-) I've just been forcing 5 different location addresses for one company (BAE Systems) into VCard. In the process, I have asserted that both Filton and Samlesbury Aerodrome are street addresses. TGIF. Phil. On 07/01/2011 15:50, John Goodwin wrote: The only problem I see with the example is that we don't have counties in Scotland, we have districts. In Quebec and Louisiana and other historically catholic places we have parishes. Is Scotland a state in the American sense, not really. You could use things like vc:county and vc:state and just say that the naming is bad, I guess. Geonames tackles this problem in a language-neutral way by having several levels of administrative areas but they also construct a hierarchy which might be a little verbose for this use case. As it's a Friday: six non golden rules of geo: 1. Any attempt to codify a series of geo rules into a formal, one size fits all, taxonomy will fail due to Rule 2. 2. Geo is bizarre, odd, eclectic and utterly human. 3. People will in the main agree with Rule 1 with the exception of the rules governing their own region, area or country, which they will think are perfectly logical. 4. People will, in the main, think that postal, administrative and colloquial hierarchies are one and the same thing and will overlap. 5. Taking Rule 4 into account, they will then attempt to codify a one size fits all geo taxonomy. 6. There is no Rule 6, see Rule 1. Source: http://www.ygeoblog.com/blog/2009/02/23/uk-addressing-the-non-golden-rul es-of-geo-or-help-my-county-doesnt-exist/ John This email is only intended for the person to whom it is addressed and may contain confidential information. If you have received this email in error, please notify the sender and delete this email which must not be copied, distributed or disclosed to any other person. Unless stated otherwise, the contents of this email are personal to the writer and do not represent the official view of Ordnance Survey. Nor can any contract be formed on Ordnance Survey's behalf via email. We reserve the right to monitor emails and attachments without prior notice. Thank you for your cooperation. Ordnance Survey Adanac Drive Southampton SO16 0AS Tel: 08456 050505 http://www.ordnancesurvey.co.uk 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
Is vCard range restriction on org:siteAddress necessary?
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). 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 -- 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
Re: Is vCard range restriction on org:siteAddress necessary?
Hi Phil, On Tue, 2011-01-04 at 10:32 +, 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.
Re: Is vCard range restriction on org:siteAddress necessary?
* [2011-01-04 11:49:43 +] Dave Reynolds dave.e.reyno...@gmail.com écrit: ] Is VCard that bad? It fits your example below just fine. The only problem I see with the example is that we don't have counties in Scotland, we have districts. In Quebec and Louisiana and other historically catholic places we have parishes. Is Scotland a state in the American sense, not really. You could use things like vc:county and vc:state and just say that the naming is bad, I guess. Geonames tackles this problem in a language-neutral way by having several levels of administrative areas but they also construct a hierarchy which might be a little verbose for this use case. Cheers, -w -- William Waitesmailto:w...@styx.org http://eris.okfn.org/ww/ sip:w...@styx.org 9C7E F636 52F6 1004 E40A E565 98E3 BBF3 8320 7664
Re: Is vCard range restriction on org:siteAddress necessary?
On Tue, 04 Jan 2011 11:49:43 -, Dave Reynolds dave.e.reyno...@gmail.com wrote: Hi Phil, On Tue, 2011-01-04 at 10:32 +, 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.
Re: Is vCard range restriction on org:siteAddress necessary?
On Tue, 2011-01-04 at 13:28 +0100, William Waites wrote: * [2011-01-04 11:49:43 +] Dave Reynolds dave.e.reyno...@gmail.com écrit: ] Is VCard that bad? It fits your example below just fine. The only problem I see with the example is that we don't have counties in Scotland, we have districts. In Quebec and Louisiana and other historically catholic places we have parishes. Is Scotland a state in the American sense, not really. You could use things like vc:county and vc:state and just say that the naming is bad, I guess. Agreed, that's one reason not to make up another set of address terms such as Phil's ex: examples. The vcard terms (locality, region) strike me as reasonably neutral whereas ex:county is not. Dave
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 +, 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,
Re: Is vCard range restriction on org:siteAddress necessary?
I wish the conflation of a VCard and a SocialEntity whose card it is were either ruled out completely or asserted completely by statements in the ontology. I personally find that the class of business card is one which I do not want to have any data about. (In fact for me it maps best not to a node in the graph but to the RDF document whose contents is the graph. Important for provenance in that respect, but not part of this ontology). My personal take on this in 1990 was the contact: ontology, which had the classes SocialEntity (subclasses: Person, Organization) and Location and properties home, work, vacation link a Person (say) to a Location. Locations Similarly I could imagine properties like site, headquarters, deliveriesPlease, corporateSeat would link an Organization to a Location. (I was extra careful in making street, city, postcode, country properties of the address of a location not of the location itself, allowing a location to have 1 address, or two organizations to have notional locations which were different and had different phone numbers but the same address. I used it for mapping my contact stuff out of Outlook into RDF. I needed assistant as Outlook has Asssitant phone number.) In all this a card has no useful place I can see. Nor is there a 1-1 correspondence between it and anything except for possibly SocialEntity. So I would be in favour of the practice of translating VCards into information about a Social Entity (or an Organization or a Person), and not a card. Tim On 2011-01 -04, at 09:03, Dave Reynolds wrote: On Tue, 2011-01-04 at 13:28 +0100, William Waites wrote: * [2011-01-04 11:49:43 +] Dave Reynolds dave.e.reyno...@gmail.com écrit: ] Is VCard that bad? It fits your example below just fine. The only problem I see with the example is that we don't have counties in Scotland, we have districts. In Quebec and Louisiana and other historically catholic places we have parishes. Is Scotland a state in the American sense, not really. You could use things like vc:county and vc:state and just say that the naming is bad, I guess. Agreed, that's one reason not to make up another set of address terms such as Phil's ex: examples. The vcard terms (locality, region) strike me as reasonably neutral whereas ex:county is not. Yes. In fact, a convention for mapping between them would be useful, even if it is in the comments in the ontology so that if you click though from locality is says such as a city (US) or parish (Scotland). Guidance for ontology users in the ontology file is useful. (Presumably e.g. OSX's Address Book has defined this mapping as they will format all your addresses (whatever country they are in) in your chosen local style of any of many countries.) Tim Address typeClass contact point typeClass comment A place, or mobile situation, with address, phone number, fax, etc. Related to a person by home, office, etc. Note one person's workplace may be another person's home. A person may have more than one home and more than one workplace. (In practice it sometimes maybe useful with restriucted datasets to assume that this is not the case, when extracting data from other ontologies with no concept of ContactLocation). Strongly related to a person: in some ways a role that a person can be in. label contact point fax label fax subClassOf phone Female typeClass Language Code typeClass Male typeClass mobile label mobile subClassOf phone Pager subClassOf phone Person comment A person in the normal sense of the word. subClassOf Social Entity phone typeClass comment An end-point in the public swiitched telephone system. Anything identified by a URI with tel: scheme is in this class. label phone tel. Social Entity typeClass comment The sort of thing which can have a phone number. Typically a person or an incorporated company, or unincorporated group. subject to change label subject to change address Property typeProperty address typeProperty domain contact point label address range Address assistant typeProperty comment A person (or other agent) who is an assistant to the subject. domain http://xmlns.com/foaf/0.1/Agent label assistant ramge http://xmlns.com/foaf/0.1/Agent birthday typeProperty domain Social Entity range Date child typeProperty city domain Address country domain Address department Name domain Person description typeProperty email typeInverseFunctionalProperty comment emailAddress is a string. Use of this is discouraged. Use :mailbox instead domain Social Entity label email rangeEmail Address example emergency only typeProperty domain Person label emergency only range contact point family Name domain Person fax typeProperty domain contact point
Re: Is vCard range restriction on org:siteAddress necessary?
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 +, 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 +, 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
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:siteAddressblah/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 +, 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:siteAddressblah/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 +, 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
Re: Is vCard range restriction on org:siteAddress necessary?
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. 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. 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 appreciate that claiming that org:siteAddress is unnecessary is somewhat orthogonal to the original question! Are there any cases where it might be needed? Kind regards, Alex (Disclaimer: We take this conflated-vCard approach -- http://oxpoints.oucs.ox.ac.uk/id/)
Re: Is vCard range restriction on org:siteAddress necessary?
On Tue, 2011-01-04 at 11:02 -0500, Tim Berners-Lee wrote: I wish the conflation of a VCard and a SocialEntity whose card it is were either ruled out completely or asserted completely by statements in the ontology. +1 I personally find that the class of business card is one which I do not want to have any data about. (In fact for me it maps best not to a node in the graph but to the RDF document whose contents is the graph. Important for provenance in that respect, but not part of this ontology). The use case that I've come across has been bundling sets of contact mechanisms together. For example, in local government there can be a main contact point for a Council (with email, phone, mail address, web form) and then contact points for out of hours use or for specific services (each potentially with multiple contact mechanisms). This grouping-for-a-purpose is different from grouping by organization or grouping by site (e.g. the council main offices may have both a normal and an out-of-hours set of contact details). Dave My personal take on this in 1990 was the contact: ontology, which had the classes SocialEntity (subclasses: Person, Organization) and Location and properties home, work, vacation link a Person (say) to a Location. Locations Similarly I could imagine properties like site, headquarters, deliveriesPlease, corporateSeat would link an Organization to a Location. (I was extra careful in making street, city, postcode, country properties of the address of a location not of the location itself, allowing a location to have 1 address, or two organizations to have notional locations which were different and had different phone numbers but the same address. I used it for mapping my contact stuff out of Outlook into RDF. I needed assistant as Outlook has Asssitant phone number.) In all this a card has no useful place I can see. Nor is there a 1-1 correspondence between it and anything except for possibly SocialEntity. So I would be in favour of the practice of translating VCards into information about a Social Entity (or an Organization or a Person), and not a card. Tim On 2011-01 -04, at 09:03, Dave Reynolds wrote: On Tue, 2011-01-04 at 13:28 +0100, William Waites wrote: * [2011-01-04 11:49:43 +] Dave Reynolds dave.e.reyno...@gmail.com écrit: ] Is VCard that bad? It fits your example below just fine. The only problem I see with the example is that we don't have counties in Scotland, we have districts. In Quebec and Louisiana and other historically catholic places we have parishes. Is Scotland a state in the American sense, not really. You could use things like vc:county and vc:state and just say that the naming is bad, I guess. Agreed, that's one reason not to make up another set of address terms such as Phil's ex: examples. The vcard terms (locality, region) strike me as reasonably neutral whereas ex:county is not. Yes. In fact, a convention for mapping between them would be useful, even if it is in the comments in the ontology so that if you click though from locality is says such as a city (US) or parish (Scotland). Guidance for ontology users in the ontology file is useful. (Presumably e.g. OSX's Address Book has defined this mapping as they will format all your addresses (whatever country they are in) in your chosen local style of any of many countries.) Tim Address type Class contact point type Class comment A place, or mobile situation, with address, phone number, fax, etc. Related to a person by home, office, etc. Note one person's workplace may be another person's home. A person may have more than one home and more than one workplace. (In practice it sometimes maybe useful with restriucted datasets to assume that this is not the case, when extracting data from other ontologies with no concept of ContactLocation). Strongly related to a person: in some ways a role that a person can be in. label contact point fax label fax subClassOf phone Female type Class Language Code type Class Male type Class mobile label mobile subClassOf phone Pager subClassOf phone Person comment A person in the normal sense of the word. subClassOf Social Entity phone type Class comment An end-point in the public swiitched telephone system. Anything identified by a URI with tel: scheme is in this class. label phone tel. Social Entity type Class comment The sort of thing which can have a phone number. Typically a person or an incorporated company, or unincorporated group. subject to change label subject to change address Property type Property address type Property domain contact point label address range Address assistant type Property comment A person (or other agent) who is
Re: Is vCard range restriction on org:siteAddress necessary?
Hi, Am 04.01.2011 13:38, schrieb Alexander Dutton: 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.) This is also a long term FOAF issue (see [1]) with the proposal to connect FOAF and vCard object using a property term businessCard (see [2]). Since the Organization Ontology is also based on the FOAF Vocabulary this might be an option. Cheers, Bob [1] http://wiki.foaf-project.org/w/FOAF_and_vCard [2] http://wiki.foaf-project.org/w/term_businessCard
