[om-list] Data Model

[Luke Call]

Sorry for the delay; responses below. -Luke

Mark Butler wrote:

> ....
> I have had second thoughts about this - for query purposes we want all
> relationship attribute values to be in the same table.  So I propose that we
> move ATTRIBUTE_VERSION to be a new table called REL_VALUE (short for
> relationship value).

Thanks for the work. I think we'll continue to learn more about what we 
want in the data model over time & w/ experience.

 
> ...
> This table would be the most critical data table in the whole system.  I
> propose that we use a structure like the following:
> 
> -- THIS_ID 		Primary Key (inherited - aka ATTRIBUTE_VALUE_ID)
> -- 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.

> -- RELATIONSHIP_ID	Relationship this value is for
> -- PARENT_ID		Entity / relationship this attribute applies to
> --			(Same as ATTRIBUTE.PARENT_ID)
> --
> -- SOURCE_ID 		Source Entity ID - Origin for relationship
> --			Null allowed here - means "empty space"
> --
> -- DEST_ID  		Destination Entity ID - Destination for relationship
> --
> -- DOMAIN_ID		Domain for this relationship value
> --                      A domain is a combination of unit and basis
> --
> -- SCHEMA_ID		Schema for this relationship value
> --			A schema is an entity or a work thereof that
> --			asserts a particular world view
> --
> -- 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?

> -- STRING_VALUE		String value
> -- SCALAR_VALUE		Scalar value
> -- VECTOR_VALUE		Vector value
> -- MATRIX_VALUE		Matrix value

Would it be more efficient use of space to break these four value fields 
into related tables, since 3 out of four of these will be blank on any 
given record?

Also, how do we distinguish between a relationship and an actual value? 
Some values aren't relationships, right? (Unless I've just forgotten 
something.)

 
> Now I completely skipped the relationship and relationship attribute tables
> because I do not think we need to instantiate those objects unless we are
> going to use them as one of the terminal entities in a relationship. Any
> objections?

No objections from me.

 
> 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.

What about the use of NULL as "no information known"? What would we use 
to indicate "no information"?

Luke