- From: Martin Hepp <martin.hepp@ebusiness-unibw.org>
- Date: Thu, 18 Jul 2013 14:07:15 +0200
- To: Cosmin Paun <cpaun88@gmail.com>
- Cc: Dan Brickley <danbri@danbri.org>, "public-vocabs@w3.org Org" <public-vocabs@w3.org>
Hi Cosmin, thanks - Wayback machine confirms what you say: http://web.archive.org/web/20130101105606/http://schema.org/PostalAddress ;-) The reason why I assume that was that the validator did not complain yesterday since it did not properly recognize the type of the item and tolerated the additional property for an untyped entity. But the second part of my post still remains open: A (slightly different) geo property for PostalAddress may be useful so that site-owners can help a search engine with the translation of an address to a point or polygon. A pragmatic choice would be to add geo to the properties for PostalAddress like property range description geo GeoCoordinates or GeoShape The geo coordinates of the place or PostalAddress. and take into account the fact that it has a slightly different meaning than when attached to another type. Alternatively, one could add a new property "geocoding" which links from a PostalAddress to its preferred translation into a geo-position. Martin On Jul 18, 2013, at 1:18 PM, Cosmin Paun wrote: > Dear Martin, > > As much as I know, geo property has never been a property of > http://schema.org/PostalAddress. It is true, location property from > http://schema.org/Organization expect a > http://schema.org/PostalAddress or a http://schema.org/Place (with a > geo property). > > Regards, > > Cosmin > > On Thu, Jul 18, 2013 at 11:48 AM, Martin Hepp > <martin.hepp@ebusiness-unibw.org> wrote: >> Dear Dan, >> all: >> >> If I am not mentally retarded, I am pretty sure that until yesterday, the geo property could also have been attached to a http://schema.org/PostalAddress. >> >> Now it seems to be gone and the Google Structured Data Testing tool starts complaining that geo was not defined for PostalAddress in schema.org. It is still available for http://schema.org/Place and its subtypes, as expected. >> >> Is that correct? I think that from a conceptual modeling perspective, both is arguably correct. Attaching the geo-position to a place and to an address means using the same property with two slightly different meaning: >> >> - geo attached to a place means the place can be found at that position >> - geo attached to an address means the address approximately translates to the geo-position. >> >> So it is "ontologically" cleaner as it is now. From a search engine perspective, however, you may want to allow people to support the translation from addresses to geo-positions or to provide precise geo-position if the address encompasses a bigger polygon. >> >> Martin >> >> >> >> -------------------------------------------------------- >> martin hepp >> e-business & web science research group >> universitaet der bundeswehr muenchen >> >> e-mail: hepp@ebusiness-unibw.org >> phone: +49-(0)89-6004-4217 >> fax: +49-(0)89-6004-4620 >> www: http://www.unibw.de/ebusiness/ (group) >> http://www.heppnetz.de/ (personal) >> skype: mfhepp >> twitter: mfhepp >> >> Check out GoodRelations for E-Commerce on the Web of Linked Data! >> ================================================================= >> * Project Main Page: http://purl.org/goodrelations/ >> >> >> >> > -------------------------------------------------------- martin hepp e-business & web science research group universitaet der bundeswehr muenchen e-mail: hepp@ebusiness-unibw.org phone: +49-(0)89-6004-4217 fax: +49-(0)89-6004-4620 www: http://www.unibw.de/ebusiness/ (group) http://www.heppnetz.de/ (personal) skype: mfhepp twitter: mfhepp Check out GoodRelations for E-Commerce on the Web of Linked Data! ================================================================= * Project Main Page: http://purl.org/goodrelations/
Received on Thursday, 18 July 2013 12:07:42 UTC