Published Subject Indicators for Constraint Types

PSI Metadata

The PSIs for Cardinality, Update Policy, Domain and Range are special cases, attached in a very compact and direct way by their semi-immutable inclusion in each aspect type by the (ontology) author who defines it. This acts as a basic declaration on the aspect's nature and expected usage, in much the same way that a programmer assigns a dataype to each variable. See each subsection for details and defaults.

Property Predicate and Topical Predicate PSIs let explicit, optional ASSERTIONS be declared for an aspect type. They are more complex to define, partly because each one now requires some constraint language in which to express the ASSERTION, plus integration of all executables required to test it.

Hopefully, a standard TMCL will soon reduce this chaos. Initially, WORDS limits it by supporting only aspect type strings (a pretty good 80-20 stopgap), and allowing (a few, basic) predicates as experimental.

• onlyAuthor = never, except by the author of aspect's ontology (release)
• onlyAdmin = never, except by an admin with special access rights (install)
• onlyLicensed = never unless explicit constraints are first passed (strict)
• fromConstraints = anytime, unless defined constraints fail to pass (default)

The last case also works as a default for aspects never declared, which have no constraints imposed. For them, all changes are deemed legal. Under onlyLicensed, any attempted updates of them would fail (as being unanticipated). A global setting for WORDS run-time code (TBDL) can make any of the above the default policy.

E.g., each aspect that applies only to living things should cite the defined code for organism. Multiple thing types, separated by spaces, are allowed as an answer.

• A RoleType range specifies one or more types of thing for its Roleplayer value(s), using the same notation as a Domain constraint.

• A PropType can specify a format-specific range of Strings, optionally followed by space-separated codes (TBDL) for related limits. These limits define extend the definition of the related data type, and define syntactic parameters to check in each instance within an occurrence:
  • general String = limits can force a length range, pattern, etc
  • a kind of URI = limits can force a domain, relative link, etc.
  • an Integer = limits can set a size range
  • a TimeStamp = limits can set units, origin, etc
  • a Topic Name = limits define base or varient type, pattern, etc
  • PSI-set ID(s) = limits show if they are in set, list or tree
  • -(others TBD)- = future needs limited in a similar way.

Lots of String types could mean lots of coding work here. Reusing published regular expressions (e.g., for XSD), should help. For many simple WORDS applications, they should be ample.

This design pattern is general, and seeks to let each application assemble the procedural constraints it needs to validate any Property value. Any WORDS validator would first check its format by using the PSI and logic for Range, then check for any ASSERTS listed after other PSIs in its Constraints property, and test them using the related method, with a signature like that above. Such a call might return: .

• patternAssertion = false unless value fits a (regular expression) ASSERT
• inListingAssertion = false unless value is in the (string list) ASSERT
• -(others TBD)- = many more to be defined in a similar way

For any particular RoleType, WORDS syntax can similarly support basic types of ASSERTS. Each related predicate takes such character Strings as the lead argument to a PSI-labeled method with the signature above. The specific predicates WORDS initially defines are wide open by design:

• instanceAssertion = is subject an instance of the user class(es) in the ASSERT?
• subClassAssertion = is subject a subClass of the user class(es) in the ASSERT?
• rolePlayViaWords = does ASSERT, a WORDS predicate on the same arguments, return true?
• -(others TBD)- = many more could clearly be defined using the four arguments above

Each ASSERT has procedural support, which can be as general as its designers desire. For security reasons, open scripts should not be supported, but PSI names and related arguments for scripts can be safely used in ASSERT Strings. Indeed, such a string can even start with the name of a scripting language other than WORDS, which can be called as described under Constraint.

Such extensions should let each aspect author register within a core TM any ASSERT scripts supported by his application's chosen language(s), then rely on those scripts and ASSERTs to ensure that mutations to (copies of) the original TM remain reasonably valid.