Discussions on Location

From looking at the key to that map, I'd say they're different since they have different entries in the key. The Census Bureau uses approximately a bazillion different levels in its hierarchy, including those that you see in the key like block, tract, CDP, CCD, MCD, etc, etc.

Do you need to know that it's a CCD, or can you just use the generic statistical region type?

Welcome to Freebase. This is just my personal opinion, but I'd say that pothole data is probably a little more fine-grained than Freebase traditionally deals with, but probably not completely out of bounds.

Having said that, you seem to be missing the temporal dimension. Really bad potholes from 2007 have probably been fixed by now...

Why should it be disjoint?   I don't know the US census system well, but it seems fairly reasonable to me that some towns (especially small ones) could be CDPs.

 What query are you doing that shows things twice as you describe?  And what's an example of a town that is appearing twice for you?

Taking a look at the topics which are typed as both city/town and CDP... many of them are described as "Springfield is a CDP within the town of Springfield", i.e. the CDP is just the central area of the town, in which case the CDP should *not* be typed as city/town. For most of these there are two different Wikipedia articles, eg. "Springfield, Illinois" and "Springfield (CDP), Illinois", leading to two different Freebase topics.

But there are counter examples, eg. Hudson, New Hampshire where there is only one Wikipedia article for both the town and the CDP, and hence one Freebase topic.  Perhaps topics like these should be split?

I haven't looked at every single topic on the list yet, but so far I haven't found any where the town limits and the CDP boundary are exactly the same.

So yes, there may be a data cleanup task here... but regardless, I would recommend rewriting your query so it doesn't break in these cases, as there's nothing we can do to *guarantee* that such co-typing won't occur, even if we do clean it up for now.

Sorry, I should have provided a reference.  I was looking at the Wikipedia page, but here's the official definition http://www.census.gov/geo/www/psapage.html#CDP

The CDP is basically a device used to provide boundaries which have no administrative basis so that the census counts things that otherwise will not be counted.  It's used where there's something interesting to count which doesn't follow an administrative boundary.  In New England, it's often used to count the "urban" core of a town center separately from it's rural surroundings, but it has all kinds of uses in different places.

The CDPs can change from census to census and, because of their definition, they're never the same as an administrative district (since that's already counted). 

Here are the two entries for Hudson - Hudson town in Hillsborough County and Hudson CDP in New Hampshire - so, yes, that topic should be split.

http://factfinder.census.gov/servlet/SAFFPopulation?_event=ChangeGeoContext&geo_id=16000US3337860&_county=hudson&_cityTown=hudson&_state=04000US33

The Census bureau has rule that a CDP can't have the same name as its containing administrative area or any adjacent administrative area.  This seems like a good rule to reduce confusion, so I'd suggest that, for Freebase, the string "CDP" not be stripped from the name of "Hudson CDP."

I'm continuously improving my various resolution algorithms, so I won't be dependent on the cleanup, but there are other good reasons to do this.  For example, if someone asks "how many cities/towns are there in New Hampshire?," they're going to get the wrong answer.

I believe Praveen or someone on the data team has been gathering just such a list.  I had heard they intended to use it for a back-end process to look for dubious data and ask humans to check it, rather than as input to a website feature, but I suppose it could be used for both.

 One concern is thinking about all the places where you would have to do that check.  Not just when someone hits "Add Type" but also when they are adding properties somewhere else that have an expected type of that type, or when they are adding topics to a view, or whatever.  Probably all over the place.  And you still couldn't prevent people doing it through scripting or external applications.  The data team's "clean up afterwards" approach is going to be necessary no matter what the website does.

I don't know if it's been edited since you posted this, but the help for the property currently says "Offices, stores, outlets, plants, campuses, etc. run by this company. These might not always have obvious names, but names like "X Company Headquarters" or "Y Store, Fifth Ave., New York" are perfectly acceptable. (Enter Business Location)". This is accessible by clicking the ? in the data entry popup. Is that what you were looking at or some other tool tip?

Think of it as a branch office, not a location like a city or street.

Yes, Tom, that was the tool tip I looked at. I don't like the fact that I have to click on the ?. But besides that, I still don't understand the helpfulness of this property if it doesn't explain itself well enough. That last sentence is the key to good data, in my opinion. We have seen what happens when a property is NOT described at all, even you and I have been bit by that scenario. Certainly, I am not going to fill it with all the McDonalds, Burger King, or Wal-Mart locations. (Someone appears to already be doing that - lol.)

If I understand this correctly, your saying that for Loving Care Agency and it's 28 business locations( but I'm NOT supposed to think of it as a LOCATION, even though it uses the term, I'm supposed to think of this as a branch office - lol), that I would type in a unique name, such as "Loving Care Office, Jersey Shore" and it shows as that business location type is not found, of course, so I then click CREATE NEW BUSINESS LOCATION, which creates a new unique GUID and TOPIC for a business_location , and then for that new business_location store, office, branch, etc that was created, at it's /business/business_location/address I would add the address information filling in the appropriate city there. I'm fine with that.

However, The bad tool tip description, to me, results in extra information that is sometimes not needed. In my opinion, storing address information freeform in the name misses the whole point of Freebase. And results in illogical views such as this http://www.freebase.com/view/en/burger_king/-/business/company/locations where you have the address field already showing and certainly you can create your own views whenever you want.

I think reducing the ambiguous description will also help reduce these extremely long business location names that really aren't necessary. THIS BAD DESCRIPTION IS CREATING VERY LAZY FOLKS that type a bunch of properties, address, city, state, etc. all in one line, the "business location name", instead of taking the time to fill in the appropriate properties, and collect good data. Or perhaps they didn't properly scrub and delimit their data loads, who knows. But in my opinion, 1 good bit is worth more than 1000 bad extra bits.

What are your ideas or agreements ?

This is a complex thread to jump in late to, but I think we're down to just the property name being an issue? (Since the help text wasn't causing the topic names which included street addresses, which I think was the main cause of Thad's complaint about them. But I could be wrong, and if there are additional ways the help text could be improved, though, I'd be happy to hear them.)

The problem with the property name, as Tom says, is that the Business Location type can be used for all kinds of things, so we need a term that can encompass branches, headquarters, outlets, store/restaurant locations, offices, and the like. Unfortunately, the closest term, "location," has another meaning which is confusing. (Certainly, in the retail world, individual stores of a chain are commonly called "locations.") We could go in the direction of a list, and call it something like "Branches, stores, etc." I try to avoid that sort of phrasing in general, but sometimes it's the best choice. Other suggestions would be welcome, too.

I might get a bit off topic here concerning the Web UI itself, but bear with me...

2 problems were identified by me, Jeff.

1. Should the tool tip description remain as giving an example of "Y Store, Fifth Ave., New York" that is perfectly acceptable , when we clearly don't want redundancy, but merely normalization ? ....and if so # 2 is a suggestion to improve the data collection UI ...

2. Why couldn't the Web UI be improved ? When I go here to this view to add business locations http://www.freebase.com/view/business/business_location and click add more topics, the pop-down defaults to showing only the name, opening date, closing date, and parent company. I think better properties to collect here would be the location details themselves, yes ?, such as name, address, city, state, and parent company and preferrably show them going left to right as a new row, just like a "gasp" spreadsheet, rather than vertically now on the right? The UI is really the culprit for me, when I'm going to add less than 10 items, because it doesn't mimic a spreadsheet view entirely, in my opinion. For more than 10 items, I use an external spreadsheet editor and tools such as Loader.

I stay in EDIT mode, so I benefit, but we cursed sometimes by that view and it's tempting "edit" link on the left of individual properties on any particular topic and usually smack face first into data collection problems from a users perspective such as this. I rarely click the Detailed View link just to the right of it. Don't get me wrong, I like the inline edit, but sometimes, its ... a pain, and slow.

This would be a good idea; especially if it could be presented as a synthetic property derived from geolocation boundary intersections where present/possible.

At the same time, I realize this would qualify as a very intensive GIS application :)

Yeah, just after posting this I discovered Geosearch. I'm very impressed.

I think Ed's idea is a good one for its simplicity. My idea was more towards batch-populating this new property from information that can be derived from existing properties (i.e. all-pairs intersection query on the GIS database). Perhaps a decent opportunity for an app?

Re Faye's question: Looks like I updated the type description for "Olympic Participating Country" the day after she posted that, but neglected to say anything in this thread. The short answer is that the IOC has, from time to time, allowed participants from "countries" that do not correspond to any existing geopolitical entity (examples include the Unified Team and Independent Olympic Participants, and which cannot be described as locations.

I'll answer Thad's other question in the Olympic Athlete thread, because I think it's actually a different question.

I would think a hospital is more akin to a business location - it "HAS-A(n)" address. Most of the existing properties on hospital are very similar to business location.

It is not uncommon for hospitals/medical centre buildings to have more than one medical tenant/practice working from the premises.

@priority9 In Freebase a structure "IS-A" (dated) location.

Structure includes Location and Hospital includes Structure, but not Location, so this is simply a schema screwup that should be gardened away (and probably all types that include Building or Structure should be double checked as well).

If someone wants to change the schema for Hospital, that's fine, but let's make what's there internally consistent.

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!

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. 

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.

The UN/LOCODEs are available here http://www.unece.org/cefact/codesfortrade/codes_index.htm and even uncompressed they are only 5MB, so I'm not sure what the 900 MB figure is referring to.

There are about 70,000 entries which one would want reconciled with very high precision (although we've already got all the airports done), so it's a significant amount of work, but not overwhelming. Many locations include lat/lon, which could be used to increase the number which could be reliably machine reconciled before kicking the remainder out for hand reconciliation.

One of the other threads mentions NUTS which is apparently an EU only thing. Wikipediabreaks down how the levels align with administrative divisions within each country.

In summary there are:

Countries 27 Level 1 97 (region, area, etc) Level 2 271 (state, province, oblast) Level 3 1303 (province, county, arrondissment)

As you can see, there's some variation in how these things align from place to place. Some countries also skip some levels.

Since it's European only and less than 2K entries, I'd suggest just defining a new NUTS Location type or some such which has properties for each of the three levels or a property for level and one for code.

It's much more important to get the UN/LOCODE stuff sorted out though.

Looking at the NUTS info, it looks like we'd need a new type "NUTS region" or the like -- the NUTS codes (at least for Europe) frequently don't correspond to actual administrative divisions of countries.

I'm tempted to say that UN/LOCODE should just go on Location, though -- it seems like a lot of different things (mostly cities and airports, I guess) can have them, but I'm only saying this based on about ten minutes looking at the UN/LOCODE data.

Yes, there could be additional properties:

• type of cemetery
• permanent burial or rotational burial with avg length of internment before moving remains to an ossuary?
• public or private, restricted to certain groups or faiths?
• full up? percentage burial plot availability?

I agree that this area needs clarification, but I don't think deleting Cemetery, which seems to be the direction Faye is headed in, is the right solution.

My interpretation of the current types is that Place of Interment is pretty much any place that someone can get buried (i.e. anywhere) and Cemetery is a formal place specifically designated to receive remains. The Dated Location included type on Cemetery provides useful information on when a cemetery was established and closed/abandoned. Several of the properties outlined above would be useful additions. GNIS has a specific category of locations called "cemeteries." Most topo maps have a specific symbol for cemeteries. Most civilians have a strong visceral understanding of what a cemetery is and how it differs from just some random place where a person was buried once.

In my opinion, the right solution is to beef up Cemetery type and clarify how it differs from Place of Interment.

Great list.  I kind of assumed that Locations were intended to be Earth bound, so I'd say "no-fly zone" is a Location but Van Allen Belt and Sea of Tranquility aren't.  This also leaves out places of myth such as Shangri-La or Brigadoon.  Not sure what you do about Atlantis or other places what may or may not be real (and who's location is unknown).

Caves - yes, definitely.  Not only the cave mouth, but the entire cave/cave system are locations.

Lists - no, but the Galapagos Islands is an archipelago with a defined collective meaning as a group (as opposed to a list).

This affects all of France's DOM/TOM as well.  For example, both St-Pierre et Miquelon and La Réunion are typed as countries, presumably to provide a place to hold their ISO 3166-1 and FIPS 10-4 codes.  

Both of those standards include dependencies and other things with special status in addition to countries, so tieing storage for these code together with typing of "Country" is probably a bad idea.  Of course having a new type of "Thing with a FIPS 10-4 (withdrawn) code" isn't especially appealing either.

The real definition of a country is whether or not it's got a football team, so the FIFA code is probably OK to stay :-), but all the others should be examined to see if they're really tied to the commonly accepted definition of country. 

I'd like to use it as a disambiguator for names which are ambiguous.  The only place I've seen this is in the autocomplete box.  Are there other places that disambiguators are used?

After looking at again though, I realize this isn't going to be enough to fix things, so let me make the problem statement more general - fix autocomplete for locations so that it provides useful information.

Someone apparently set up a bot to go through and add city, state aliases to many of the U.S. locations.  This is mostly just noise because the useful part gets truncated.  If I type Worcester, I get

Worcester               ...(Worcester,...

as an autocomplete entry which provides absolutely zero additional information.  What I want to see is

Worcester                (Massachuset...

This would probably require a) removing all the current bogus aliases (they're not true aliases anyway) b) getting contained_by used as a disambiguator and c) picking the "best" contained_by to use in the UI.  The last piece is probably the hardest.

Of course, any alternate solution which provides useful disambiguation is acceptable too.  The current scheme doesn't. 

One problem is that not all countries follow the same hierarchical nesting of that country's locations.  /location/administrative_division is meant to be as generic as possible to account for that.  Administrative divisions could be states, counties, etc.

You could nest containment queries and restrict to certain types.  A query like:

[
  {
    "/location/location/contains" : [
      {
        "/location/location/contains" : [
          {
            "name" : null,
            "type" : "/location/citytown"
          }
        ],
        "name" : null,
        "type" : "/location/administrative_division"
      }
    ],
    "id" : "/en/germany",
    "type" : "/location/country"
  }
]

Would return all administrative divisions and their citytowns for the country Germany.

[
  {
    "/location/location/contains" : [
      {
        "/location/location/contains" : [
          {
            "name" : null,
            "type" : "/location/administrative_division"
          }
        ],
        "name" : null,
        "type" : "/location/administrative_division"
      }
    ],
    "id" : "/en/united_states",
    "type" : "/location/country"
  }
]

Would return all the counties of the states of the US.

This is the point:

Contained/contained by offers no description as to what the relationship is.  There needs to be descriptive relationships within individual types if not within location. The reason this Contained/Contained by system does not work is because eachcountry has a different hierarchy of locations.  If I want to pull information on a city, regardless of what country it is in, I should be able to easily find:

What country it sits within,

What State or Province it is in (if any at all) 

What County/Parish it is in (if any at all)

The advantage freebase has over other sites is that it can leave information null if it does not apply.  

Example of why this is an issue:

Oaxaca, Mexico

What am I talking about? The City? The State? Well lets just see what it is contained by.  Bost Oaxaca the State and Oaxaca the City are contained by Mexico.   Oaxaca the City is also contained by the State.  A user can be very confused on what Oaxaca they are looking at because it does not say the relationship it has with the locations it is contained by.

When you say "a user" are you referring to users of our website, freebase.com, or to API users?  API users can easily deal with this problem by limiting a query thus:

 "/location/location/containedby" : {  "id" : null, "type" : "/location/citytown" }

That would get only the cities contained by that thing.

This is a very complex problem.  Part of the issue is, as you mention, the fact that every county has a different "hierarchy" of administrative divisions.  It's recomplicated by the fact that in many, many cases the so-called hierarchy isn't really hierarchical. In the US, for example, it's convenient to think of a three-tier system: state, county, city (ignoring for now territories, DC, and townships). But not all cities are contained by counties: some cities (San Francisco and I think Denver) are also counties; some cities (Baltimore) are not contained in counties at all; and some cities (New York) actually contain counties.

To address this, what we've done for a number of countries (but by no means all of them) is to create separate types for each administrative division type (so the US has the types US State, US County, US Federal District, US Territory, and US Indian Reservation) so that you can tell which type of division it is separately from the containment.  Part of the problem in your Oaxaca example is that the state hadn't been typed with the Mexican State type (although it does have the administrative division type, which also indicates that it is farther up the local -> national scale of divisions than Oaxaca the city), which I've fixed.

I can't speak to your geo question, but I'll forward it on and maybe one of the geo guys can pop on and take a stab at it.

As for gnis, we have a gnis_bot that went through a big batch of them over the summer, but I don't think it's running constantly, or currently.  The property enumerates into a protected namespace, which currently only the location admins are allowed to edit, since the data came from an "authorative" source (a gnis dataset).

I tried the same thing you were trying, and got the same results.  I would suggest filing a client bug at bugs.freebase.com (if you don't mind).

Currently cemetery doesn't have any included types - we can add that.  When you type something in the client, the client handles adding the included types.  If you are going to type in MQL, you will have to make sure to add the included types in your type assertion.

The bug is https://bugs.freebase.com/browse/CLI-7404

Any suggestions on workarounds to get the desired list?

Thanks Jeff.

I just realized that my original query is actually *not* doing what I want.  It is returning all topics which have "cemetery" in their name and is not excluding those which are of type "/location/cemetery" as I'd hoped.

Do I have the nested query wrong?  How do I exclude things already typed as cemetery?

Never mind, I figured it out.

    "type" : [{"optional" : "forbidden", "type" : "/location/cemetery"}]

needs to be

    "type" : [{"optional" : "forbidden", "id" : "/location/cemetery"}]

I'd be happy with 130,000 cemetery topics.  More would be better. :-)

Picking a state at random, I see GNIS contains:

• 1012 populated places
• 829 schools
• 808 post offices
• 756 locales
• 575 cemeteries
• 396 parks 

In this context, it doesn't seem like there are really all that many cemeteries in comparison to some other things.

As a matter of fact, I'd have thought that all or almost all of the 2 million features in GNIS would be candidates for inclusion in a database like Freebase.

I guess the bottom line is "How many is too many?"