[OSGeo-Discuss] Summary: Representing Places With Intelligent URLs

2010-10-06 Thread Landon Blake
Thanks for all of the responses.

After some careful consideration of the responses I received I realize
the challenges of trying to get real world features into the type of
hierarchy I derive.

I'm going to check out the system Geonames is using with RDFa. I think I
might be able to use their technique for uniquely identifying places.

Thank you again for your help.

Landon
Office Phone Number: (209) 946-0268
Cell Phone Number: (209) 992-0658
 
 
-Original Message-
From: discuss-boun...@lists.osgeo.org
[mailto:discuss-boun...@lists.osgeo.org] On Behalf Of Allan Doyle
Sent: Wednesday, October 06, 2010 7:40 AM
To: OSGeo Discussions
Subject: Re: [OSGeo-Discuss] RE: Representing Places With Intelligent
URLs


On Oct 5, 2010, at 9:58 PM, Bob Basques wrote:

  All,
 
 I'm a long time address database creation/maintenance/re-creation
fiend myself.
 
 I've also been working with the USNG (MGRS) gridding system the last
few years, and need to at least suggest the idea of 
 using a Gridding system to locate things.  This idea is not nbew, but
USNG usage has gained quite a bit of ground the 
 last couple of years across all level of government, with a large
emphasis placed on using it for disaster response.
 
 Tying a placeName to a grid location that can describe things down to
the centimeter if needed and still stay unique as 
 a location is a very good thing.

Don't be too sure at the centimeter level.

The average rate of motion across the San Andreas Fault Zone during the
past 3 million years is 56 mm/yr (2 in/yr).  --
http://earthquake.usgs.gov/learn/facts.php

I like Chris Schmidt's quote: The world is fuzzier than you realize.

Allan


 
 bobb
 
 
 
 On 10/5/2010 8:52 PM, Landon Blake wrote:
 The geonames ontology looks like it might work for me. I'll read it
over tomorrow.
 
 Thanks for the suggestion.
 
 Landon
 
 Sent from my iPhone
 
 On Oct 5, 2010, at 5:45 PM, Ian Turtonijtur...@gmail.com  wrote:
 
 On Tue, Oct 5, 2010 at 8:39 PM, Christopher Schmidt
 crschm...@crschmidt.net  wrote:
 On Tue, Oct 05, 2010 at 05:18:47PM -0700, Paul Ramsey wrote:
 All attempts to construct simple ontologies end up reinventing
RDF . ?
 That was actually my first thought when I saw this: Hey look,
 someone else reinventing RDFa! :)
 
 Seriously, I say this with a bit of knowledge; I mean, after all,
 I sort of work on making places searchable on maps. For a company
 with a pretty big set of data about the hierarchy of the world.
 It's a lot fuzzier than you think :)
 
 Also, Landon, I do highly recommend looking into RDF --
specifically,
 RDFa -- because I think it's heading in a very similar direction to
 what you're describing, without the need for some
all-world-hierarchy
 to tie it to, which might actually help you get a bit further.
 
 You might want to look at http://www.geonames.org/ontology/ which
RDFs
 the GeoNames database.
 
 Ian
 -- 
 Ian Turton
 ___
 Discuss mailing list
 Discuss@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/discuss
 
 Warning:
 Information provided via electronic media is not guaranteed against
defects including translation and transmission errors. If the reader is
not the intended recipient, you are hereby notified that any
dissemination, distribution or copying of this communication is strictly
prohibited. If you have received this information in error, please
notify the sender immediately.
 ___
 Discuss mailing list
 Discuss@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/discuss
 
 
 
 ___
 Discuss mailing list
 Discuss@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/discuss

-- 
Allan Doyle
Director of Technology
MIT Museum | http://web.mit.edu/museum | +1.617.452.2111



___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss


Warning:
Information provided via electronic media is not guaranteed against defects 
including translation and transmission errors. If the reader is not the 
intended recipient, you are hereby notified that any dissemination, 
distribution or copying of this communication is strictly prohibited. If you 
have received this information in error, please notify the sender immediately.
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss


Re: [OSGeo-Discuss] RE: Representing Places With Intelligent URLs

2010-10-06 Thread Bob Basques
Allen, 

You need the Centimeter stuff to realize that something moved over the two 
years.  Besides, that just ends up being a re-projection in the end anyway. 

  :c) 

bobb 



 Allan Doyle afdo...@mit.edu wrote:


On Oct 5, 2010, at 9:58 PM, Bob Basques wrote:

  All,

 I'm a long time address database creation/maintenance/re-creation fiend 
 myself.

 I've also been working with the USNG (MGRS) gridding system the last few 
 years, and need to at least suggest the idea of
 using a Gridding system to locate things.  This idea is not nbew, but USNG 
 usage has gained quite a bit of ground the
 last couple of years across all level of government, with a large emphasis 
 placed on using it for disaster response.

 Tying a placeName to a grid location that can describe things down to the 
 centimeter if needed and still stay unique as
 a location is a very good thing.

Don't be too sure at the centimeter level.

The average rate of motion across the San Andreas Fault Zone during the past 3 
million years is 56 mm/yr (2 in/yr).  -- 
http://earthquake.usgs.gov/learn/facts.php

I like Chris Schmidt's quote: The world is fuzzier than you realize.

Allan



 bobb



 On 10/5/2010 8:52 PM, Landon Blake wrote:
 The geonames ontology looks like it might work for me. I'll read it over 
 tomorrow.

 Thanks for the suggestion.

 Landon

 Sent from my iPhone

 On Oct 5, 2010, at 5:45 PM, Ian Turtonijtur...@gmail.com  wrote:

 On Tue, Oct 5, 2010 at 8:39 PM, Christopher Schmidt
 crschm...@crschmidt.net  wrote:
 On Tue, Oct 05, 2010 at 05:18:47PM -0700, Paul Ramsey wrote:
 All attempts to construct simple ontologies end up reinventing RDF . ?
 That was actually my first thought when I saw this: Hey look,
 someone else reinventing RDFa! :)

 Seriously, I say this with a bit of knowledge; I mean, after all,
 I sort of work on making places searchable on maps. For a company
 with a pretty big set of data about the hierarchy of the world.
 It's a lot fuzzier than you think :)

 Also, Landon, I do highly recommend looking into RDF -- specifically,
 RDFa -- because I think it's heading in a very similar direction to
 what you're describing, without the need for some all-world-hierarchy
 to tie it to, which might actually help you get a bit further.

 You might want to look at http://www.geonames.org/ontology/ which RDFs
 the GeoNames database.

 Ian
 --
 Ian Turton
 ___
 Discuss mailing list
 Discuss@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/discuss

 Warning:
 Information provided via electronic media is not guaranteed against defects 
 including translation and transmission errors. If the reader is not the 
 intended recipient, you are hereby notified that any dissemination, 
 distribution or copying of this communication is strictly prohibited. If you 
 have received this information in error, please notify the sender 
 immediately.
 ___
 Discuss mailing list
 Discuss@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/discuss



 ___
 Discuss mailing list
 Discuss@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/discuss

--
Allan Doyle
Director of Technology
MIT Museum | http://web.mit.edu/museum | +1.617.452.2111



___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss


[OSGeo-Discuss] RE: Representing Places With Intelligent URLs

2010-10-06 Thread Geoff Hay
Hi
The knowledge you are trying to encode should be represented as associations 
between individuals (this place contains that place etc) and concepts (city, 
park, post office delivery area, etc) (as in OWL) rather than a URI scheme (see 
Geonames).  The basic idea is to represent places in a way that allows 
inference (make implicit knowledge explicit) i.e. logical consequence 
e.g. 
Explicit: a country only has only one capital city
Explicit: NZ is a country 
Explicit: Wellington is the capital of NZ
Explicit: 'Te Upoko o te Ika a Maui'  is the capital of NZ
Implicit: Wellington and 'Te Upoko o te Ika a Maui' are the same place 

- you cant do this nicely with a URL scheme but an OWL reasoner can make such 
conclusions - yehar Semantic Web.  Actualy there is really no problem with your 
URI scheme otherwise. It looks exactly like what you would expect for REST Web 
Services URLs - as long as you don't expect your URLs to be the ultimate and 
final identifiers - that would break both of the two main assumptions behind 
the semantic web and its underlying formal logics.

regards
Geoff

From: discuss-boun...@lists.osgeo.org [discuss-boun...@lists.osgeo.org] On 
Behalf Of Landon Blake [lbl...@ksninc.com]
Sent: Wednesday, 6 October 2010 12:45 p.m.
To: OSGeo Discussions
Subject: [OSGeo-Discuss] Representing Places With Intelligent URLs

A talk at the recent Location Business Summit and some reading I've done
about the semantic web and microformats lately got me to thinking about
a standard way to represent places, place names, place data on the web.
(I must admit I'm a desktop software guy, not a web programmer.)

I thought it would be awesome if there was a way to create a unique URL
for places that was somewhat intelligent to humans. If this URL could
point to a folder on a server with some basic information about a place,
that would be even better.

So I took a stab at creating this type of URL for my city, the City of
Stockton. Here it is:

http://www.standardwebmarkup.org/standard_places/north_america/united_st
ates_of_america/california/san_joaquin_county/city_of_stockton/

You can see the URL follows a logical hierarchy, and it would be easy to
determine what the URL for the City of Sacramento, San Joaquin County,
or Victory Park in the City of Stockton would be. Obviously the
continent/country/state/county/city/location URL pattern would have to
change for other parts of the world.

I put a very simple HTML file with data about the City of Stockton here:

http://www.standardwebmarkup.org/standard_places/north_america/united_st
ates_of_america/california/san_joaquin_county/city_of_stockton/info.html

The current info.html file is just a skeleton. It's more of a place
holder right now than anything else.

My thought was to also put a WKT file (place.wkt) representing the
location of the place and a simple text file (data.txt) with facts about
the place at this same URL:

http://www.standardwebmarkup.org/standard_places/north_america/united_st
ates_of_america/california/san_joaquin_county/city_of_stockton/

Now, if someone wanted to write content about the City of Stockton, they
could simply do something like this:

a
href=http://www.standardwebmarkup.org/standard_places/north_america/uni
ted_states_of_america/california/san_joaquin_county/city_of_stockton/S
tockton/a

If everyone that was putting web content about Stockton online did the
same thing, search engine and other tools would be able to link data
from this web content to a single location.

This becomes even more powerful if we come up with some rules for the
content of the info.html file, place.wkt file, and the data text file.
Here are some examples:

(1) Specify that the place.wkt file have both a point and a polygon WKT
representation, or a linestring representation, of the place when
appropriate.

(2) Specify that the info.html file use a list with alternate place
names. This list would be identified with an html class value of
alternate_place_names.

(3) Specify that the data.txt file contain a relationships section that
can contain an optional relationship in the form of: City is the County
Seat of County. (Stockton is the County Seat of San Joaquin County.)

(4) Standardize the way common place facts are stored in the data.txt
file. Population and area are examples.

I realize there are some problems with this overall scheme. How do you
store a city that straddles a state boundary, for example? Or what if
you want to have a URL for the location of the Pacific Garbage Patch?

However, I think we could use this system to uniquely identify and
describe a lot of places in the world. We could then work on how to
handle the edge cases.

Is anyone else interested in ironing out the kinks for a system like
this? Is there already a system like this in place? (If so, I have just
revealed my great ignorance to everyone on this mailing list.)

I'm interested in setting something up that could be maintained 

RE: [OSGeo-Discuss] RE: Representing Places With Intelligent URLs

2010-10-06 Thread Geoff Hay
Hi
Yes it's a blatent simplification, although... semantics...  
Interesting the association between truth and space, and then there's time 
regards
Geoff


From: discuss-boun...@lists.osgeo.org [discuss-boun...@lists.osgeo.org] On 
Behalf Of P Kishor [punk.k...@gmail.com]
Sent: Thursday, 7 October 2010 10:14 a.m.
To: OSGeo Discussions
Subject: Re: [OSGeo-Discuss] RE: Representing Places With Intelligent URLs

On Wed, Oct 6, 2010 at 3:45 PM, Geoff Hay geoffrey@otago.ac.nz wrote:
 Hi
 The knowledge you are trying to encode should be represented as associations 
 between individuals (this place contains that place etc) and concepts (city, 
 park, post office delivery area, etc) (as in OWL) rather than a URI scheme 
 (see Geonames).  The basic idea is to represent places in a way that allows 
 inference (make implicit knowledge explicit) i.e. logical consequence
 e.g.
 Explicit: a country only has only one capital city

I am assuming the above is just for illustration, because we have

http://en.wikipedia.org/wiki/List_of_countries_with_multiple_capitals

To make matters worse, we also have

http://en.wikipedia.org/wiki/List_of_countries_spanning_more_than_one_continent

and

http://en.wikipedia.org/wiki/List_of_metropolitan_areas_that_overlap_multiple_countries

and probably more.


 Explicit: NZ is a country
 Explicit: Wellington is the capital of NZ
 Explicit: 'Te Upoko o te Ika a Maui'  is the capital of NZ
 Implicit: Wellington and 'Te Upoko o te Ika a Maui' are the same place

 - you cant do this nicely with a URL scheme but an OWL reasoner can make such 
 conclusions - yehar Semantic Web.  Actualy there is really no problem with 
 your URI scheme otherwise. It looks exactly like what you would expect for 
 REST Web Services URLs - as long as you don't expect your URLs to be the 
 ultimate and final identifiers - that would break both of the two main 
 assumptions behind the semantic web and its underlying formal logics.

 regards
 Geoff
 
 From: discuss-boun...@lists.osgeo.org [discuss-boun...@lists.osgeo.org] On 
 Behalf Of Landon Blake [lbl...@ksninc.com]
 Sent: Wednesday, 6 October 2010 12:45 p.m.
 To: OSGeo Discussions
 Subject: [OSGeo-Discuss] Representing Places With Intelligent URLs

 A talk at the recent Location Business Summit and some reading I've done
 about the semantic web and microformats lately got me to thinking about
 a standard way to represent places, place names, place data on the web.
 (I must admit I'm a desktop software guy, not a web programmer.)

 I thought it would be awesome if there was a way to create a unique URL
 for places that was somewhat intelligent to humans. If this URL could
 point to a folder on a server with some basic information about a place,
 that would be even better.

 So I took a stab at creating this type of URL for my city, the City of
 Stockton. Here it is:

 http://www.standardwebmarkup.org/standard_places/north_america/united_st
 ates_of_america/california/san_joaquin_county/city_of_stockton/

 You can see the URL follows a logical hierarchy, and it would be easy to
 determine what the URL for the City of Sacramento, San Joaquin County,
 or Victory Park in the City of Stockton would be. Obviously the
 continent/country/state/county/city/location URL pattern would have to
 change for other parts of the world.

 I put a very simple HTML file with data about the City of Stockton here:

 http://www.standardwebmarkup.org/standard_places/north_america/united_st
 ates_of_america/california/san_joaquin_county/city_of_stockton/info.html

 The current info.html file is just a skeleton. It's more of a place
 holder right now than anything else.

 My thought was to also put a WKT file (place.wkt) representing the
 location of the place and a simple text file (data.txt) with facts about
 the place at this same URL:

 http://www.standardwebmarkup.org/standard_places/north_america/united_st
 ates_of_america/california/san_joaquin_county/city_of_stockton/

 Now, if someone wanted to write content about the City of Stockton, they
 could simply do something like this:

 a
 href=http://www.standardwebmarkup.org/standard_places/north_america/uni
 ted_states_of_america/california/san_joaquin_county/city_of_stockton/S
 tockton/a

 If everyone that was putting web content about Stockton online did the
 same thing, search engine and other tools would be able to link data
 from this web content to a single location.

 This becomes even more powerful if we come up with some rules for the
 content of the info.html file, place.wkt file, and the data text file.
 Here are some examples:

 (1) Specify that the place.wkt file have both a point and a polygon WKT
 representation, or a linestring representation, of the place when
 appropriate.

 (2) Specify that the info.html file use a list with alternate place
 names. This list would be identified with an html class value of