My two cents is to have 3 properties: members, employees and volunteers. <br><br>For example, Joe Smith might be an employee of The Nature Conservancy, a paying member of the Union of Concerned Scientists and Sierra Club, and he volunteers sometimes for Sierra Club activities. The 3 properties would permit the storage of all this data in a simple way. <br>
<br>"Key person" is more of a subjective call depending on the purpose for using the data. Some users might think volunteers are key people when looking for future volunteers. Other users might think employees and members are key people because they involve money going in and out of the organization.<br>
<br>A reciprocating "Volunteer" property added to the "Person" type sounds like a good thing to me.<br><br>-Ed<br><br><br><div class="gmail_quote">On Thu, Mar 6, 2008 at 1:51 PM, Bryan Cheung <<a href="mailto:bryan.cheung@metaweb.com">bryan.cheung@metaweb.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">> 2. One of the designers of the organization type originally created<br>
> the property key_people, and later decided this was a bad idea and hid<br>
> the property. This property has been hidden for quite some time, but<br>
> there still exists some data that should be migrated.<br>
><br>
> The existing data should be migrated to /business/employer/employee<br>
> (employer is an included type) and the hidden property should be<br>
> deleted.<br>
<br>
<br>
</div>I'd like to to solicit feedback from the data-modeling gurus out there<br>
about this migration. Organizations can have paid employees,<br>
volunteers or a combination of both. While I believe the reasoning<br>
for getting rid of the ambiguous property "key person" is still valid,<br>
do people think the property "employees and other personnel" on the<br>
employer type is sufficient in capturing a "key person" who is a<br>
volunteer? An alternative would be to have a volunteer property (on<br>
employer or organization type); however, this might be complicating<br>
because the reciprocating property would either have to be on the type<br>
person or a new type like "volunteer".<br>
<br>
Suggestions?<br>
<br>
Thanks,<br>
<font color="#888888">Bryan<br>
</font><div><div></div><div class="Wj3C7c"><br>
<br>
On Mar 5, 2008, at 11:36 AM, Bryan Cheung wrote:<br>
<br>
> A couple of changes have been proposed for the /organization/<br>
> organization type:<br>
><br>
> 1. A user has requested that we add time span as a disambiguated<br>
> property on organization member.<br>
><br>
> <a href="http://www.freebase.com/view/discuss/organization/organization_member#%2Fguid%2F9202a8c04000641f8000000006fe1430" target="_blank">http://www.freebase.com/view/discuss/organization/organization_member#%2Fguid%2F9202a8c04000641f8000000006fe1430</a><br>
><br>
> I think it's a good idea to know when people were members of an<br>
> organization; however, the relationship between an organization member<br>
> and an organization is a simple one, and we would have to insert a CVT<br>
> to represent the timespan-member relationship.<br>
><br>
> 2. One of the designers of the organization type originally created<br>
> the property key_people, and later decided this was a bad idea and hid<br>
> the property. This property has been hidden for quite some time, but<br>
> there still exists some data that should be migrated.<br>
><br>
> The existing data should be migrated to /business/employer/employee<br>
> (employer is an included type) and the hidden property should be<br>
> deleted.<br>
><br>
> Does anyone disagree with this changes? Are the applications being<br>
> developed that will break due to these changes?<br>
><br>
> Thanks,<br>
> Bryan<br>
><br>
> _______________________________________________<br>
> Data-modeling mailing list<br>
> <a href="mailto:Data-modeling@freebase.com">Data-modeling@freebase.com</a><br>
> <a href="http://lists.freebase.com/mailman/listinfo/data-modeling" target="_blank">http://lists.freebase.com/mailman/listinfo/data-modeling</a><br>
<br>
_______________________________________________<br>
Data-modeling mailing list<br>
<a href="mailto:Data-modeling@freebase.com">Data-modeling@freebase.com</a><br>
<a href="http://lists.freebase.com/mailman/listinfo/data-modeling" target="_blank">http://lists.freebase.com/mailman/listinfo/data-modeling</a><br>
</div></div></blockquote></div><br>