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.
-
[AdamRice] Somewhat simpler would be to allow one feed-level location (the author's main location) and one entry-level location per entry. I suppose we could conjure up situations where Joe Blogger resides in City 1, is visiting City 2, and wants to blog about something going on in City 3 (while indicating "written from City 2", but not changing his home location). This seems awfully finicky to me. Which is not to say that it won't happen. Just representing what's going on would be a syntactic challenge.
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.
ChrisHollander so, to summarize:
-
something along the lines of ContentOriginLocation could be used to designate a specific location at which a entry is authored. what would the format of this attribute be? seperate lat/lon attributes on Loc.Origin element? what about less exact measures, like zipcode (and international equivelants)?
-
a different element, i.e., Loc.Subject, could be used to indicated that a given entry is actually "about" a specific location. The same questions about the granularity of the location information apply here.
-
The concept of introducing a vector (direction, distance) or a a minimum, a range (distance) from a well known location could be used to define these locations; i.e., "5 miles from the empire state building", "10k from the space needle". [AdamRice] This is certainly a humane way of dealing with geolocations, but unfortunately, would be all-but impossible for a machine to do anything with. And I think the point of having an explicit geotag is specifically to facilitate interesting automated results--for the benefit of our human readers, we might as well put "10 miles from the space needle" in the main content.
-
I might also be interested in seeing a location tag to describe an entire EntryChannel... as in, yes, this particular EchoEntry was written on "this" spot and talks about "that" spot, but the "home" of the entire site is "there".
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:
-
ESW GeoInfo page -- lots of links
-
Natural Area Encoding System -- a location coding that uses between two and ten alphanumeric characters to pinpoint areas of differing size.
-
GeoURL ICBM Address Server -- Websites can be located by putting certain metadata (coordinates) into the HTML code.
-
GeoSketch -- MT plugin for mapping
-
GeoInfo notes in W3C SemWeb wiki -- ongoing RDF work
-
Blogmapper -- Mechanism in use.
-
TGN -- Getty Thesaurus of Geographic Names
-
ICBM RSS Module -- one way to geolocate using RSS
-
Java InetAddress Locator -- GPL'd code for finding country from IP address (java)
-
IP::Country -- GPL'd code for finding country from IP address (perl)
-
IP2Location -- Commercial geolocation technology
[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 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.