The SystemML Namespace is a hierarchical tree with a single root, containing nodes representing SystemML Components. The path into the Namespace at which a Component is found is called the Component "class", and is a unique way to refer to a Component (strictly, to a Component specification - there may be more than one implementation at the Component node). The node contains the component specification (both in human and machine readable forms), and zero or more implementations for particular execution clients. When a client is asked to instantiate a Component, the class is used to obtain the necessary resources from the appropriate provider. Generally, these will be available in local cache - if not, they can be obtained from the provider's server (the SystemML Server, a local server, or just a local filesystem).

Since the Namespace is a shared resource, certain rules are enforced to ensure that naming conflicts do not occur. The Namespace contains a branch for each organization that is registered as a publisher with the SystemML Server and they are responsible for avoiding naming conflicts within that branch. In addition, several branches are reserved by the specification, as listed below. Additional branches may be reserved in future.

Globally-managed branches

Components published onto these branches have persistent status in the global namespace and conflict resolution is managed by the public server.

The branch belonging to a registered publishing organisation.
Reserved for the Standard Library.

The <org> branch

An <org> branch must contain only sub-branches that are 4-digit years (publication date), but the contents of those sub-branches are up to the publishing organisation. A Component, then, has a class of the form <org>/<year>/my/component/class.

The std branch.

The contents of std are organised by the SystemML developers. The Standard Library is an extensible set of generic Components that can be implemented in any client - SystemML specifies the system-level interfaces those Components must express. The basic Data classes are found here.

Locally-managed branches

Components published onto these branches have their status and conflict resolution managed locally by the branch manager. The public server has no knowledge of these branches. Therefore, production systems should not reference components in these branches.

Reserved for local use by the user.
Reserved for local use by clients, like BRAHMS.
Reserved for any use by anyone, public or private.

The local branch

No constraints are placed on this branch, since it will be implemented locally to an organisation and noone else will ever see it. However, sticking to the <org> branch approach probably isn't a bad idea, with classes of the form local/<year>/my/component/class. This will make publishing these Components to the public Namespace easier, minimising the changes required both to the Component source code and to system code to use the published version of the Component. This branch is managed by the organisation.

The client branch

Specific clients may like to provide demo, test, or other Components to their users. The client branch is similar to the local branch, but private to the client rather than the user. Clients should use a sub-branch named appropriately (BRAHMS uses client/brahms). This branch is managed by the client developers.

The dev branch

No constraints are placed on this branch, noone has overall responsibility for it, and there are no concerns as to how it is used - the responsibility is with the end user to recognise that Components herein may change. This branch is not managed (the branch is intended for use during alpha development, before work is shared at all, and before a home in more public branches has been assigned to a component).

Publication Policy

Any publication made to the public part of the namespace (std and <org>) will remain present and unchanged forever. This ensures that any System using a Component from the public Namespace will still compute in an identical way ten years from now, without modification. Note that in implementational terms, Components may be archived and thus become "inactive" safely, so long as they can be returned to active status if a request is ever made for them.

Namespace Organization

The structure of the Namespace is, conceptually, a flat list. That is, the node hierarchy is not intended to confer any semantic order on the Component collection. There is some hierarchical structure imposed (see above) solely for reasons of assigning responsibility. The first responsibility is that Components in <org> or std must persist for all time once published; the second is that the relevant organisation must ensure naming conflicts do not occur within a given Namespace branch. This aside, the class of a Component can be seen just as a unique identifier into an unordered set.

The principle behind this is that there will be many ways to organise the contents of the Namespace in people's minds, so imposing one particular structure upon everyone is not progressive. Some of these ways will not be purely hierarchical (some modules may have multiple parents), also. Therefore, SystemML does not impose an organisation, both because no organisation is fundamental, and because the filing system that will be behind an implementation won't generally support multiple parenthood.

Hierarchies of one sort or another can be imposed, to aid human search of the tree, through Overlays.


The Namespace, as mentioned, is conceptually organised as a flat list, which may not be easy to navigate if you are seeking a module to compute a certain class of problem, for example. To facilitate human-useful navigation, any number of overlays can be laid down on the flat list. We expect one overlay, for instance, to be a categorical organisation, with modules arranged in groups of similar function (general purpose mathematical processes, research models, hardware interface components, etc.).

Notes on implementation

The Class node is shared between all SystemML clients, and thus some respect should be shown between them to avoid conflicts. In particular, where clients implement the Class node as a container (e.g. a folder), all client-specific data should be in a sub-container named for the client. For instance, BRAHMS uses <node>/brahms.