[om-list] Data Model

[Mark Butler]

I did some work on a Postgres data model the other day and have made some
reasonable progress.  In our last meeting we had Attribute and Relationship
Attribute as two separate tables even though all attributes are actually
relationship attributes.

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

A relationship value is equivalent, roughly speaking, to a single dimension of
what Tom calls a "noetic vector", or a vector in idea space.  The main
difference is that I use the same table to store multiple versions of the same
value, according to schema (world view), date of claim, and date of value.

Schema dependency allows us to store different claims or beliefs about the
same relationship.  Claim date dependency allows us to easily model the
evolution of those beliefs through time.  Value date dependency allows the
relationship values to be time dependent, as most real world relationships are
- (e.g. the position vector of a moving object).

This table would be the most critical data table in the whole system.  I
propose that we use a structure like the following:

--
-- rel_value.sql
--
-- relationship value Table 
--
-- A value for an attribute of an entity relationship 
--
-- $Id: rel_value.sql,v 1.1 2001/04/10 07:25:57 model Exp $
--
-- 09 APR 2001   Created 	mdb
--
-- THIS_ID 		Primary Key (inherited - aka ATTRIBUTE_VALUE_ID)
-- STANDARD_NAME       	Standard name (inherited)
-- 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
--
-- STRING_VALUE		String value
-- SCALAR_VALUE		Scalar value
-- VECTOR_VALUE		Vector value
-- MATRIX_VALUE		Matrix value
--
--
--

CREATE TABLE REL_VALUE
(
 SOURCE_ID  		VARCHAR(20),
 DEST_ID    		VARCHAR(20)  	NOT NULL,
 DOMAIN_ID		VARCHAR(20)	NOT NULL,
 SCHEMA_ID		VARCHAR(20)	NOT NULL,
 CLAIM_YEAR,     	FLOAT,     
 VALUE_YEAR,     	FLOAT,     
 STRING_VALUE		TEXT,
 SCALAR_VALUE		FLOAT,
 VECTOR_VALUE		FLOAT[],
 MATRIX_VALUE		FLOAT[][]
)
INHERITS (ENTITY);

A relationship value is a single version of a partial dimensional projection
of a relationship extending from a source entity to a destination entity. The
relationship is explicitly polarized, so conventions must be used to identify
which entity should be the source and which entity should be the destination. 

A domain is a simple combination of a unit of measurement and a vector basis
that gives polarity or alignment to that measurement.

A schema is an entity that is capable of believing something or representing a
collection of beliefs (e.g. a person or a book)

I used a 64 bit floating point type to represent the claim date and the value
date as a fractional year. The reason for this is that the date type only
extends to 4713 BC/AD, and we probably want to model much larger dates.  With
a 53 bit mantissa, we can get sub-second accuracy for millions of years.

The remaining four columns allow attributes to be character strings, numbers,
vectors, or matrices.

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?

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.

- Mark