Augmented Type for Equations and Externals

Last revised 08/08/2019 by A. W. Crapo

Acknowledgement

Augmented Types were developed in the course of work funded by the Defense Advanced Research Projects Agency (DARPA) under Agreement No. HR00111990006.

Introduction

The purpose of SADL is to capture knowledge in the form of semantic models. In Version 3, simple equations can be expressed in the SADL grammar and more complex equations can be referenced as external equations. In either case, the signature of the equation identifies the name of the equation, the type and name of each argument, and the type of any values returned by the equation. (Since some languages in which external equations might be expressed allow the return of multiple values, so does the SADL grammar.) However, all but the simplest equations have implicit constraints placed on their usage. Almost always these constraints are not captured in the code and often they are not captured in the documentation because it is assumed implicitly that anyone using the equation will have domain knowledge sufficient to understand these constraints. Augmented Types deal with the explicit capture of these constraints so that the knowledge of how to properly use the equation is also captured. This is a necessity if equations are to be used by an artificial intelligence or by people less knowledgeable about a domain.

We will consider the problem of capturing the semantic constraints associated with an equation in three parts.

  1. What are the constraints?
  2. How can they be expressed in a way that humans and machines can understand them unambiguously?
  3. How can they be expressed to enable querying and automated reasoning over them?

The solutions to questions 2 and 3 may be the same or may be different. Also, the best way to represent semantic constraints for human understanding may vary from person to person.

A Example

Let's use a simple example to illustrate. The example is drawn from the NASA Glenn Research Center's Hypersonics Web site: https://www.grc.nasa.gov/WWW/BGH/shorth.html. Mach number and the various regions of flight which it defines are illustrated by this figure from the referenced site.

Figure 1: Mach Number and Regions of Flight

Implicit constraints on the use of this equation for Mach number are the following.

  1. The "Speed of Sound" in the denominator must be the speed of sound in the medium through which the "Object" is moving.
  2. The speeds in the numerator and denominator must have the same units to yield the desired ratio.

On another page in the NASA Glenn Web site, we find an equation for the speed of sound.

Figure 2: Equation for the Speed of Sound

This equation (in red) also has some constraints, some of which are given in the surrounding text.

  1. The speed of sound "a", the ratio "γ", the gas constant "R", and the temperature "T" are all properties of the same thing--a gaseous medium.
  2. The temperature "T" must be in degrees Kelvin.

Finally, we find a set of equations for temperature of atmospheric air on Earth on another page. We are interested in the three equations for temperature "T" as a function of altitude "h".

Figure 3: Earth Atmospheric Model

Constraints for these equations include the following.

  1. The altitude h must be in feet (ft).
  2. The temperature T will be in degrees F
  3. Each of the three equations has a range restriction on the values of h for which it is valid.

Putting the three pages together gives us the following graphical view of computing the Mach number.

Figure 4: Composite Picture of Equations for Mach Number, Speed of Sound, and Atmospheric Temperature

Representing Equation Constraints in SADL

SADL, a controlled-English language for expressing semantic models, allows us to capture the signatures of equations. Here are the signatures of the five equations in SADL syntax at the level of detail one would expect to find in a procedural language such as Java or C.

  1. Equation machNumber(decimal so, decimal sos) returns decimal
  2. Equation speedOfSoundEq(decimal gamma, decimal R, decimal T) returns decimal
  3. Equation troposphereTemperature(decimal alt) returns decimal

  4. Equation lowerStratosphereTemperature(decimal alt) returns decimal

  5. Equation upperStratosphereTemperature(decimal alt) returns decimal

Representing the constraints on the use of these equations is fundamentally a question of capturing the graph patterns that relate the equation arguments and returned values to each other, in domain terms, as well as any additional functional constraints. The SADL expression grammar already allows us to capture graph patterns and functions, so we will use this capability to augment the signatures. Of course we need to establish a domain model before we can express constraints in that domain model. Here is a simple model for the domain to which these equations apply. UnittedQuantity is a class in the SADL implicit model (implicitly imported into every SADL model) with properties value and unit.

Temperature is a type of UnittedQuantity.
Speed is a type of UnittedQuantity.
Length is a type of UnittedQuantity.
SpecificHeat is a type of UnittedQuantity.
GasConstant is a type of UnittedQuantity.

PhysicalThing is a class,
   
described by speed with values of type Speed,
   
described by temperature with values of type Temperature.

Medium is a type of PhysicalThing.

Gas is a type of Medium,
    
described by specificHeatCV with values of type SpecificHeat,
    
described by specificHeatCP with values of type SpecificHeat,
    
described by gamma with values of type decimal,
    
described by gasConstant with values of type GasConstant,
    
described by speedOfSound with values of type Speed.

Air is a type of Gas.

Object is a type of PhysicalThing
    
described by altitude with values of type Length,
    
described by movesIn with values of type Medium,
    
described by mach with values of type decimal.

Using this domain model, we can now express the augmented signatures of the five equations with constraints made explicit. Note that "value" is escaped with a "^" at the beginning because it is also a keyword in the grammar. Note also that this example uses English indefinite and definite articles to generate variables to link graph patterns together, and "some" is treated as an indefinite article because it is more English-like for substances (as opposed to objects). Hence "some Air" creates a variable of type Air and "the Air" references that variable, "an Object" creates a variable of type Object and "the Object" references that variable.

  1. Equation machNumber(decimal so (speed of (an Object movesIn some Air)), decimal sos (speedOfSound of the Air and unit of speed of the Object = unit of speedOfSound of the Air))
          
    returns decimal (mach of the Object)

  2. Equation speedOfSoundEq(decimal gama (gamma of some Gas), decimal R (^value of gasConstant of the Gas {"m2/sec2/K"}), decimal T (^value of temperature of the Gas {K}))
         
    returns decimal (^value of speedOfSound of the Gas {"m/sec"})

  3. Equation troposphereTemperature(decimal alt (^value of altitude of some Air and alt <= 36152 {ft}))
         
    returns decimal (^value of temperature of the Air {F})

  4. Equation lowerStratosphereTemperature(decimal alt (^value of altitude of some Air and alt > 36152 and alt <= 82345 {ft}))
         
    returns decimal (^value of temperature of the Air {F})

  5. Equation upperStratosphereTemperature(decimal alt (^value of altitude of some Air and alt > 82345 {ft}))
         
    returns decimal (^value of temperature of the Air {F})

Viewing Equation Constraints as a Graph

Equation constraints can be viewed as a graph. For example, the constraints of Equation 4, lowerStratosphereTemperature, look like this, where variable nodes are pink, class nodes are dark blue, instance nodes are lighter blue, and properties are green.

Figure 5: Equation Constraints Viewed as a Graph

Note that while the functional constraints greaterThan and lessThanOrEqual are shown here as graph edges, this is only possible because they are binary functions. For non-binary functions the function would have to be a graph node with arguments linked to it.

Representing Equation Constraints in OWL

First consider the kinds of things that we need to capture in the constraint model. Continuing with the example of Equation 4, lowerStratosphereTemperature, and using Figure 5 as a guide, we identify the need to capture the following information, expressed here in pseudo RDF.

  1. TriplePattern (v0, rdf:type, Air)
  2. TriplePattern (v1, rdf:type, Length)
  3. TriplePattern (v0, altitude, v1)
  4. TriplePattern (v1, value, alt)
  5. TriplePattern(v1, unit, ft)
  6. TriplePattern (v2, rdf:type, Temperature)
  7. TriplePattern (v0, temperature, v2)
  8. TriplePattern (v2, value, v3)
  9. TriplePattern (v2, unit, F)
  10. FunctionPattern(greaterThan, alt, 36152)
  11. FunctionPattern(lessThanOrEqual, alt, 82345)

    where alt is the input decimal value and v3 is the returned decimal value computed by the equation.

In order to capture equation constraints in OWL, we need a meta-model for constraints. We have considered using the W3C recommended Shapes Constraint Language SHACL (see https://www.w3.org/TR/shacl/). However, in SHACL the graph patterns of the constraints are represented as SPARQL strings, which would have to be parsed into a structured representation in order to be able to query or infer over the patterns. That would require parsing the SPARQL into some meta-model, so we are forced in any case to provide some non-standard meta-model. The SADL Augmented Types meta-model is in the SADL implicit model and the relevant snippet of that model is shown below.

Figure 6: The Equation (and Tabular Data) Constraint Meta-model

The OWL created from the equation constraints is not easy to read in any standard OWL serialization. The portion for lowerStratosphereTemperture, in RDF/XML-ABBREV format, is shown in Appendix A at the end of this document. To relate this content to the pseudo RDF above, we will illustrate the mappings of two elements from the above constraints.

(1) TriplePattern (v0, rdf:type, Air)

maps to

             <j.0:TriplePattern>
               <j.0:gpObject rdf:resource="#Air"/>
               <j.0:gpPredicate>http://www.w3.org/1999/02/22-rdf-syntax-ns#type</j.0:gpPredicate>
               <j.0:gpSubject rdf:resource="#lowerStratosphereTemperature_v0"/>
             </j.0:TriplePattern>

(10)FunctionPattern(greaterThan, alt, 36152)

maps to

             <j.0:FunctionPattern>
               <j.0:argValues rdf:parseType="Collection">
                 <j.0:GPVariable rdf:about="#lowerStratosphereTemperature_alt"/>
                 <j.0:GPLiteralValue>
                   <j.0:gpLiteralValue rdf:datatype="http://www.w3.org/2001/XMLSchema#decimal">36152</j.0:gpLiteralValue>
                 </j.0:GPLiteralValue>
               </j.0:argValues>
               <j.0:builtin rdf:resource="builtinfunctions#greaterThan"/>
             </j.0:FunctionPattern>

Note that order matters in a number of places in the OWL representation of the constraints of the equation. In the meta-model, the range of a property where order matters is given as a typed List, e.g., the argValues property with domain FunctionPattern, has range GPAtom List. Similarly, the order of units matter because it is intended that if the nth unit listed, when multiple are listed, not illustrated here, is used for one argument, then the nth unit listed must be used for all other arguments and for the returned value.

Appendix A: Semantic Constraints for Equation lowerStratosphereTemperature

 <j.0:Equation rdf:ID="lowerStratosphereTemperature">
   <j.0:returnTypes rdf:parseType="Collection">
     <j.0:DataDescriptor>
       <j.0:descriptorVariable>
         <j.0:GPVariable rdf:ID="lowerStratosphereTemperature_v3"/>
       </j.0:descriptorVariable>
       <j.0:augmentedType>
         <j.0:SemanticConstraint>
           <j.0:constraints rdf:parseType="Collection">
             <j.0:TriplePattern>
               <j.0:gpObject rdf:resource="#Temperature"/>
               <j.0:gpPredicate>http://www.w3.org/1999/02/22-rdf-syntax-ns#type</j.0:gpPredicate>
               <j.0:gpSubject>
                 <j.0:GPVariable rdf:ID="lowerStratosphereTemperature_v2"/>
               </j.0:gpSubject>
             </j.0:TriplePattern>
             <j.0:TriplePattern>
               <j.0:gpObject rdf:resource="#lowerStratosphereTemperature_v2"/>
               <j.0:gpPredicate>http://sadl.org/SemanticConstraintsExample.sadl#temperature</j.0:gpPredicate>
               <j.0:gpSubject>
                 <j.0:GPVariable rdf:ID="lowerStratosphereTemperature_v0"/>
               </j.0:gpSubject>
             </j.0:TriplePattern>
             <j.0:TriplePattern>
               <j.0:gpObject rdf:resource="http://www.w3.org/2001/XMLSchema#decimal"/>
               <j.0:gpPredicate>http://www.w3.org/1999/02/22-rdf-syntax-ns#type</j.0:gpPredicate>
               <j.0:gpSubject rdf:resource="#lowerStratosphereTemperature_v3"/>
             </j.0:TriplePattern>
             <j.0:TriplePattern>
               <j.0:gpObject rdf:resource="#lowerStratosphereTemperature_v3"/>
               <j.0:gpPredicate>http://sadl.org/sadlimplicitmodel#value</j.0:gpPredicate>
               <j.0:gpSubject rdf:resource="#lowerStratosphereTemperature_v2"/>
             </j.0:TriplePattern>
           </j.0:constraints>
         </j.0:SemanticConstraint>
       </j.0:augmentedType>
       <j.0:specifiedUnits rdf:parseType="Resource">
         <rdf:rest rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#nil"/>
         <rdf:first rdf:datatype="http://www.w3.org/2001/XMLSchema#string">F</rdf:first>
       </j.0:specifiedUnits>
       <j.0:dataType>http://www.w3.org/2001/XMLSchema#decimal</j.0:dataType>
     </j.0:DataDescriptor>
   </j.0:returnTypes>
   <j.0:arguments rdf:parseType="Collection">
     <j.0:DataDescriptor>
       <j.0:augmentedType>
         <j.0:SemanticConstraint>
           <j.0:constraints rdf:parseType="Collection">
             <j.0:TriplePattern>
               <j.0:gpObject rdf:resource="#Air"/>
               <j.0:gpPredicate>http://www.w3.org/1999/02/22-rdf-syntax-ns#type</j.0:gpPredicate>
               <j.0:gpSubject rdf:resource="#lowerStratosphereTemperature_v0"/>
             </j.0:TriplePattern>
             <j.0:TriplePattern>
               <j.0:gpObject rdf:resource="#Length"/>
               <j.0:gpPredicate>http://www.w3.org/1999/02/22-rdf-syntax-ns#type</j.0:gpPredicate>
               <j.0:gpSubject>
                 <j.0:GPVariable rdf:ID="lowerStratosphereTemperature_v1"/>
               </j.0:gpSubject>
             </j.0:TriplePattern>
             <j.0:TriplePattern>
               <j.0:gpObject rdf:resource="#lowerStratosphereTemperature_v1"/>
               <j.0:gpPredicate>http://sadl.org/SemanticConstraintsExample.sadl#altitude</j.0:gpPredicate>
               <j.0:gpSubject rdf:resource="#lowerStratosphereTemperature_v0"/>
             </j.0:TriplePattern>
             <j.0:TriplePattern>
               <j.0:gpObject>
                 <j.0:GPVariable rdf:ID="lowerStratosphereTemperature_alt"/>
               </j.0:gpObject>
               <j.0:gpPredicate>http://sadl.org/sadlimplicitmodel#value</j.0:gpPredicate>
               <j.0:gpSubject rdf:resource="#lowerStratosphereTemperature_v1"/>
             </j.0:TriplePattern>
             <j.0:FunctionPattern>
               <j.0:argValues rdf:parseType="Collection">
                 <j.0:GPVariable rdf:about="#lowerStratosphereTemperature_alt"/>
                 <j.0:GPLiteralValue>
                   <j.0:gpLiteralValue rdf:datatype="http://www.w3.org/2001/XMLSchema#decimal">36152</j.0:gpLiteralValue>
                 </j.0:GPLiteralValue>
               </j.0:argValues>
               <j.0:builtin rdf:resource="builtinfunctions#greaterThan"/>
             </j.0:FunctionPattern>
             <j.0:FunctionPattern>
               <j.0:argValues rdf:parseType="Collection">
                 <j.0:GPVariable rdf:about="#lowerStratosphereTemperature_alt"/>
                 <j.0:GPLiteralValue>
                   <j.0:gpLiteralValue rdf:datatype="http://www.w3.org/2001/XMLSchema#decimal">82345</j.0:gpLiteralValue>
                 </j.0:GPLiteralValue>
               </j.0:argValues>
               <j.0:builtin rdf:resource="builtinfunctions#le"/>
             </j.0:FunctionPattern>
           </j.0:constraints>
         </j.0:SemanticConstraint>
       </j.0:augmentedType>
       <j.0:specifiedUnits rdf:parseType="Resource">
         <rdf:rest rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#nil"/>
         <rdf:first rdf:datatype="http://www.w3.org/2001/XMLSchema#string">ft</rdf:first>
       </j.0:specifiedUnits>
       <j.0:dataType>http://www.w3.org/2001/XMLSchema#decimal</j.0:dataType>
       <j.0:descriptorVariable rdf:resource="#lowerStratosphereTemperature_alt"/>
       <j.0:localDescriptorName>alt</j.0:localDescriptorName>
     </j.0:DataDescriptor>
   </j.0:arguments>
   <j.0:expression>
     <j.0:Script>
       <j.0:language rdf:resource="sadlimplicitmodel#Text"/>
       <j.0:script rdf:datatype="http://www.w3.org/2001/XMLSchema#string">decimal lowerStratosphereTemperature(decimal alt): </j.0:script>
     </j.0:Script>
   </j.0:expression>
 </j.0:Equation>