Content under development

The IM partnership is being launched as we write (Fall 2017). Much of the its initial work will provide full documentation in web pages like this one. As a temporary preview, we outline each page's planned contents here. We expect the site to be in initial working shape by 2018.

We are currently entertaining conversations with prospective partners, whose participation will be instrumental in finalizing this site's details and content.

Please contact us at if you would like more information before then.

Outline of forthcoming content

  • K.Lab is the reference implementation for the k.IM language and all functionalities of semantic modeling as described in this site. It is distributed according to the Affero General Public License 3.0, implying that all derivatives of this work must adopt the same license. The IM partnership, jointly with the individual code author(s), holds the intellectual property for the k.IM language, the k.LAB design, and all code.
  • No functionalities offered by k.LAB are yet available in any other package and much serious work has been and is being done with it. The software has been functional and in use for many years with hundreds of users, and has been used in trainings and courses since 2014, although many features are still in development or test stage. However, the software has not yet reached a stable version, and development is intense although the API is stable enough for serious developers to work with it. The IM partnership intends to mobilize the development resources necessary to lead to the release of version 1.0 between late 2018 and mid-2019. 
  • The code resides on git repositories hosted by Atlassian’s Bitbucket hosting service, under the KLAB main project. Most of the code is in Java 1.8, with some Groovy and Clojure components. It is built with Maven 3.0. The main software artifacts are pushed to Maven Central, but since this does not happen regularly and some non-standard repositories are still used, we suggest for now that developers always use locally installed artifacts built from source. The partnership maintains a continuous integration service using Atlassian’s Bamboo, where the artifacts released are built in both official (tracking the master branch) and development (tracking develop) versions. We suggest that any interested developer bases their code on the develop branch and regularly merges in any changes (coming in usually daily).
  • The main Maven projects that must be checked out to build a complete system are:
  • The projects above are structured in multiple sub-modules and each produces several different artifacts. They will soon be joined by a fourth project containing the implementation of most network-based components (k.Server), which are temporarily being developed in a non-public repository but share the same license as the remainder.
  • The first two projects are built with Maven in the normal way. The IDE is built with Maven and Tycho, and (because of Tycho’s internal limitations) uses a networked repository for temporary storage when building, so that ‘mvn install’ will fail in klab-ide without the proper upload permissions. Still, it is not necessary for a developer to build the IDE with Maven; simply installing the three projects in a recent version of Eclipse (Neon at minimum, with only a few third-party plug-ins installed) will yield a running installation of the IDE, run through the default Eclipse launcher and properly set up for debugging. Since we cannot provide individual support except through existing collaborations, we suggest that only experienced developers attempt this type of installation. We maintain more detailed configuration instructions on our collaborative site, which we’ll be happy to point you to until these pages are in better shape.
  • The javadocs are rebuilt at each commit to the develop branch and are available at We will include a “field guide” to the javadocs on this site soon.
  • Using a client like the k.LAB IDE is the most common way of accessing modeling functionalities, but a programmer can also use the engine API and embed observation functionalities in Java programs. A basic example of using the Java API to access the network and make observations through referencing concept and observation URNs could look like this:
  • A major part of many independent developers’ interests will likely include development of components – independent packages that provide functionalities for k.LAB, such as new model integrations. A Maven archetype is provided that installs a sample component to use as a template. The KLAB project in Bitbucket contains many of the components that are currently available.
  • Little documentation and support is currently available for working with the k.LAB API, but the IM partnership plans to produce those and maintain active Gitter channels to support open-source developers interested in collaborating with the core team. Question should be directed to and we encourage interested open-source contributors to inquire.