[Data-modeling] how much work done on modeling of personal names -- even for surname + given name?

Ed Laurent spatial.db at gmail.com
Thu Mar 5 16:39:10 UTC 2009


> If you add people as admins to your base, they will have full admin
> rights.  You probably want to put the relevant types in a base of
> their own, though, rather than using litcentral -- unless you want
> people to be able to change all that schema as well.

Um.. not sure how this helps me test out changes to schema in common and
other member's bases on sandbox...

It didn't seem right at the time to make a new base for a couple schema. I
put these schema in my litcentral base b/c that's where I want them if they
don't go common. If other people want to see changes I'm happy to consider
them. If there's a big call for it or if someone really wants to make
changes that I don't agree with then they can copy them.  It took me about
10 minutes to copy them by hand into sandbox.

> Was [use of periods for exact matches] actual documented functionality, or
just something you
> discovered?  I don't recall ever having heard that.  It would be cool
> though!

Faye told me about this functionality around a year ago.


1) do you need that CVT to be time mediated?  If not, how do you handle name
> changes, maiden names, etc?
>

I was modeling Robert's suggestion of "current name" only. Originally I
tried duplicating the CVT for "previous names" but that didn't work very
well. I think previous names would need a similar CVT with different
property names and descriptions to be intuitive. A date might work on both
CVTs but I'm not sure how often it would be used for a slight majority of
people who's names never change. Are you thinking one or two date
properties? Also, "current name" didn't seem to make sense for deceased
people so I called it "Most recent name".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freebase.com/pipermail/data-modeling/attachments/20090305/e56b2c23/attachment.htm 


More information about the Data-modeling mailing list