I didn't take into account an entire specification.  A typical
implementation of one person living at different places, not taking into
account past addresses might be modeled as:

PEOPLE(id) = { (place, start date, end date)* }  where date is month/day
only if it is an annual date and is month/day/year or as
PEOPLE(id) = { (place, start date, end date, annual start, annual end)* }

No matter how you cut it, you are mapping something to something else.

It is not a matter of being two abstract but the fact that with computers we
are just talking about applying functions (processing) to objects.  If we
want to go into depth on objects that are relations and are not functions
for some particular application, it is fine to define an object that is a
relation, but I have never seen any need for that with retrievable stored
data since by nature of it being accessible, it almost always (?can you
think of cases this is not true) can be easily represented as a function
operating on a key or reference id of some sort to retrieve the data.

While there are many types of propositions that are difficult to encode in
an RDBMS and easy to encode in implementations of the Nelson-Pick model.
These include, but are not limited to, multivalued attributes.  How often to
those implementing a relational model have to think hard about whether to
pull out an attribute because it is possible or likely that in the future
one might want to have more than one of 'these' for this entity.  Even
today, with cell phones having been out for over a decade, I've had someone
tell me on the phone that their system permitted one phone number for home
and one for business, but didn't have a spot for an additional phone number.
This is highly unlikely in a system where cardinality of attribute values
can be changed with the blink of an eye from 1 to a variable (not fixed
number) "many".

So, where I have seen no instances that cannot be modeled equally well with
functions as with relations, I have seen many times when a flexible function
is a much better way to model the propositions.

Take some example propositions:

Hope has a cat named Geneva and a dog named Rugby.
Shanna has no pets, but did have a dog named Monte who died in 2002.

Given only these statements, I might immediately come up with something like
this:

a function named PEOPLE and the assignment of an arbitrary (or sequentially
assigned) id for each person
PEOPLE("12345") = { "Hope", { ("cat", "Geneva", NULL) , ("dog", "Rugby",
NULL)} }
PEOPLE("12346") = ( "Shanna", { ("dog", "Monte", "2002") } }

I've modeled this with a single function and I think I can even leave out
telling you the metadata (although I wouldn't typically) because this so
closely models the way we speak and think about these propositions.  Now
take these same propositions and model them with a relational model.  This
would require at least two relations and the act of splitting up these
propositions into two separate propositions adds to the complexity for both
the developer and unfortunately typically also for the end-user trying to do
queriest, without any noticable gains.

Or am I wrong?  Thanks.  --dawn