[om-list] Data Model

[Luke Call]

Comments below....

Mark Butler wrote:

> Luke Call wrote:
>>> -- STANDARD_NAME              Standard name (inherited)
>> 
>> When we develop contexts so that anything can have 0-n names, we will
>> probably want to move this; it's probably a good place for now.
> 
> STANDARD_NAME is pretty much for debugging purposes - an actual name is an
> attribute of a relationship between a schema and an entity. 

OK, and we use a "default schema" at first--so we are leaving the schema 
problem to be fully implemented at a slightly later time, right?

 
 
>>> -- CLAIM_YEAR         Year schema first asserted this value (fractional)
>>> -- VALUE_YEAR         Value asserted to be valid for this year (fractional)
>>> --                    Null if claim is for all time
>> Wouldn't a value be good for a span of time

> That would represent a constant attribute for a finite length of time, which
> is rather uncommon in the natural world.  What I suggest instead is that we
> insert another record with the same value at a later time, and then represent
> the proposed interpolation (linear, polynomial, etc.) as some sort of meta
> theory about how the value changes through time.  Alternatively we could add
> time derivative attributes to this table, but I think that is unnecessarily
> constraining.

> The reason not to have VALUE_START and VALUE_END is that generally speaking
> VALUE_END is the same as the VALUE_START of the next sample, which is
> redundant and causes update anomalies.


OK, so how do you use VALUE_YEAR? Wouldn't there be possibly multiple 
instances of it?


 > ....

> variable length fields take very little space
> when empty / null - the storage overhead of separate rows, especially in
> Postgres, is much greater.  The join overhead is a much worse consideration. 

That is good info; I didn't realize that about the space for all those 
types.


>> Also, how do we distinguish between a relationship and an actual value?
>> Some values aren't relationships, right? (Unless I've just forgotten
>> something.)
> 
> 
> Values aren't relationships, but you can make a strong case that all
> attributes are - otherwise they would be meaningless. e.g. "This is good" -
> compared to what? If not better than something, than we can do no better than
> interpret the attribute statement as saying "this is good relative to nothing"
> or "this is better than nothing".   Alternatively, one could make "good" into
> an entity and draw a relationship that way.
> 
> Basically, I think you can except as fundamental the idea that any statement
> is meaningless unless it proposes a relationship between at least two
> entities, provided that we admit "nothing" to quasi-entity status so that we
> can represent ideas like "This exists" and "It weighs 100 lbs" as relations.

I guess I still am not certain on the meaning of the tables. In our 
diagram, based on my understanding of your email, I've crossed out 
"relationship" and "relationship attribute", and replaced "attribute 
version" with "rel_value". So if a building is 30' tall, I would have 
building in the entity table, connected (at first I presume) to the 
"default schema" record in the schema table, and to an attribute row 
(that has what columns?), which is itself related to a rel_value table 
record(s) that have recorded 30' (units etc we can ignore for the moment 
I suppose). How do I know that 30 is a value, rather than a 
relationship? Or you're saying I don't care--it doesn't matter. So if it 
is specifically something we commonly think of as a relationship, say 
between two individuals, how would the specific data in the rows reflect 
that? I think a complete simple example will help.

 
>>> Finally, I propose that we treat NULL as the entity id for "nothing", i.e. the 
>>> entity that does not exist.  This is useful for a class of relationships, like
>>> mass / energy that do not relate to any convenient real entity.  In such cases
>>> SOURCE_ID would be null, and dest_id would be the entity id of the entity we
>>> are describing.

> Well unfortunately SQL has rather awkward three-valued logic, so for any given
> table column, we have to choose an interpretation for NULL.  This one happens
> to be the most convenient.
> If I were designing a language, I would have two special values:
> NIL  - value does not exist  
> NULL - value is not known

So you're saying for the entity table we choose that NULL means 
"nothing", and we could conceivably need to use the other meaning 
("unknown") for NULL on other columns later, right?

Thanks again. Let me know when you have more table layouts done; I want 
to think about how I'd lay out data from objects in them. (yesssssss......)

Best,
Luke