12/18 - fixed broken link in part C; indents in E.6.1; moved history to end of page

A) Entity Types - Real world things on which Creditsights tracks data

1. Company - one of the current tagging items; part of an Industry
   
2. Industry - one of the current tagging items - part of a Sector
   
3. Sector - top level nodes in a PSI-tree modeling A-2 & C-1.3.1
   
4. Country - one of the current tagging items - politically controlled region
   
5. Region - top level nodes in a PSI-tree for modeling A-4 & C-1.3.2

   ---

6. Analyst - someone who may author a report - ID = email-addr?
   
7. Report - see below - required, but subtype models too complex
8. Subject - better term than "Menu topic" (sic) - another tagging item

B) DatedResource Types - An evolving set, typically rebuilt on a recurring basis

1. several sub-types are listed under the link above, typically tagged, dated, attributed
2. some site pages are merely non-Entity types of navigation aid, neither type A nor B
   
• My Companies - list of Company links each user can self-maintain
• Weekend Reader - compilation of links to recent Articles, etc
  

C) Occurrence Types - every Type has its own needed set of these.

1. of a bond seller (Company or Country) or an aggregate-specific prototype
   
1. rating - the string(s) for stating risks in obligations of a bond seller
2. performance - under/over/market PSIs for a bond seller?
• bondScore data - links and strings that model its history, etc.
• this may also be aggregated in Sector and Regional prototypes
3. automatic "tags" come from adjustable type & whole-part hierarchies..
   
1. sectorization - says what work (industries in a PSI-tree) a company does
2. regionalization - says where a company operates or country resides
3. obligations  - PSI-tree models of where/how its bonds are sold
1. market - a debt/equity trading forum for exchanging bonds/stocks
2. currency  - market-specific designation price for a bond/stock
4. homepage - URL presenting above characteristics, relevant associations  
2. of a DatedResource - attributed to, produced by and tagged by your experts
   
1. focus - what is ostensibly discussed  - the main subject(s) analyzed
   
2. timestamp when tagged - XSD types used for strings whenever possible
3. summary - what it is as a web page: management aspects (of the type)
   
4. classification - "tags" citing homepages log several PSI-tree aspects
• searching mechanisms can be implemented in several ways
  
• implemention after modeling (but MFCS queries 100:1 faster)
  
3. of other types - mostly type specific, with PSI-enumerated values:
• administrator update groups - UI for framework; Analysts for dynamic data
• equity vrs debt instruments - probably need whole new market types
4. the constraints that Role or Occurrence Types impose on their instances
   
1. we will reuse a PSI-pattern that WORDS adapted from OWL
   
2. used as doc, constraints can greatly clarify what topics "expect"
1. domain - usually phrased as {aspect} OF {domain type(s)}
   
2. range - what it expected of the value
   
3. cardinaility - how many such values are legal
   
4. updates - by whom - UI or analysts only options
   
5. inheritance - relevant only when stated (usually from type)
6. comments - English explanations replace validation for now
   
• TMs will not validate until a full constraint language is built
  
• ... but with Template-built LTM, validation is less important
• ... as whatever is built reflects the same set of constraints
  

D)  Name Types - special-case Occurrence sub-Types conveying identity

1. topic IDs - must be unique; may vary with class-instance nature
• unique class ids in LTM best picked as controlled vocabulary
• unique instance IDs often come from the class plus a record ID
• Java time tags (new Date()) usually work when no record ID handy 
  
2. base names - often just like above, but may be multiple and/or localized
3. variant names - variations on the base name; and/or new symbol types
4. subjectAddresses - the obvious choice for all your Report instances
   
5. subjectIndicators - ideal for many types, like Analysts.  Controls merging
6. PSI - like D.5, but also defines complex type in human-readable doc
   

E) Association Types - why Topic Maps are a COMPELLING tool

Once types A and B are defined, new N-WAY relationships that link their instances can be declared after we define and constrain these types, each uniquely named so that its related roleTypes stay easy to remember.   For association types, I like regular (3p, sing) English verbs, with roleTypes as "-ER" and "-ED" inflections:

1. Basic association types for any ontology, named by roleTypes
   
• class-instance - gets idiomatic treatment in LTM
  
• class-subclass - gets idiomatic treatment in LTM
  
2. WP (whole-part) - core assoc type; should get idiomatic treatment
• whole - role type (unconstrained base type)
• part - role type (unconstrained base type)
3. Includes - (virtual) extension of WP making a Company part of its Industries
   
• includer - whole-subclass (constrained to be an Industry)
• included - part-subclass (multiple ok) must be Company or Industry
• (above can be inferred from included's Sectorization and a PSI-tree) 
4. Surrounds - (virtual) extension of WP making a Country part of its Regions
   
• surrounder  - roleType (constrained to be a Region)
• surrounded - roleType (multiple ok) must be a Country or Region
• (above can be inferred from surrounded's Regionality and a PSI-tree)
5. Registers - (virtual) extension of WP making a Company part of a Market
• registerer - roleType for a market (based on a PSI-Tree)
  
• registered - roleType for a company bond (or later, stock)
  
• currency - denotes how the registered instrument is priced in market
• (above can be inferred from registered's obligations and a PSI-tree)
  
6. ---- Above is "autotagged" UI; more links below come from Tags of Authors ----------
   
1. Authors = binary association to declare an attribution
• the authored (an analysis page) = 1: a DatedResource instance
• the author (the analyzer(s)) = N: who wrote it (or else just "CS staff")
2. Discusses = binary asociation to declare a focus (aids "autotagging")
• the discussion (analysis; the page) = 1: the web page instance
• the discussed (the analyzed; the focus) = N: an instance of entity type
3. References - associations to "tag" a DatedResource with other Entity IDs
   
• referencer - roleType for a DatedResource - any sub-type
  
• referenced - roleType for a Company, Industry, Subject,...

F) Role Types - these are needed mostly to constrain associations

The occurrence set for each RoleType can be expanded into the virtual parts below, or compressed into a packed, aspect-specific string format.  The expansion pattern looks like examples (F.1-2), but the packed strings may be easier to process in a validation or templating system.

1. Referencer (role within References)
   
• Range = the DatedResource instance being tagged
  
• Cardinality = exactly 1t
• Updated = by Analysts only
• Comments = will be added to Referenced's Homepage
2. Referenced (role within References)
• Range = something with a HomePage
• Cardinality = any number
• Updated = by Analysts only
• Comments = may update models of Range as a sub-task
3. (similar constraints are needed for all other Types of Roles)
• some virtual ones are defined in hierarchy module
  
• see part E for a summary of them and all the others