kPMML

kPMML models are written in the kPMML language (an enhanced version of XML as defined by the dmg.org). The dependencies are coded into the XML tags themselves and the kPMML code is used to generate Scala executable code that then is packaged into the appropriate JAR file for runtime execution. Introduction to kPMML Models kPMML … Read More

kPMML – An Annotated COPD Model

This section introduces the healthcare example used on this web site. The healthcare example is model that will filter out those patients who are at risk for COPD. Header In this model, the engine presents the in-patient, out-patient, and HL7 history of an individual to the model, presumably triggered when one of these respective records … Read More

kPMML – Collection Types

Most data structures supported in the Scala programming language can be declared in the Kamanja metadata and used by the models, including many of the concrete classes found in the Scala collection packages. Not all of them are currently defined in Kamanja’s metadata bootstrap, but it is possible to define them (and the functions that … Read More

kPMML – Constants

The Constant dataType has been extended to support a number of the new features introduced in kPMML. In addition to interpreting the Constant value to one of the supported DMG data types, it is used to give hints to the compiler as to the nature of the argument in its larger context. It is worth … Read More

kPMML – Hierarchical Data

As mentioned earlier, data can be hierarchical in nature. To access hierarchical data elements, the FieldRef field attribute uses a conventional ‘.’ deferencing notation found in most programming languages. For example, consider the following DerivedField definition:

The FieldRef field attribute shows how to access a field called Bene_Birth_Dt that is part of the message, … Read More

kPMML – Macros

Introduction to Macros For some model development tasks, the use of a system of Apply expressions is insufficient to express the problem the model is to address. For example, the nature of the PMML language has no means to update a specific field of a container or message structure. This is where macros are useful. … Read More

kPMML – Messages Versus Containers

Note that the only distinction between a container and a message is one of convention. The only significant difference is that messages are cataloged globally in the metadata as top-level container structures. The message is the principal vehicle for presenting data to the model. Instead, use container instances as elements of a message or another … Read More

kPMML – User-defined Functions (currently not supported)

Shipped with the Kamanja platform is a user-defined function library that contains some core function behavior of general use to all models. Currently, there are approximately 80 functions with unique names in this library (500 + functions if their variants are counted). They include the following functions shown in Table 1. Table 1 User-defined Functions … Read More

kPMML – User-defined Functions (UDFs), Macros, and Constants

User-defined Functions (currently not supported) Click on the above link to learn about user-defined functions. Writing a Custom UDF Library Click on the above link to learn about writing a custom UDF library. User-Defined Properties Click on the above link to learn about user-defined properties. Macros Click on the above link to learn about macros. … Read More

kPMML – User-defined Properties

A Kamanja model developer can use Kamanja metadata to store and share some user properties. These properties can be specified in the ClusterConfig.json properties file, which then can be uploaded, after which any runtime instance affected by that ClusterConfig.json can use the getPropertyValue(clusterId: String, key:String): String method on a ModelContext, EnvironmentalContext, or TransactonContext object available. … Read More