One may feed the discussion on concepts like properties and attributes in various ways. There are and will be many different opinions on the characteristics of these concepts. Even in graph theory there is no consensus. The purpose of the Boxary software however allows for a clean definition.

Example. A woman may be blond and may drive a car. The woman is a living thing with blondness as a property. The car is a thing and the verb 'drives' assigns the car as an attribute.

Please note that there will be no discussion on the truth of this example. What is important, is that properties may identify the subject and attributes will extend the subject. Properties fall in the category 'is-a' and attributes fall in the category 'has-a'. Though this could be the main concept, it is not completely the case.
What is also important in our case, is the aspect of our view. Above deduction is valid only when we view the subject as an 'entity', which is 'person' in this case. But Boxary is about software and about graphs and delivers a total abstract concept of entities.

Example. A vertex has properties and edges assign attributes to vertices.

How wonderful. But please do not view vertices being equivalent with entities, nor edges being equivalent with aspects. Vertices and edges are abstract and form the structures where application data will land. Boxary uses a EAV model and this model allows for storage of the data, modelled after entity - attributes. The resulting graph system however models the access, not necessarily conform a entry - attribute paradigm.

Final. (vertex)properties are (boxary)SystemData and attributes are applicationData.

This is the best definition to offer. If Boxary is installed, the skeleton contains vertices with (system)properties and edges. The usage of Boxary allows for adding attributes. So, the Boxary kernel deals in this way with properties and attributes. Now, do view the manifest.


Attributes have an ID while Properties are named. With these keys the rendering instructions can be found, which are either a short snippet or a reference to a Slot. These instructions are found in their respective manifest. When rendering (processing templates) both are disclosed using a template variable. Attributes become the registered template variable for its ID, while Properties are assigned with their name.


Slots are hybrid templates and have a Code; f.i. 'select:vertex' or 'textarea:raw'. Its manifest maps the Code to a closure (a named file) which contains either a simple template or arbitrary php code. The result of exciting this closure is always rendered text.