Ski Area does not equal Company
-
-
Hi! I notice that as soon as you type a topic as Ski Area it automatically adds Company and Employer. Can we undo that please? Often the area is not a company itself, but more of a location, and is operated by an actual company.
In fact, it may be good to add Mountain to the Ski Area data so you can see which mountains the area covers??
-
Hey. First of all it's great to see other people taking an interest in this base. PlesefFeel free to bring up data modeling issues. It's been a while since I worked on this base, and I'm sure there are areas that could use some refactoring. In modeling Ski Areas, I was attempting to model the organizations that run ski lifts.
I see where you're goign with this, but it seems to me that, save for a few mom and pop ski hills, that these organizations are always employers. They always have to hire someone to run the lifts. In the few cases where they are not, they can be detyped as employers. I can see how they might not be companies though. I believe that Mad River Glen is run as a cooperative. Did you have a specific place in mind?
Again, thanks for the work, and let me know if you have other ideas for the base. Hopefully, as Freebase's geographic capabilities grow, this base will become more and more useful.
-
I guess it depends on how you want all this to work.
Mad River Glen Cooperative is the company that runs the Mad River Glen ski area. I don't think you'd call the ski area Mad River Glen Coop, though. Or do you want it that way?
Looking at a couple of the ski areas, I see that Mammoth Mountain Ski Area's company is "Mammoth Mountain Ski Area LLC", while Blue Hills Ski Area appears to be "Recreational Sports Inc". Blue Hills doesn't work neatly, does it??
And I think you have to be paid by an actual "Company". That's why Employer is co-typed with Company.
I guess my overall point is that I don't think a Location can also be a Company/Employer. Having both Types in the same topic seems counterintuitive.
-
I agree with evening that being both a location and a company doesn't make much sense. Although you don't have to be a company to be an employer -- schools, non-profits, governments, etc. can all be employers, for example.
I think keeping them separate might yield some interesting facts, too -- I bet that there are a number of ski areas that are run by the same company, for instance. Or, if you had lat./long. for the ski area, and the address for the company headquarters, you could see which management companies were based furthest from the ski area.
-
Sorry for my delayed response. You both raise interesting, valid points. It definitely makes sense to me to remove the company included type. I'm still concerned about the proper way to model these relationships.
When I created the ownership property, I intended it to be used either for an individual or an organization. For example, Snowbird is owned by Dick Bass. I think that the distinction between the Snowbird corporation and the Snowbird resort is insignificant and would only confuse users. If I were looking for the Director of Skiing, my instinct would be to look at the Snowbird ski area topic, not a separate Snowbird LLC topic page.
On the other hand, Boyne Resorts owns Brighton and many other ski areas. This would be reflected in the ownership property. However, I think it's a valuable piece of information that a person is employed as the General Manager of Brighton, not just as an employee of Boyne Resorts. This would be similar to a subsidiary company relationship. I would therefore argue for the inclusion of Employer in the Ski Area type.
For now, I'll remove company as an included type. Do you think this is adequate, or am I totally missing the boat, and conflating two fundamentally different types? I suppose another solution might be to create a "managing company'' property. -
I think this is probably OK. Although managing company might be an interesting thing to model as well, if you think you can get the data.
-
