A GeoLocation can be where the author is when creating an entry or a location that the entry is related to. A different attribute would be used to distinguish the two.

Does GeoLocation describe the author's current location or the "setting" of the content? Either probably. Do these uses need to be distinguished?

Yes, the two need to be distinguished, so that you can have both in a single posting.

With respect to the GeoLocation the entry is related to, it would be useful to have an indication of extent, in miles or kilometers. This way, without defining a precise area, you can discuss an area.

[WWW]ChrisHollander so, to summarize:

Incredibly interesting. pretty simple from an infoset standpoint, and very powerful from an aggregation/query/analysis standpoint. Could really take off as devices become more location aware.

See also Categorization, using DublinCore's 'subject' definition to identify the location that is the subject of the entry (not the creator's location).

[Moof, RefactorOk] I don't think Zipcodes are necessarily a good idea. Mostly due to the complexities of dealing with every country's postal code standard, and the differences in accuracy. A full postcode in britian, for example, will locate you to within less than 20 houses (eg. BN20 7XL is the postcode of a school, and the school building is the only correct addresee for that postcode - the computer bulding over the road has a separate one), and people may not want to give that sort of information out. In the British system it's easy to make it less specific, but it still limits you to a reasonably small number of houses. BN20 is an area a few miles wide, but WC1 is smaller than a square kilometer.

As someone who's been looking for this kind of data, I'm aware of the differing scales of what is needed. I used to regularly post from "Home, Canterbury, UK" and "Computing Lab, University of Kent at Canterbury, UK". The former could be anywhere within the 20 square miles that is Canterbury, the latter is a specific building within a well-known and identifiable campus.

With either of these, I could give Longitude and Latitude to differing scales, assuming I could find the information out without needing to buy a GPS. However, the thing becomes a little less easy when it's a travel blog, as mine did for a while. I posted form various places including "Hervey Bay, Queensland, Australia", "Orlando, Florida, USA", "Paihia, North Island, New Zealand" and so on. Orlando is a fairly big city. Hervey bay is town sized, maybe a mile or two wide. Paihia is about five streets and a seafront. In all these cases it isn't important where exactly I am, just that I was in that location as defined by me. I certainly couldn't tell you GPS co-ordinates for any of these places, and i doubt I could find them out without buying a GPS, something that may be difficult if not impossible for someone to buy in certain countries.

Another major issue that comes with it is language. I currently live in Palma de Mallorca, Espaņa. Well, that's what the locals call it. In English, the official spelling is Palma, Majorca, Spain. And remember that some countries may have more than one official language. Mallorca is one of what is known in English as the Balearic Islands, in Castillian Spanish (what you learn in school as Spanish) as las Islas Baleares, and in the local languages (each island has a different dialect of Catalan) as las Illes Balears. Similarly, Paihia is in the North Island of New Zealand, which is known in Maori (one of the local languages) as Te Ika a Maui, Aotearoa. In the case of Paihia, I don't even know what province it's in. I may be blogging from there in spanish, in which case I'd like to be able to say "Paihia, Isla del Norte, Nueva Zelanda"

Given the complexity of the issue, and the fact that GPS data is not always available, I suspect a free text string be permissible instead of, or in addition to, GPS data.

Related links:

[AdamRice] Moof makes many meritorious comments. My interest is whether a location is presented in a readily machine-readable form or not. ICBM addresses seem the most machine readable. Somewhat less so might be "USA: Texas: Austin: Hyde Park" (though that brief example illustrates the problems with abbreviations). Worst-case would be something like "just down the road from the big green house, on Red Arrow Hiway running south from S. Haven, MI".

I'd also like to suggest that "ChronoLocations" would be just as useful for indicating the time frame under discussion in the entry--not the time of the entry's publication/revision/whatever, but for use in schedules (post-dating) or referring to long-past events where back-dating your entry would be a bad idea.

[NigelWetters] Most Internet geolocation based on IP address is performed by querying the Regional Internet Registries' WHOIS databases. Commercial and free products exist, which usually provide a local fast copy of the location information from WHOIS, along with various APIs for its use. All rely on the assumption that Internet users live close to their ISPs. If you define close as in the same country, this assumption might be true for most users. However, if you define close as in the same city, the assumption breaks down (apart from in the major cities of the USA, where there is a thriving ISP business). It is extremely difficult (possibly impossble) to measure accuracy of Internet geolocation at any granularity, but many of the commercial vendors are happy to say that their products have 99% accuracy to country level and 80% accuracy to city level. Treat such claims with a dose of salt.

[MovGP0] Look at [WWW]W3C's Geo Scheme. If there would be more than one implementation for Geolocation-RDF, a program has to support all of them. Therefore the Version for Atom need to implemented as an (maybe same titeled) Alias - but in no case as a brand new element. Also the Geolocation-Element need to be optional, because not every blogger will get out the right location. It shold be also possible to apply different (part of) posts to different locations. Therefore I think that Atoms-Geolocation should be just a explicit recommendation to use the W3C-Version, rather than included directly into the ATOM-RDF-scheme.

CategoryModel, CategoryExtension