City/Town

City/Town: Newspapers?

2008-06-30T22:02:22.0005Z

I think a property for "areas covered locally" or something similar would be the best way to capture this. Of course, the trick is then getting the data.

City/Town: Newspapers?

2008-06-29T05:23:31.0012Z

Very specifically, I wanted to ask, "What are the websites of the newspapers in the 3 cities neighboring the Federation of Damanhur?"

Of your two options, if I had to pick one, I would ask, "What newspapers cover a specific city locally?"

For Turin, (for example,) according to Wikipedia, the newspapers are: La Stampa, Tuttosport, and the Turin Metro.

City/Town: Newspapers?

2008-06-25T00:51:47.0001Z

Do you have a specific use case in mind? I'm hesitant to add this property to City/Town, because a lot of cities don't have their own newspapers, and a lot of newspapers are regional (Contra Costa Times for Contra Costa County, CA, for example). Is the idea just to be able to see what newspapers cover a specific city locally? Or are you specifically wanting to know what newspapers are based in a given city?

City/Town: Newspapers?

2008-06-24T23:24:37.0012Z

City newspapers? A link to the city newspapers?

For example, Santa Cruz, CA -> Santa Cruz Sentinel.

For example, Seattle -> both Seattle Times & Seattle P-I.

City/Town: "Date founded" vs "Founded"

2008-03-27T17:16:34.0007Z

Good catch. The "founded" property on City/Town is an older property. "Date founded" is actually on a supporting type called "dated location", which we created to be used with many different types, including City/Town, Administrative division, and Country. But we forgot to get rid of the old property on City/Town. I'll open a bug to address this. Thanks!

City/Town: "Date founded" vs "Founded"

2008-03-27T05:18:05.0012Z

Both of these accept a Date/Time type, so they seem to be equivalent. Why are they both part of the schema?

City/Town: UN/LOCODE

2008-01-23T22:57:43.0007Z

We actually have a property on the location type for the US Geographic Names Service UFI code (the property is called "GEOnet Feature ID"), which would serve that purpose. The main problem with loading the data, besides its sheer volume (or because of its sheer volume -- I don't know how many records it is, but the download file is a 900MB txt file), is reconciling that data against our existing topics, which has kept us from taking this on yet. But we do agree that this would be valuable data to have in Freebase.

City/Town: UN/LOCODE

2008-01-23T16:05:31.0000Z

Hi,

It would be great if you could consider this carefully. I think the crucial thing is not that it necessarily be UN/LOCODE, but that there be some kind of identifier, since without it it's hard to use this information.

I'll watch this thread.

City/Town: UN/LOCODE

2008-01-14T18:17:13.0007Z

Hi larsga,

Thanks for the suggestion. We have discussed this data before; however, we have to go back and look at the licensing around it. Stay tuned!

City/Town: UN/LOCODE

2008-01-13T12:04:35.0012Z

The UN has defined ~55,000 codes for various locations around the world, mainly cities/towns/airports/ports. These are quite widely used to identify locations, and it would be great if Freebase had a "LOCODE" field to hold these identifiers. They're of the form "XX YYY" where XX is the ISO 3166 two-letter country code, and YYY is the actual locode.

This is really important because without unique and well-known identifiers for the city/towns in Freebase it's very hard to actually make use of the data anywhere else.

City/Town: Country field needed!

2007-11-21T05:44:32.0007Z

I hear you on usefulness... there are definitely trade-offs being made in this model. Hope we can get you an answer to your query question on the data modeling mailing list soon.

City/Town: Country field needed!

2007-11-20T12:13:06.0000Z

I still believe we need a "Country" field. A Location can be "contained by" many things - a region, an administrative division, a sub-urban area, county, province, a national park, a postal district. But one thing is common to all Towns - they all exist within a Country. There might be several levels of "contained within" between Country and Town - but "what country is this town in" is a regular question and it's a solid principle of database design to de-normalise the structure of the database intelligently away from the purely abstract and "perfectly non-redundant" model to allow for actual "USEFULNESS" (anyone heard of this concept?!) and performance of the data! Country field please!

City/Town: Founded By

2007-11-13T00:41:44.0012Z

Please consider adding a “Founded By” field which references a “Person” type. This historical information would be very useful to historians along with other individuals.

City/Town: Parks and Schools

2007-10-11T23:09:54.0000Z

For parks, you can enter the city in the "contained by" property. For schools, you have to fill in the address property. (If you don't know the full address, it's OK to just put in the city -- it's more information than we currently have, and someone else can always add more information later.)

City/Town: Parks and Schools

2007-10-11T20:29:44.0012Z

How can I link a City/Town to a Park or a School?

City/Town: Neighborhoods?

2007-09-05T17:31:17.0007Z

The contains property is pretty unconstrained -- anything that can be considered a location is fair game. So New York City can contain not only The Bronx and Harlem, but also Central Park and Todt Hill (the highest point in NYC). The "neighborhood" type already exists, although it's pretty empty right now.

City/Town: Neighborhoods?

2007-09-05T16:18:10.0005Z

Here's a question: how specific should the "Contains" box be? For instance, New York City contains borroughs as well as neighborhoods. Should we consider a separate type for neighborhoods, so they can be grouped and distinguised from jurisdictional boundaries?

City/Town: Postcode/zip property

2007-08-28T11:50:46.0000Z

totally agree

City/Town: Postcode/zip property

2007-08-26T21:51:20.0012Z

I think it would be good to add a postcode/zip to locations.
There are many free postcode date tables out there.
Cheers, Phil

City/Town: Should we allow multiple dated populations?

2007-08-22T17:11:10.0007Z

The same argument does indeed apply; thanks for catching it. All three population properties (on citytown, country, and administrative_division) now accept multiple values.

City/Town: Should we allow multiple dated populations?

2007-08-21T06:10:20.0007Z

You made City Population have multiple values to track changes over time. Why does not the same argument apply to Country Population which is still single valued?

City/Town: Adding a new property...

2007-07-27T20:53:48.0004Z

Hello, just starting out, so don't shoot me if it is a silly question. I have been on the Help but can't seem to figure this out...

bottom line, I think it would be helpful to have a property "surface" (square km, etc) for the location type. For cities, regions, countries etc it's interesting to know this kind of information...

again, sorry if I posted in the wrong place, let me know...

ciao

Luca

City/Town: Should we allow multiple dated populations?

2007-07-25T22:37:02.0008Z

I agree. I've made it so you can have multiple populations.

City/Town: Should we allow multiple dated populations?

2007-06-08T00:09:40.0011Z

Particularly since population is disambiguated by date, I'd expect to be able to enter multiple dated populations for a City, and track changes over time.

City/Town: Country field needed!

2007-05-26T00:19:46.0006Z

Actually, city/town has an included type called 'location' which has a property called 'contained by' that will hold the country information. This may seem overly abstract, but it is a general model that works well for locations of any type -- if 'country' was added to city/town, it would likely show up twice which would be redundant and might be confusing.

I do notice that St. Petersburg isn't typed as a location - which it should be.

City/Town: Country field needed!

2007-05-25T12:01:45.0011Z

Hi!

Can we add a Country field to the city to denote the country it's in?