[Data-modeling] Proposed changes to the/organization/organization type

Fri Mar 7 01:46:49 UTC 2008

There is already a Board
member<http://www.freebase.com/view/business/board_member>type with a
Board
member title <http://www.freebase.com/view/business/board_member_title>property
that links to the
Secretary <http://www.freebase.com/view/en/secretary> topic. I requested
that Board member be reciprocated one way with Member awhile back (a board
member is always a member but not vice versa). Members and board members are
not necessarily employees and often aren't within organizations. Companies
are different.

As for the definition of "Key people", I think that term is so subjective
that there is no way to replace it without defining the context. Where do
you draw the line between the unpaid person who folds the chairs and the
unpaid person who keeps the minutes or holds the gavel? I think there are
many reasons to keep track of volunteers but maybe not every instance of
volunteering. For example, how would you describe the position of "volunteer
fireman" if there was a reason?

IMO a volunteer is not an employee no matter what they do. You can have an
unpaid employee but that person is not necessarily a volunteer. In fact, I'm
about to become an official "unpaid employee" of my current employer so that
I can stay in my office when I switch jobs at the end of the month. I will
be paid by another company and work on projects that benefit both companies.
Hence, I will be an employee of both companies but a volunteer of neither.

What about contractors? I can think of many reasons to keep track of them
too (e.g., public people who receive government contracts and are "former"
business partners with the contract managers). Are they employees? Not in my
opinion and the IRS doesn't think so either.

-Ed

On Thu, Mar 6, 2008 at 7:59 PM, Jeff Prucher <jeff at metaweb.com> wrote:

>  I think the idea behind the proposed "volunteers" property is for unpaid
> staff/officers, rather than for people who show up to fold newsletters or
> staff tables or whatnot, since we're talking about replacing the property
> "key people". In my opinion, the fact that Joe sometimes volunteers for the
> Sierra Club, in addition to the fact that he is a member is not that
> interesting. But that he's the secretary of his local chapter, for which he
> receives no pay, is of more interest.
>
> The question for me is, does the property "employees and other personnel"
> (on the type "employer") sufficiently address unpaid staff
> positions/officers? The correllary is whether the type "employer" makes
> sense as a co-type on organizations that have no paid staff.
>
> Jeff
>
>  ------------------------------
> *From:* data-modeling-bounces at freebase.com [mailto:
> data-modeling-bounces at freebase.com] *On Behalf Of *Ed Laurent
> *Sent:* Thursday, March 06, 2008 11:04 AM
> *To:* Freebase data modeling mailing list
> *Subject:* Re: [Data-modeling] Proposed changes to
> the/organization/organization type
>
> My two cents is to have 3 properties: members, employees and volunteers.
>
> 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.
>
> "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.
>
> A reciprocating "Volunteer" property added to the "Person" type sounds
> like a good thing to me.
>
> -Ed
>
>
> On Thu, Mar 6, 2008 at 1:51 PM, Bryan Cheung <bryan.cheung at metaweb.com>
> wrote:
>
> > > 2. One of the designers of the organization type originally created
> > > the property key_people, and later decided this was a bad idea and hid
> > > the property.  This property has been hidden for quite some time, but
> > > there still exists some data that should be migrated.
> > >
> > > The existing data should be migrated to /business/employer/employee
> > > (employer is an included type) and the hidden property should be
> > > deleted.
> >
> >
> > I'd like to to solicit feedback from the data-modeling gurus out there
> > about this migration.  Organizations can have paid employees,
> > volunteers or a combination of both.  While I believe the reasoning
> > for getting rid of the ambiguous property "key person" is still valid,
> > do people think the property  "employees and other personnel" on the
> > employer type is sufficient in capturing a "key person" who is a
> > volunteer?  An alternative  would be to have a volunteer property (on
> > employer or organization type); however, this might be complicating
> > because the reciprocating property would either have to be on the type
> > person or a new type like "volunteer".
> >
> > Suggestions?
> >
> > Thanks,
> > Bryan
> >
> >
> > On Mar 5, 2008, at 11:36 AM, Bryan Cheung wrote:
> >
> > > A couple of changes have been proposed for the /organization/
> > > organization type:
> > >
> > > 1. A user has requested that we add time span as a disambiguated
> > > property on organization member.
> > >
> > >
> > http://www.freebase.com/view/discuss/organization/organization_member#%2Fguid%2F9202a8c04000641f8000000006fe1430
> > >
> > > I think it's a good idea to know when people were members of an
> > > organization; however, the relationship between an organization member
> > > and an organization is a simple one, and we would have to insert a CVT
> > > to represent the timespan-member relationship.
> > >
> > > 2. One of the designers of the organization type originally created
> > > the property key_people, and later decided this was a bad idea and hid
> > > the property.  This property has been hidden for quite some time, but
> > > there still exists some data that should be migrated.
> > >
> > > The existing data should be migrated to /business/employer/employee
> > > (employer is an included type) and the hidden property should be
> > > deleted.
> > >
> > > Does anyone disagree with this changes?  Are the applications being
> > > developed that will break due to these changes?
> > >
> > > Thanks,
> > > Bryan
> > >
> > > _______________________________________________
> > > Data-modeling mailing list
> > > Data-modeling at freebase.com
> > > http://lists.freebase.com/mailman/listinfo/data-modeling
> >
> > _______________________________________________
> > Data-modeling mailing list
> > Data-modeling at freebase.com
> > http://lists.freebase.com/mailman/listinfo/data-modeling
> >
>
>
> _______________________________________________
> Data-modeling mailing list
> Data-modeling at freebase.com
> http://lists.freebase.com/mailman/listinfo/data-modeling
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freebase.com/pipermail/data-modeling/attachments/20080306/c78252aa/attachment-0001.htm 