In Blawx, all information is held in objects and attributes. An object represents a collection of information, and an attribute represents a single piece of information. An attribute has a type, which is either a data type, or a category. If an attribute has a data type, only values of that type can be assigned to the attribute. If the attribute has a category, only objects and variables can be assigned to that attribute.
Let’s imagine you want to write some rules about cars, and you have an ontology like this:
You can see that two attributes have been defined for the category “Car”. One is “make”, and its type is “Manufacturer”, which is a category. The other attribute is “model”, which has a data type of text.
If you make these declarations, Blawx will now know about these two attributes, and they will be available in the Known Attributes drawer of the toolbox.
As suggested by the text on the known attribute blocks, the first hole is filled with an object, and the second hole is filled with a value. So to create a Ford Mustang, you might use the following blocks in a Fact Block:
This creates an object called “my_car”, places it in the category “Car”gives it the make “Ford”, and the model “Mustang.” If you try to place something in the value of the make attribute block that is not an object or a variable, it will not fit because Blwx knows that value is supposed to be an object in the category Manufacturer.
If you try to place something other than a string or an object or variable into the “model” attribute block, it will not fit, because Blawx knows that attribute is supposed to have a text value. Objects can still be provided because Blawx treats objects and variables as the same “type”, and a variable may contain a text value.
When working with attributes you will want to be careful with how you name them. Blawx will not stop you from applying an attribute defined for “cars” to an object inthe category “bicycle”. If you need to know how many seats both categories have, but you want to avoid the implication that bikes have car seats or vice-versa, you may want to name the attributes “Bike_seats” and “car_seats” to make it clear what you are referring to.
If you create two attributes both named “seats”, they will both appear in the Known Attributes drawer of the toolbox, but it will not be possible to tell which attribute belongs to which category, and in fact, Blawx will treat them as two copies of the same attribute.
You may also want to name attributes so that their names fit more comfortably into the syntax of the attribute block, which is “object’s attribute is value”. For example, an attribute named “father” makes sense, if you have objects named Anakin and Luke: “Luke’s father is Anakin.” But it may be more difficult to read a yes/no attribute named “Jedi”. “Luke’s Jedi is True.” Something like “is_a_Jedi” might read more clearly.
Attributes Hold Multiple Values By Default
In Blawx, all attributes are lists by default. That is to say, they do not hold only one value, but can hold any number of values. As a result, it can be helpful to name your attributes in a way that implies how many values they have. For instance, a game may have many players. So a game category might have an attribute called “players” to help the user recall that the attribute may have more than one value. Likewise, a category called “world_record” may have an attribute that refers to the player holding that record, of which there is only one, so it may make sense to call that attribute “player” instead of “players.”
Adding cardinality – the ability to say how many values an attribute is expected to have – is a planned feature for a later version of Blawx.