Source can be a local DB plus a query, or the URI for a
similar CSV or XML file
The aspect-lists (and order?) within each row[] must be
known in some kind of list
The format (and conversion rules, if any) for each aspect
will be stored inside it
aspect = col for a table = a class of datum, each with a known, class-wide format and meaning
to find their value(s) in any member of row[], search
occurances in row=topic
this could involve first loading the row[] member,
then converting it. (In theory,
one could also search row occurances inside some
aspect instance, but that
would be much slower for long tables, which are
rarely problematically wide)
the conversion rules for various sources could be
defined or stored here. Or
better, each source must return the data in a format
specified here, and deal
with its own conversions to & from that standard
specification. (As a service,
we could supply handy converters, potentially leased
on each aspect separately.)
situation = class of assoc, modeling sets of 2-way typed linkages
and storage treatment
the above lets all instance pairs be found for any
type of assoc. Otherwise, one must
know one instance of the pair to find the other
one inside it. (Two 1-way links - not
the same.) A situation instance MAY be also
reified. Lacking this power, it is hard to
see how a situation could become a complement.
CHECK THIS and implications later.
In a typical Data Dict, there need be no situations
modeled. But within an Inglish lexikon,
we need 'em to define the verbs and preps, and get
2-way modeling added automatically
from (e.g.), a definition and a set of (nearly)
synonymous terms, such as tags or aspects.
If each row is a topic, id-shape and typed by class=table
- its occurances (each typed by an aspect),
hold latest values. This makes a topic similar to
a row, with an ID, plus names and prop-value pairs
stored inside of occurances. For links to
other topics, we simply use a resourceRef here (instead of
a resourceData string), and have it point to the
unique ID of the other row=topic in the current TM.
EXCEPT: 2-way links might shift into a timetagged
situation, under role=aspect pairs to which both
topics would then point. This seems needed
for Inglish, which works heavily that way by design. It
is not clear that typical DBs use such links, or
care (either way) how they would be implemented. To
find the link values with this allowed approach,
each role-aspect must define its storage treatment,
or else situations simply become the declaration
that they should be used for their related aspects.