In EBA attributes are modeled via concepts, ontology, and semantic actions. Most of these components are auto-generated by EBA when an agent is loaded. For a developer there are only a few relations needed to be defined in the ontology:
All of this ontology definitions can be done at “Concepts” tab in EBA Dev Lab.
EBA handles attributes on the assumption that entities are represented by JSON objects and collections are represented by JSON array of JSON objects. EBA only supports primitive types as attribute values. To enable type-specific OOB semantic actions (like ranking for numerical attributes, fuzzy search for string attributes) you need to define additional ontology:
For every attribute EBA automatically generates all the neccessary components (concepts, ontology, and semantic actions). You may use some of these autogenerated concepts in your semantic actions or visualizers if necessary. If we define the attribute
example:Price as an attribute of
example:Product EBA will generate the following ontology:
example:Product hasAttribute example:Price- this relation may be useful in polymorphic semantic actions or rewriting rules;
example:PriceValue, example:PriceValues isValueOf example:Price- for every attribute additional concepts are generated which represent actual values of attributes. EBA distinguish singular and plural forms of attribute values. You should refer to these concepts when you define custom visualization for your attributes;
attr:ProductPrice attributeOf example:Product, example:Products- for every attribute - entity relationship EBA generates an auxiliary concept to hold a JSON field name. These auxiliary concepts are used in OOB semantic actions to sort, filter or rank collections.
You can share attribute concepts among different business entities if necessary. For example you can define the attribute
example:Address and then make it as an attribute of both
example:Supplier. EBA will generate two auxiliary concepts to distinguish these attributes: