Naive implementation of TMRM-style ontological commitments

Requirement: Represent sets of TMRM property value pairs relationally in highly normalized fashion. Add in CRU (non D) tracking columns later.

Advantages of using Drupal as the platform: Large, vibrant open-source community; user and administrative interfaces don’t don’t need to be constructed.

Disadvantages of using Drupal: Store is SQL. (However, nothing prevents the SQL database from being used for local storage only, and connected—say, through an agent-driven tuple space—with other stores through the six degrees of separation principle. Also, have yet to confront performance issues with highly normalized tables.

Data entry syntax perhaps an inline microformat something like this, where this is what appears to the user. (The Drupal filter can parse it out into XHTML spans with classes.)

0. {affair {lover:<u>Heloise</u>}<u> and </u>{lover:<u>Abelard</u>}} <u>are one of the most celebrated couples of all time.</u>
                                   
1. {marriage{husband:<u>John</u>}<u> is </u>{wife:<u>Mary</u>}}<u>’s husband.</u>

Note that it is possible to achieve results that benefit users with properties only, and with untyped proxies only. The degree of markup value added should be not be prescribed for the user, but there should be visible and immediate benefits to the user when value is added, immediately upon pressing the Submit button.

So all the following should work as data entry:
0. {lover:Heloise} and {lover:Abelard} are one of the most celebrated couples of all time.

1. {{lover:Heloise} and {lover:Abelard}} are one of the most celebrated couples of all time.

QUERY: Are the brackets needed? If we restrict the labels to words without spaces, this would work:

0. lover:<u>Heloise  and </u>lover:<u>Abelard are one of the most celebrated couples of all time. </u>

1. {lover:<u>Heloise and </u>lover:<u>Abelard</u>}<u> are one of the most celebrated couples of all time. </u>

2. {affair lover:<u>Heloise and </u>lover:<u>Abelard</u>}<u> are one of the most celebrated couples of all time. </u>
                                   
3. {marriage{husband:<u>John</u>}<u> is </u>{wife:<u>Mary</u>}}’s husband.

Draft of tables:

+-----+----------+
| datatypes      |
+-----+----------+
| nid | datatype |
+-----+----------+
| 1   | string   |
+-----+----------+

Actually, it’s more likely that each datatype will have its own table; GIS data to be processed by GIS functions, etc., etc. That’s why there’s a tuple space, since each database if normalized will have different, though overlapping, sets of dataypes (and why not?)

+-------+----------+----------+
|  The set of all values V    |
+-------+----------+----------+
| vid   | data     | datatype |
+-------+----------+----------+
|  0    | type     |    1     |
|  1    | heloise  |    1     |
|  2    | abelard  |    1     |
|  3    | john     |    1     |
|  4    | mary     |    1     |
|  5    | lover    |    1     |
|  6    | husband  |    1     |
|  7    | wife     |    1     |
|  8    | affair   |    1     |
|  9    | marriage |    1     |
+-------+----------+----------+
* By convention, vid 0 is type

+-------+---------------------+
| The set of all Labels L     |
+-------+---------------------+
| lid   | vid                 |
+-------+---------------------+ 
| 0     | 0                   |  type   
| 1     | 5                   |  lover  
| 2     | 6                   |  husband
| 3     | 7                   |  wife
+-------+---------------------+
* By convention, lid 0 is type

+-----+-----+-----------------+
| The set of all properties P |
+-----+-----+-----------------+
| pid | lid | vid             |
+-----+-----+-----------------+           
| 0   |  0  |   8             |  type     affair   
| 1   |  0  |   9             |  type     marriage
| 2   |  1  |   1             |  lover    heloise
| 3   |  1  |   2             |  lover    abelard
| 4   |  2  |   3             |  husband  john
| 5   |  3  |   4             |  wife     mary
+-----+-----+-----------------+           

+-----+-----+-----------------+
| Proxy to property           |
+-----+-----+-----------------+
| nid   xid   pid             |
+-----+-----+-----------------+
| 0   |  0  |  0              | type     affair 
| 1   |  0  |  2              | lover    heloise
| 2   |  0  |  3              | lover    abelard
| 3   |  1  |  1              | type     marriage
| 4   |  1  |  4              | husband  john
| 5   |  1  |  5              | wife     mary
+-----+-----+-----------------+

+-----------------------------+
| The set of all proxies M    |
+-----------------------------+
| xid                         |
+-----------------------------+
| 0                           |
| 1                           |
+-----------------------------+

Given that all the values are unique, are all the IDs needed? (Or will values be stemmed, for example?

There will also need to be a table of equivalences for merging, and a table of subject sameness rules. The equivalence table would have columns for two XIDs that are the same, and a refererence to the subject sameness rule applied.