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

Ed Laurent spatial.db at gmail.com
Thu Mar 6 19:15:36 UTC 2008


Some other organization properties you might want to consider are those that
I included in "Ornithological
society<http://www.freebase.com/view/schema/user/spatialed/default_domain/ornithology>".
A well filled in example is Ohio Ornithological
Society<http://www.freebase.com/view/guid/9202a8c04000641f8000000006ac683c>.


-Ed


On Thu, Mar 6, 2008 at 2:03 PM, Ed Laurent <spatial.db at gmail.com> wrote:

> 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
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freebase.com/pipermail/data-modeling/attachments/20080306/d2075cd9/attachment.htm 


More information about the Data-modeling mailing list