Hierarchies for Region-Country and Sector-Industry Characteristics
This is not in proper PSI-tree format, and not close to
complete. But it does sketch a page of PSIs that can define the
above things as a fairly modular sub-system within the ontology, which
has these parts:
- a tree of Region instances decreasing to the scale of Countries
- each parent node implicitly contains all its children (and theirs too, etc.)
- by convention, all Countries will exist only at the fringe nodes of the tree
- option: reuse the current unique Country IDs at the fringe, versus new ones
- a tree of economic Sector instances, of which Companies can become parts
- each parent node implicitly contains all its children (and theirs too, etc.)
- sectors (near root) shift toward "industries" and "sub-industries" at fringe
- option: reuse current unique Industry IDs (more ad hoc, may be less appealing)
- the resourceData types that can assign node(s) of these trees to instances:
- Regionalization of a Company or Country
- Sectorization of a Company or (sub)Industry
In each sub-tree below, the PSIs for nodes can be expressed using the
path of outline numbers leading to each node from the root.
Another format for expressing the PSI-trees is a text file. Notes follow the listings below on auto-converting that simpler format into proper PSI pages and LTM.
- Regions & Countries
- North America = includes Mexico
- United States
- Canada
- Mexico
- Central America = excludes Mexico
- Panama
- Europe
- United Kingdom
- France
- Spain
- Asia
- Pacific Rim = sub region to Asia
- Japan
- Korea
- China
- South America
- Brazil
- Argentina
- Pacifica
- Australia
- New Zealand
- Economic Sectors & Industries
- Industrial
- Transportation
- Autos
- OEM
- Suppliers
- Freight and Logistics
- Chemicals
- AeroSpace & Defense
- Consumer Goods
- Finance
- Real Estate
- Office
- Industrial
- Multifamily
- Retail
- Energy
- Utilities
- resourceData Types that relate
- Regionalization (of a Country)
- Range = PSI node ID(s) from tree 1 fringe
- special constraint applying to any Country
- must always be the Country modeled
- Cardinality = exactly 1
- Updated = by UI coders only
- Comments = denotes its physical location
- answer is all parent nodes on path
- compare to same attribute for a Company
- Regionalization (of a Company)
- Range = PSI node ID(s) from tree 1 fringe
- Cardinality = at least 1; no limit
- Updated = by Analysts only
- Comments = denotes where it operates
- answer is all nodes on path
- compare to same attribute for a Country
- Sectorization (of a Company)
- Range = PSI node ID(s) from tree 2
- special rule below also applies
- cannot cite any top-level node
- Cardinality = at least 1; no limit
- Updated = by Analysts only
- Comments = each node cited has two meanings:
- an activity for the Company (see node's parents, too)
- implied groups of similar Companies under each node
Note #1 - on treating the two trees as templates - an off line process UI Coders drive
This "navigation" stuff is expected to change very infrequently, and can be built into a new UI:
1) Both trees can be easily walked (depth-first) in reading order, with
a new topic instance being generated for each node encountered.
It will have these LTM characteristics:
- One of these classes, depending on the tree and the node position involved:
- In tree 1, a Country if at the fringe, else a Region
- In tree 2, a Sector if parent is the root, else an Industry
- A unique instance ID that can be the class name, with the node ID appended
- A PSI as indicated by the (fixed) PSI-tree URL plus the node ID
- ResourceData of all commentary after the first '=' on the node's line
- A Basename of all other text on the line (dropping the first '=' if any)
2) Each new instance can then be made part of an LTM association
between itself and its parent. These are optional, as each node's
PSI differs from its parent's only incrementally, and it may actually
be easier to process only the strings and substrings. Otherwise,
tree-specific associations are easy to infer:
- In tree 1, surrounds({parent}:surrounder, {child}:surrounded)
- In tree 2, includes({parent}:includer, {child}:included)
3) In order to simplify this process, both of the main PSI-trees above
will be maintained in a Properties file of the form ID + '=' + rest of
the line above, then read in and sorted on ID by a JSP. It will
then emit, per the latest copy of this file whenever it is displayed:
- The PSI-tree in proper format per the OASIS spec for such documents
- The LTM for all the instances (as a file saved in a tree-related folder)
Note #2 - Updating Company instances as an offline process done by Analysts
This is not UI-driven stuff. With 1,200 competing companies, it
would take a team of analysits to notice and report changes in what
they do and where, so this takes a more polished web interface.
For any defined Company instance, its Regionalization or Sectorization
can be updated by a JSP to which is posted the IDs of all the nodes in
either tree above, as a GET request on any noticed errors:
- From each leading digit posted, the JSP knows what ResourceData is to be updated
- it applies the checks cited above, after reading in the Properties file for both trees
- it returns the results to the user (in a page .Net "includes") after first..
- it dumps to a Company-specific folder a time-tagged file holding the implied LTM
- Periodically, all change files built since the last such sweep get migrated into on-line TMs
- care must be taken to replace (not just merge), the new LTM-based values
- this may best be automated as part of a global rebuild process for the TM