Enumerated Aspect Data Types for WORDS


This 12/1 table summarizes Lexikos' views after a long debate on facet types

Feature \ Model
 Model 1
 Model 2A
 Model 2B Model T
Definition
 PSI-page PSI-page PSI-page "Natural hierarchy"
Range
tree/list/set Same as 1
 Same as 1 Unknown yet
Constraints cardinality
+ domain		 Same as model 1, plus  any formally declared in propType
topic 		Like 2A, plus overrides and extensions possible on  each facet individually? Unknown yet, but  (?) could be declared in roleType
topic
Linkage
 PSI for value is hardwired propType of occurrence 
Aspect topic (cited as the propType of occurrence)  is flagged by a model 0 tag
Like 2A Aspect topic (cited as roleType) is tagged via a model 0 tag
Implementation
 only a PSI-page  PSI-page  + Aspect topic tagged with dimensions as outlined above
 Like 2A, plus optional topic for each node in the PSI-set holding extra node-specific data
Replaces PSI-page with (TBDL) PSI-based  structure of topics and associations
Best Uses
 "nature" tags and similar, accessed via PSI hardwired into Modeler's  Java logic
 Fast version of 2B? (It can skip checking for extra data in each facet topic)
General case  WORDS type for building any MFCS
 Legacy topic hierarchies meant for use in MFCS

Release
 ASAP
 ASAP
 TBDL (=1.0?)
 Unplanned

* flagged directly or in one of its ancestors?  This is still unclear.

The table below better justifies these implementation plans

ASAP
 We need a simpler way to define PSI-trees with an include file, not unlike what is now being used in JSPs for WORDS PSIs.  Each include files could them be processed differently to create the LTM needed for a TM, as well as the equivalent PSI page itself.

The Model 2A would actually have three sub-types, for trees (the classic in MFCS) plus lists (enables limited range types useful as the basic of pull down lists) plus sets (uses TBDL with 2B?)

These Aspects, if defined soon, should give NYC everything it needs in a first cut MFCS ontology, even if the set type must be stubbed,
TBDL
 One goal here is to let the PSI-tree itself be easily rebuilt, so any set of entities (SKUs, ISBNs, Bonds, People, ...) might be managed as if they were simply facets under model 2A.

If they actually each had a topic, that would enable 2B as well, at least in the case of ALL entities having topics - the most common set.  For an org-chart uses case, this would let the boss get special treatment and scripts, yet still be one of the crowd.

A further bit of work in the Java code should enable optional topics, and this would handle the case of a set in transition (new hires, for example, in the org-chart use case).
 
Unplanned
 Model-T is so bizarrely UNdefined at this point we cannot plan it, and we do not want to because no known implementation yet exists that in general but does not require (unportable) tolog.

The hope is that auto-rebuilt PSI-trees on Model-2B, populated from entity lists, can handle dynamic cases adequately until this most complex case gets better TM-community support and definitions.