Calculated Properties
In some cases, properties are calculated from other properties. In the case of a person, the property "FullName" is created from "FirstName" and "LastName". This does not mean you cannot set the property, but that it is not necessary to do so.
Using the calculated properties concept, a person’s full name, for instance, is calculated by the concatenation of the first names and the last name. This is exposed to the Maltego Desktop Client:
Some example Entities that use calculated properties are:
- maltego.Person
- maltego.Location
- maltego.PhoneNumber
Property types
The current version of the Python library only supports string types, to match the current version of the XML protocol used between the client and the server. Subsequent releases might extend this to include all the other types of properties that Maltego supports. When dealing with Entities that have property types other than strings, make sure you format the string value properly so that the Maltego client can parse the correct type from the string value.
Static vs. dynamic properties
When you design an Entity, you can add properties to the Entity. These are called static properties. This means, that should a user drag an Entity from the palette to the graph, the properties will be available for editing. Refer to the example below showing the property view for Person, with three static properties:
Transforms can create new properties for the Entities they return. The Transform simply adds a property to the Entity when it’s returned. These are called dynamic properties. If a Transform returns a property that had been defined as static in the Entity definition it will store the value as a static property, if it’s not defined in the Entity definition it then becomes dynamic. The only real difference between static and dynamic properties is that users cannot edit dynamic properties on a fresh node from the palette…simply because the property does not exist yet - a Transform is needed to create it.
Inheritance
The concept of inheritance means that the MXRecord, NSRecord, and Website Entities are in fact only specialized DNSNames. The benefit to this is that one Transform e.g. DNSName 2 IPAddress, works on all of them and saves on Transform configuration time. The result being that should you specify on the TDS that a Transform will run on a DNSName it will also run on all Entities down the ‘family tree’ – MXRecord, Website, and NSRecord.
At the top of the tree is the Base Entity, ‘maltego.Unknown’, This means that should you configure a Transform to run on this Base Entity type – it will be available when you right-click on any Entity.
Entity Design Summary
Below is a quick summary of some of the more advanced concepts to be considered when working with Entities.
Calculated Properties | During the Entity design phase, you can set the default value of an Entity to be calculated from other properties. For example, a person’s full name can be calculated by concatenating the first and last names by default. Such a property is referred to as a Calculated Property. |
Static vs Dynamic Properties | When writing a Transform, a property can be added to any Entity, even if that property is not part of the design or specification of the Entity. For example, a ‘Date’ property can be set to reflect the date that the Transform was run to the IP Address Entity which comes from the DNS lookup Transform. Such a property is referred to as a Dynamic Property, and conversely, properties that form part of the specification are referred to as Static Properties. |
Inheritance | During the Entity design phase, you can choose to extend from an existing Entity, inheriting all the base-Entity’s properties. You can then add additional properties to the new entity to add specific functionality to the extended Entity. Transforms designed to work with the new extended Entity type will only work on that Entity type. Conversely, Transforms designed to work for the Base Entity will also work for the extended Entity. |
Entity/Property Merging | When a new Entity is added to a Maltego graph, Maltego automatically checks whether such an Entity already exists. If another Entity of the same type with the same value exists, they will be merged. In addition to these requirements, any property on the new Entity that was set by the Transform developer at runtime to use the ‘strict’-matching rule, will have to match as well before the Entities will merge. |
Bookmarks and Notes | Maltego users can add bookmarks and notes to any Entity. Transform developers can also set the bookmark color and add notes to Entities that is returned. When merging Entities, only the new Entity’s bookmark will be used, and the notes will be concatenated. |