Published Subject Indicators for Scripted Aspects

PSI Metadata

1. SubKind, a numeric ID for the aspect being declared.
2. Cardinality of its value, an ID at cardinality
3. Update Policy on its value, an ID at updating
4. Domain shows (per these rules) what subjects the aspect can modify
5. Range of its value(s), per rules that depend on its SubKind:
   • for a PropType, this denotes legal composition of a String
   • for a RoleType, it gives legal class(es) for a rolePlayer
6. Inheritance Policy for aspect values not yet set, per Data Inheritance

• for a PropType, a String which could fill it in the given topic
• for a RoleType, a Topic which could fill it in the given association

Such scripts are key parts of a TM's ontology under WORDS, which help to define (i.e., configure) the abstract system behavior for each Aspect Type.

This has many exotic use cases. One simple example would be to find the value of some resourceRef by normal means, then read in that resource as a stream, and locally process it to compute the final value returned by the script.

A more complex (and useful) example might combine the above script with a real time clock and a separate scheduler. It builds a nightly report of selected content or changes. At other times (to stay nimble), it returns the last such (cached) value.

This is a very general spec, as open as the registry of predicates. Validation will return the first listed predicate to fail in each case. Such logic (often experimental) may become part of a TMCL spec, or augment it.

Details of the substring formats and semantics are forthcoming separately. This is an advanced feature, whose uses seem highly application-specific.

For a RoleType in such a situation, WORDS uses no inheritance of the value, but instead it looks for a script that can return a Default Value. That script may be inherited, but not the default topic itself.

This PSI types ResourceData holding comma-separated specs that can configure exceptions to such inheritance rules. Details are in separate forthcoming specs. They involve such variations as:

• enabling inheritance for a RoleType, under special-case rules
• adding criteria that enables support of multiple inheritence paths
• adding logic to let inheritance gather and combine multiple values
• shifting inheritance from classes to a new path (e.g., containment)

No matter what rules get configured above, they can be designated for each aspect by the single character 'n' (iNheritance), whereas normal lookup rules for a value can be summarized by the single character 'L' (Lookup). Using such notation, a full list of primative ways to get an aspect value might be:

• L = look it up normally, nothing unusual
• n = inherit the value as is described above
• N = as in n, plus locally saving any value found
• d = find and use the declared Default Value
• D = as in d, plus locally saving any value found
• f = find and use the declared Functional Value
• F = as in f, plus locally saving any value found

The codes above can be combined into an optional script-like Inheritance Policy subString for the Aspect Type, as in these bolded examples:

• LF = try L, but if nothing is found, then try F
• Lf = same as above, but do not save any functional value
• Lfd = same as above, plus if f fails, get a default value
• L = just do a lookup; do nothing else exotic
• f = always compute the needed functional value
• Ln = try L, and if no value, try inheriting one
• LD = try L. If none, seek and save a default value

If such a policy is present, it will program WORDS to return a value of the aspect by using the indicated pattern of calls. If the policy is omitted from the Aspect Type, WORDS will use these default policies:

• Ln for a PropType (inherit whenever needed along one-parent class lines)
• LD for a RoleType (default - as from a template - and save the result)