Why both "state" and "region" and not "province", "oblast", etc..?

[wdoekes]

As a non-American, I find it strange why there would be two ways to specify a region when neither of them applies to the Dutch "province" or the Swedish "landskap" (or "län") or "oblast".

Can't you just remove "state" and add this to the description: "Americans put state in the region field. Others may put region or province or whatever seems most likely for their country there."

[thomasdavis]

I thought state and region were the only ones used, but I guess that was naive. It's just hard to theme when the property names are dynamic.

Because templates might print {{state}} or {{region}}, if someone could chime in with some abstract term which might represent all that would be great.

Otherwise we might have to roll with each possibility (state,region,oblast,province)

[wdoekes]

Otherwise we might have to roll with each possibility (state,region,oblast,province)

Yuck.

I'd go with:

{
 "region": "Texas",
 "regionType": "state"
}

Where regionType would be free form, but with a couple of common suggestions.

[thomasdavis]

ahh it's been a long day, your suggestion is great.

On Mon, Jul 7, 2014 at 6:51 PM, Walter Doekes notifications@github.com
wrote:

Otherwise we might have to roll with each possibility
(state,region,oblast,province)

Yuck.

I'd go with:

{
"region": "Texas",
"regionType": "state"
}

Whether regionType would be free form, but with a couple of common
suggestions.

—
Reply to this email directly or view it on GitHub
#19 (comment)
.

Thomas Davis
http://thomasdav.is

VP of Tech - Earbits - http://earbits.com
Co-founder - Cdnjs - http://cdnjs.com
Founder - Backbone Tutorials - http://backbonetutorials.com

[wdoekes]

Long day? As a non-American, I find that it's still morning ;-)

Jokes aside, thanks for the positive response!

[Kwpolska]

Most people do not need to have their region type specified. A form like {{city}}, {{region}}, {{country}} should be enough.

PS. city is discriminating people living in towns and villages.

[DonDebonair]

I second what @Kwpolska says, with regards to region. I don't think a regionType is necessary. In general I'd like a standard like jsonresume to strike a balance between correctness and usability. Otherwise it will quickly grow into a complex collection of key-value pairs.

With regards to city and discriminating people: on the one hand that is true, and you could solve that by using something like municipality, on the other hand that will confuse people even more. We're talking about resumes here, so a lot of people will probably put down the nearest city anyways, because putting down an obscure village will probably deter some companies from hiring you, because they don't have a clue if it's geographically feasible for you to be working for them ;)

[wdoekes]

I tried municipality in a database once. Never again. city gets my vote any day.

As for the regionType: I agree that it's not strictly needed.

However, there is the risk of people using 'region' as an actual region, so you cannot reliably use to filter on.

For example, if I live near Amsterdam (capital of NL), I could put various in things there:

1. province: Noord-Holland
2. economic region: Randstad
3. vicinity of Amsterdam: regio Amsterdam

We could just accept that filtering by region may prove difficult, and leave it up to the author of the resume to specify the most sensible value there.

[DonDebonair]

I totally agree on not using municipality, just wanted to mention it for completeness' sake ;) LDAP uses it, and I hate it!

An option for region could be, to call it state anyways. I know that's a very US-centric model, but on the other hand, almost every website uses that nowadays, and I don't know about the rest of the non-US residents, but I always end up putting my province there :)
If we do use region (which might be semantically better), I agree that we should just leave it to the author to interpret that.

[Kwpolska]

But then again, no matter which of those we choose, sorting is still impossible. There are tons of ways to refer to a thing:

• California
• Calif.
• CA
• US-CA

And then we get out of our US-centric bubble, to eg. Wrocław, Poland, which we can say:

• DS, PL-DS — ISO code; rare
• Dolny Śląsk — historical/geographical region
• Lower Silesia — ↑ in English
• (województwo) dolnośląskie — official name of the administrative unit
• Lower Silesian (Voivodeship) — ↑ in English
• D — car plate (okay, that’s a bit too hardcore)

There are also two, more unlikely options, to use Śląsk/Silesia, which may anger some people, and that would be generally used for Upper Silesia instead.

---

One might also use the term province.

Or, be even more hardcore: require the ISO 3166-2 codes (the format is: [A-Z][A-Z]-[A-Z0-9]+ — that is, country code (two letters, dash, some digits/letters)

[DonDebonair]

That's why I think we should stick to region and let the author of the resume figure out what s/he wants to put there. We cannot possible please everyone/satisfy every possible condition.

[wdoekes]

#12 geotagging makes the whole sorting/filtering point moot.

[DonDebonair]

👍 to geotagging

[thomasdavis]

City sounds like it will stay

Geotagging is great and seemingly solves all the problems but I'm not sure it makes to push as the standard way to begin with. The theming systems will obviously have to have a geo lookup built into them so maybe it makes more sense to push for geo tagging when that functionality gets built out.

For the sake of simplicity, it sounds like a good idea to either settle with either Region or State.

I don't know enough about websites who use Region but State does seem pretty global even though it's not correct for some countries.

[vote539]

Maybe we should just let people who live in a state put state: "CA", people who live in a province put province: "BC", and so on. It's more important IMO to increase the amount of metadata available in the JSON file, and then just let the templating engine figure out how to display it.

[wdoekes]

+1 to keeping only "state" for the v1 version

[Kwpolska]

@vote539, this sounds quite impossible. The region/regionType proposal is doable, but this just cannot work. There are tons of names, the schema and templates would have to account for all of them.

[DonDebonair]

I agree with @Kwpolska that allowing for many different attributes with almost the same meaning, will be hell for templating engines. I think we're overengineering this. I also happen to agree with @wdoekes that we should just stick with "state" or "region" (pick one) for V1.

[osg]

As an American who lives in Germany, I prefer "region" because a state is also a region within the US.

[ocram]

What about this then? #79

[osg]

Build does not pass, please revisit.

[DonDebonair]

I still think we should pick one ("region" has my preference as well) and stick with that for the time being. That means that #79 would be obsolete.

[osg]

+1 for "region", and simplicity for v1. Can always revisit.

[thomasdavis]

Experimenting with a new label called "Decision Needed", this issue has it applied. It means we will be passing something through in the very near future.

[thomasdavis]

I feel like flipping a coin on this one, hard decision.

region just seems to encompass more than state so we will just push ahead with it.

Maybe we will change the culture of the world and region will become prominent everywhere e.g. The United Regions of America

[ocram]

Compared to "state", the term "region" is much more abstract and general, so that should be fine for the spec.

[DonDebonair]

I created the above PR to fix this.

[thomasdavis]

Issue resolved and added to Changelog