I.e., no need for
Mom BirthMotherTo Tom startdate forever
because EVERY "People" has exactly one birthmother and birthfather
(even if not known)
I'm refactoring my the tables that I use to track entities
(most commonly people).
I had naively assumed 1:1 relations between certain entries
where that isn't really guaranteed /in all such cases/.
E.g., everyone has a (birth) mother and (birth) father.
But, can have various mother or father *roles* at
different times in their lives. (Bob fathered Tom;
but, Joe ended up being the father figure in Tom's
life -- until Larry replaced Joe as his "mother's"
love interest, etc.)
Likewise a person can have multiple spouses (which SHOULD
/legally/ be separated in time, but that's not a known)
Anyway, it seems to make sense to add fields for BirthMother
and BirthFather to all People entities. But, handle all
other relationships with a separate relation -- one that defines
a TYPE of relationship and the TWO parties involved.
E.g.,
Joe FatherFigureTo Tom startdate enddate
Larry FatherFigureTo Tom startdate enddate
I.e., no need for
Mom BirthMotherTo Tom startdate forever
because EVERY "People" has exactly one birthmother and birthfather
(even if not known) just as they have a single birth date, sex,
etc.
This then can be extended for non-human entities:
CompanyA EmployerOf Tom startdate enddate
I can't see any way of avoiding this complexity and still
covering all the bases (e.g, putting an "Employer" field
in each person's record allows for only a single employer
to be tracked)
Sadly, I don't see commercial "contact" databases that even
attempt to handle these things intuitively. E.g., we remember
facts as relationships. So, if I wanted to find the name of
Tom's coworkers, I would look for his employer and then any
People who have an "EmployeeOf" relationship with that employer.
Or, to find the name of his brother-in-law, go to his spouse
and then find her parents and anyone who is male and claims
either of them as a parent.
Etc.
[I guess when you write code, the idea of chasing pointers
is highly intuitive]
Don Y <blockedofcourse@foo.invalid> wrote:
[...]
I.e., no need for
Mom BirthMotherTo Tom startdate forever
because EVERY "People" has exactly one birthmother and birthfather
(even if not known)
It gets a bit complicated with transgender relationships. I know a
young girl who has two mothers for all practical and social purposes.
One of them is her biological father - but it is totally irelevant to
her, and the rest of the world, which one that is.
I presume the problem would also arise with same-sex couples who adopted
a child. There would be different problems with a heterosexual couple
who adopt an orphan from a war zone where the parents aren't known or
with a single surviving relative who becomes the guardian of an orphaned child.
If the actual biological relationship is not important, you could use "Parent1" and "Parent2". Years ago there were official forms which used
the terminology "Parent or Guardian".
[I guess when you write code, the idea of chasing pointers
is highly intuitive]
Very complicated for sure. But what is the *purpose* of this database
to be? This will lead to what needs to be tracked and how precisely.
And to what can be elided.
On 7/8/2025 7:31 AM, Joe Gwinn wrote:
[I guess when you write code, the idea of chasing pointers
is highly intuitive]
Very complicated for sure. But what is the *purpose* of this database
to be? This will lead to what needs to be tracked and how precisely.
And to what can be elided.
My (personal) "address book" takes this form -- with the exception of the >tuples created for these one-to-many relations (IsFatherTo, IsEmployeeOf, etc.)
As such, I can "walk" through a person's "six degrees of separation" to
get the information on a particular individual.
Joe's brother's wife's mother's daughter
Joe's brother's mother-in-law's daughter
(one of) Joe's brother's sister-in-laws
Isn't this how we relate to people not in our immediate family?
Do you remember your brother's mother-in-law's full name, cold?
Or, do you step through the relationships (in your mind) and
try to drag up "handles" for each of the people you "step along"?
It was created as the result of a survey I had done of clients'
needs (for an address book). I had imagined a much smaller dataset;
how many people do YOU know (and keep track of)? I have a few hundred.
A client showed me *his* address book with *5000* entries! (almost
all of which were HIS clients -- not people with whom he interacted >frequently but, rather, people whose contact information he had to
retain: "Mr Smith called, today. You should call him back during
business hours"
[I.e., you wouldn't store *a* phone number per People as most have
multiple phone numbers; you'd store the set of numbers and how
they relate to that People.]
There are lots of details about "People"s that aren't important
(do you care about eye color? weight? height?). But, there is
nothing to prevent you from augmenting an existing set of
relations with, for example, a "Heights" relation that maps
a "People ID" to a specific "height" -- adding the field to
"People" is likely unjustified but a height can still be
associated with those People for whom it is important.
When contacting Mr Smith, you'd likely want to know how to address
him ("Hi Bob!" vs. "Hello Mr. Smith"). So, a "Greetings" relation.
Do you recall the name of the nice lady at the insurance company
who helped you sort out that billing error? Do you rely on your
memory? Or, jot notes, somewhere? (how do you access those
notes?)
Isn't this how we relate to people not in our immediate family?
Do you remember your brother's mother-in-law's full name, cold?
Or, do you step through the relationships (in your mind) and
try to drag up "handles" for each of the people you "step along"?
Although true, this is not an answer to my question.
The Swedish have a useful system: Mor is Mother and Far is Father.
MorMor is your maternal grandmother and MorFar is your paternal
grandmother, and so on, to any depth. I don't offhand know of
extensions beyond Mor and Far, but they may exist. This pattern
occurs in all Norse languages.
There is a childrens' song playing on this. I encountered it when in Stockholm in the 1970s, when the children in a nearby park were
singing it in chorus with gusto.
It was created as the result of a survey I had done of clients'
needs (for an address book). I had imagined a much smaller dataset;
how many people do YOU know (and keep track of)? I have a few hundred.
A client showed me *his* address book with *5000* entries! (almost
all of which were HIS clients -- not people with whom he interacted
frequently but, rather, people whose contact information he had to
retain: "Mr Smith called, today. You should call him back during
business hours"
[I.e., you wouldn't store *a* phone number per People as most have
multiple phone numbers; you'd store the set of numbers and how
they relate to that People.]
There are lots of details about "People"s that aren't important
(do you care about eye color? weight? height?). But, there is
nothing to prevent you from augmenting an existing set of
relations with, for example, a "Heights" relation that maps
a "People ID" to a specific "height" -- adding the field to
"People" is likely unjustified but a height can still be
associated with those People for whom it is important.
Again, all determined by intent, not technology.
When contacting Mr Smith, you'd likely want to know how to address
him ("Hi Bob!" vs. "Hello Mr. Smith"). So, a "Greetings" relation.
Do you recall the name of the nice lady at the insurance company
who helped you sort out that billing error? Do you rely on your
memory? Or, jot notes, somewhere? (how do you access those
notes?)
By date.
The bottom line is Focus!
Joe
On 7/8/2025 10:59 AM, Joe Gwinn wrote:
Isn't this how we relate to people not in our immediate family?
Do you remember your brother's mother-in-law's full name, cold?
Or, do you step through the relationships (in your mind) and
try to drag up "handles" for each of the people you "step along"?
Although true, this is not an answer to my question.
The Swedish have a useful system: Mor is Mother and Far is Father.
MorMor is your maternal grandmother and MorFar is your paternal
grandfather, and so on, to any depth. I don't offhand know of
extensions beyond Mor and Far, but they may exist. This pattern
occurs in all Norse languages.
What happens when your *original* grandmother divorces her spouse.
He remarries. What is HIS spouse called? What is the original
grandmother called?
More importantly (and the purpose of organizing the data the way I have),
how do you FIND these people -- especially when you have to deal with
people other than your immediate family? How do you find the name of
your neighbor's spouse? Father? NayFar?? *Which* "Nay"?
There is a childrens' song playing on this. I encountered it when in
Stockholm in the 1970s, when the children in a nearby park were
singing it in chorus with gusto.
It was created as the result of a survey I had done of clients'
needs (for an address book). I had imagined a much smaller dataset;
how many people do YOU know (and keep track of)? I have a few hundred.
A client showed me *his* address book with *5000* entries! (almost
all of which were HIS clients -- not people with whom he interacted
frequently but, rather, people whose contact information he had to
retain: "Mr Smith called, today. You should call him back during
business hours"
[I.e., you wouldn't store *a* phone number per People as most have
multiple phone numbers; you'd store the set of numbers and how
they relate to that People.]
There are lots of details about "People"s that aren't important
(do you care about eye color? weight? height?). But, there is
nothing to prevent you from augmenting an existing set of
relations with, for example, a "Heights" relation that maps
a "People ID" to a specific "height" -- adding the field to
"People" is likely unjustified but a height can still be
associated with those People for whom it is important.
Again, all determined by intent, not technology.
Technology should mirror how we process and access information.
We don't write names and addresses on scraps of paper and toss
them in a large box -- because that would be a horrid way of
retrieving that information.
To a zeroth order, we put names in alphabetical order. (by first
name? last name? what happens to those folks whose last names
are unknown? Or, FIRST names (what's the first name of your
priest/rabbi)?
You likely don't know the exact date-of-birth of most of the people
you know. Yet, if you were told that today was Bob's birthday,
you *might* want to make a note of "July 8" -- even if you don't know
the YEAR. Or, that Mary's birthday is some time in August.
How do you record these data? More scraps of paper?
Each month, I prepare greeting cards for the people I know who
have "significant days" (birthday, anniversary, etc.) in the
coming month. I may not know a specific date (happened this
month -- but, my card arrived early and I was TOLD "but my
birthday isn't until the 23rd"... now I can add the day-of-month
to the name-of-month I had stored.
I may want to recall the date a friend lost her daughter. With
"scraps of paper", I can make a note of that. But, nothing
other than my memory will allow me to even know that datum exists!
We use technology to leverage our abilities. "What significant
things are happening THIS month?"
When contacting Mr Smith, you'd likely want to know how to address
him ("Hi Bob!" vs. "Hello Mr. Smith"). So, a "Greetings" relation.
Do you recall the name of the nice lady at the insurance company
who helped you sort out that billing error? Do you rely on your
memory? Or, jot notes, somewhere? (how do you access those
notes?)
By date.
So, you remember that some particular thing happened on some
particular date? WHEN did you have that billing problem? Was
it this past year? The year before? Was it THIS company?
Or, some other?
If you leverage technology to store these "associations" for
you, then you can leverage it to recall them, as well. E.g.,
"Gee, I've made a point of storing 'Betty' in my address
book with no other information than the fact that she works
for CompanyX -- and, a note about some sort of billing issue
that I may not recall, presently. But, given that I made a point
of recording her contact information, maybe she's a good place
to start resolving this issue? Likely at least as good as
cold-calling their 'support' folks and talking to Rajig..."
The bottom line is Focus!
There are lots of details about "People"s that aren't important
(do you care about eye color? weight? height?). But, there is
nothing to prevent you from augmenting an existing set of
relations with, for example, a "Heights" relation that maps
a "People ID" to a specific "height" -- adding the field to
"People" is likely unjustified but a height can still be
associated with those People for whom it is important.
Again, all determined by intent, not technology.
Technology should mirror how we process and access information.
But be no better?
We don't write names and addresses on scraps of paper and toss
them in a large box -- because that would be a horrid way of
retrieving that information.
Lots of people do just that. It works so long as their memory holds
up.
I had a co-worker whose office was stuffed with teetering piles of
paper articles and reports. Looked hopeless, but if you asked for
something, he would go to one pile, and pull the requested item from somewhere deep in the pile. Never searched, never missed.
To a zeroth order, we put names in alphabetical order. (by first
name? last name? what happens to those folks whose last names
are unknown? Or, FIRST names (what's the first name of your
priest/rabbi)?
Depends on purpose. Phone books in Iceland are organized by first
name, profession, last name, because there are too few unique last
names to be useful.
When contacting Mr Smith, you'd likely want to know how to address
him ("Hi Bob!" vs. "Hello Mr. Smith"). So, a "Greetings" relation.
Do you recall the name of the nice lady at the insurance company
who helped you sort out that billing error? Do you rely on your
memory? Or, jot notes, somewhere? (how do you access those
notes?)
By date.
So, you remember that some particular thing happened on some
particular date? WHEN did you have that billing problem? Was
it this past year? The year before? Was it THIS company?
Or, some other?
To be precise, it's the old filing system used by secretaries back in
the day of file cabinets. For each major entity dealt with there was
a section, within which it was by accession date. If the entity got
too big, subsections would be created, and so on. There was always an uncatorgized section in date order.
Libraries used a similar system, where reports et al were assigned a
number in accession order, and the card file was populated by subject, author, and field cards.
How best to organize information was worked out long before computers
were invented, and many systems evolved, each for a specific purpose
and field. Modern computers actually have little to add to that
except speed and capacity.
If you leverage technology to store these "associations" for
you, then you can leverage it to recall them, as well. E.g.,
"Gee, I've made a point of storing 'Betty' in my address
book with no other information than the fact that she works
for CompanyX -- and, a note about some sort of billing issue
that I may not recall, presently. But, given that I made a point
of recording her contact information, maybe she's a good place
to start resolving this issue? Likely at least as good as
cold-calling their 'support' folks and talking to Rajig..."
The bottom line is Focus!
Which has not yet happened. What exactly are you trying to
accomplish? Don't tell me how - too early in the discussion.
We don't write names and addresses on scraps of paper and toss
them in a large box --
Don Y <blockedofcourse@foo.invalid> wrote:
[...]
We don't write names and addresses on scraps of paper and toss
them in a large box --
Oh?
Don Y <blockedofcourse@foo.invalid> wrote:
[...]
We don't write names and addresses on scraps of paper and toss
them in a large box --
Oh?
There are lots of details about "People"s that aren't important
(do you care about eye color? weight? height?). But, there is
nothing to prevent you from augmenting an existing set of
relations with, for example, a "Heights" relation that maps
a "People ID" to a specific "height" -- adding the field to
"People" is likely unjustified but a height can still be
associated with those People for whom it is important.
Again, all determined by intent, not technology.
Technology should mirror how we process and access information.
But be no better?
*You* have to be able to access YOUR data. How do you tell an
agent what data you are looking for? We (as humans) tend to
encode meaning in the relationships that we have to the data.
If you want your secretary (or any other agent) to place a call
to a particular someone, MUST you have that person's full (and
unique!) name in order for her to carry out your wish? If
you said "Get me Bob at Acme Metals", would she have to look through
your Rolodex for all Bob's? Or, all Acme Metals entries?
Would she know -- once she got him on the line -- to remind
you to congratulate him on his recent 25th wedding anniversary?
And, inquire as to what they did to celebrate it? Or, to
prompt you that his kids names are Alpha, Beta and Gamma -- and
that Beta is likely just graduating from college "about now"?
If you had a perfect (unerring and unaging) memory, you would
recall these DATA on your own and use them as you deemed
appropriate.
Yvonne called, a few days ago. Before I picked up the phone,
I knew it was her and that her birthday was in the upcoming week.
So, instead of "Hello", I answered "Bon anniversaire!" pleasing
her by *remembering* her birthday AND greeting her in her
native tongue.
We don't write names and addresses on scraps of paper and toss
them in a large box -- because that would be a horrid way of
retrieving that information.
Lots of people do just that. It works so long as their memory holds
up.
But memories DON'T hold up. So, people lose information -- or access to
it -- particularly as they age and the amount of information increases.
I had a co-worker whose office was stuffed with teetering piles of
paper articles and reports. Looked hopeless, but if you asked for
something, he would go to one pile, and pull the requested item from
somewhere deep in the pile. Never searched, never missed.
I hadn't lived "at home" in some 30 years. On one visit, I
noticed the garage door wasn't working. Bringing up the subject as
I walked in the door, my father ranted about "your mother" having
misplaced the paperwork for the door so he didn't know what part
to order.
I walked to the refrigerator and reached into the cabinets *above*
(no way my mother could reach them!) and pulled out the paperwork.
Thus, aborting that "rant". Neither of them -- living in the
house -- could remember that the paperwork was there (I have no
idea WHY it ended up there!) yet I was able to recall it in a
heartbeat.
Now, ask me where I left my tape rule...
To a zeroth order, we put names in alphabetical order. (by first
name? last name? what happens to those folks whose last names
are unknown? Or, FIRST names (what's the first name of your
priest/rabbi)?
Depends on purpose. Phone books in Iceland are organized by first
name, profession, last name, because there are too few unique last
names to be useful.
You would likely STILL have your own "address book" containing the
names and other information of those persons important to you.
My mother kept the phone numbers of the neighbors on a slip of
paper tacked to a corkboard by the phone. She used them often
enough that she didn't want to even bother looking in the
abbreviated phone book she kept.
"Muriel and Gene" would mean nothing to anyone else reading it.
And "Doctor" was NOT our doctor!
When contacting Mr Smith, you'd likely want to know how to address
him ("Hi Bob!" vs. "Hello Mr. Smith"). So, a "Greetings" relation.
Do you recall the name of the nice lady at the insurance company
who helped you sort out that billing error? Do you rely on your
memory? Or, jot notes, somewhere? (how do you access those
notes?)
By date.
So, you remember that some particular thing happened on some
particular date? WHEN did you have that billing problem? Was
it this past year? The year before? Was it THIS company?
Or, some other?
To be precise, it's the old filing system used by secretaries back in
the day of file cabinets. For each major entity dealt with there was
a section, within which it was by accession date. If the entity got
too big, subsections would be created, and so on. There was always an
uncatorgized section in date order.
And people manually trudging through it WITH KNOWLEDGE OF THAT ENCODING >PROCESS.
Libraries used a similar system, where reports et al were assigned a
number in accession order, and the card file was populated by subject,
author, and field cards.
How best to organize information was worked out long before computers
were invented, and many systems evolved, each for a specific purpose
and field. Modern computers actually have little to add to that
except speed and capacity.
People -- individuals -- don't lump their interactions in "large paper files >organized by date". Because that's not how they THINK of that information. >List all of the neighbors by date they moved into the neighborhood?
List friends by age?
If you leverage technology to store these "associations" for
you, then you can leverage it to recall them, as well. E.g.,
"Gee, I've made a point of storing 'Betty' in my address
book with no other information than the fact that she works
for CompanyX -- and, a note about some sort of billing issue
that I may not recall, presently. But, given that I made a point
of recording her contact information, maybe she's a good place
to start resolving this issue? Likely at least as good as
cold-calling their 'support' folks and talking to Rajig..."
The bottom line is Focus!
Which has not yet happened. What exactly are you trying to
accomplish? Don't tell me how - too early in the discussion.
I am trying to impart *meaning* to "data" such that an agent
can use the same sort of reasoning that *I* would to access
that data.
If "James" phones, announcing his NAME would tell me nothing;
his last name differs from that of his mother. Annotating
his name with "Diana's son" makes the information useful to me.
If *you* answered the phone, for me -- and had access to the
names of all of my contacts -- what value could you add in
announcing the caller to me? "Who the f*ck is James?"
But, an agent with access to the data AND THE RELATIONSHIPS
BETWEEN THEM can extract additional information to add value.
But, an agent with access to the data AND THE RELATIONSHIPS
BETWEEN THEM can extract additional information to add value.
I think we've exhausted this SED thread, so I'll stop.
=====================================
But I did recall a key to the larger issue. There are lots of ways to organize library indexes. The Savant of such things, Shiyali
Ramamrith Ranganathan, worked out the details in the 1930s, in India, publishing in English. He spent his entire career on this issue.
.<https://en.wikipedia.org/wiki/S._R._Ranganathan>
On 7/9/2025 11:40 AM, Joe Gwinn wrote:
But, an agent with access to the data AND THE RELATIONSHIPS
BETWEEN THEM can extract additional information to add value.
I think we've exhausted this SED thread, so I'll stop.
=====================================
But I did recall a key to the larger issue. There are lots of ways to
organize library indexes. The Savant of such things, Shiyali
Ramamrith Ranganathan, worked out the details in the 1930s, in India,
publishing in English. He spent his entire career on this issue.
.<https://en.wikipedia.org/wiki/S._R._Ranganathan>
You're not trying to organize a library index. You're trying to imbue
data with *meaning* that another agency can understand.
If some ill has befallen you and I can't get in touch with your
"emergency contact", should I give up? Perhaps if I knew which
of the names in your phone were RELATIVES I might give one of them
a try...
Which of the 7 doctors in my phone should be called if I was
having a dental problem? Medical problem? What about those
"doctors" who have nothing to do with medicine?? Which are
my *current* providers vs. records of PREVIOUS (now retired!)
providers?
How do you (another agency) synthesize this information without
access to my grey matter?
On Wed, 9 Jul 2025 11:56:43 -0700, Don Y <blockedofcourse@foo.invalid>
wrote:
On 7/9/2025 11:40 AM, Joe Gwinn wrote:
But, an agent with access to the data AND THE RELATIONSHIPS
BETWEEN THEM can extract additional information to add value.
I think we've exhausted this SED thread, so I'll stop.
=====================================
But I did recall a key to the larger issue. There are lots of ways to
organize library indexes. The Savant of such things, Shiyali
Ramamrith Ranganathan, worked out the details in the 1930s, in India,
publishing in English. He spent his entire career on this issue.
.<https://en.wikipedia.org/wiki/S._R._Ranganathan>
You're not trying to organize a library index. You're trying to imbue
data with *meaning* that another agency can understand.
If some ill has befallen you and I can't get in touch with your
"emergency contact", should I give up? Perhaps if I knew which
of the names in your phone were RELATIVES I might give one of them
a try...
Which of the 7 doctors in my phone should be called if I was
having a dental problem? Medical problem? What about those
"doctors" who have nothing to do with medicine?? Which are
my *current* providers vs. records of PREVIOUS (now retired!)
providers?
How do you (another agency) synthesize this information without
access to my grey matter?
You are not the first to think of such things, by orders of magnitude.
Another place to look are the various Secretary's "Handbook to Filing Systems". Google will bring up lots of examples.
I was deep into such issues back in the days when DEC VAX/VMS was
being invented. DEC eventually published a book on VAX/VMS Internals
and Data Structures:
.<https://www.amazon.com/VAX-VMS-Internals-Data-Structures/dp/1555580599>
It cited two books that were very influential. The most important is:
"Simon_Herbert_A_The_Sciences_of_the_Artificial_3rd_ed" - The
Architecture of Complexity. MIT Press, still in print.
The other, regarding file system organization,was Ranganathan.
I don't recall where I got the Secretary's Handbook. It may have been
my Department Secretary of that day; these no longer exist.
Dig in if you wish. Computers have changed nothing essential.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (3 / 13) |
| Uptime: | 29:56:59 |
| Calls: | 10,391 |
| Calls today: | 2 |
| Files: | 14,064 |
| Messages: | 6,417,091 |