Attribute definition needs enhancement

[yogeshkodei]

trafficstars

Problem to Solve

Current attribute definition is incomplete. Need to add the following as part of definition:

1. Limit of the number of characters it can have depending on the data type
2. Provide a way to describe an attribute. This would be handy while providing a tooltip for a user. Also it makes attribute definition complete so that it can be communicated to other consumers properly
3. Ability to define a displayed as filed so that it can be displayed in plain English to users
4. Ability to invoke a method or a function to populate a derived Enum or set of objects
5. Ability to define roles to the OOTB Attribute field. The current inability prevents from defining roles and assign it. We cannot insert a datatype free attribute under Attribute. We end up defining a base custom attribute for each data type.
6. Need the ability to define an attribute as a class constant so that we could implement behavior based on parameters.

Current Workaround

We end up creating additional attributes and model out way around it. This introduces a lot of inefficiencies.

Proposed Solution

Improve the attribute definition constructs to support what is identified in the problem statement.

[flyingsilverfin]

Hi - thanks for the issue! Couple of things:

1. have you seen the regex we can place on string attributes
2. this seems like a modeling issue - you probably want to model your UI element (or similar) using an Entity with an attribute value for the actual user entered valued, and an attribute for default value, description, hint, etc.
3. I think this is also actually a modeling proble, not an attribute specific problem
4. Not sure what you mean - how is invoking a method linked to attributes? An example would be great!
5. I'm not following this either - an example would best. Is the core issue the requirement to have a datatype on an attribute?
6. What are you trying to say here? How is class different from an Entity in Grakn, and how is a behavior/value different from relations/attributes in the Grakn model? (example would suffice for what you're trying to do)

[yogeshkodei]

Regarding 2: How is this a modeling issue? I want to describe what the meta model stands for. I am not looking for an instance level description by assigning an attribute to it. Example: Let us say I define a type called Person. The meaning of that Person entity is "Any individual who needs to login to the application and perform his day to day activities within the system." If I assign an attribute to capture the intent of that Person entity, then every instance of Person will have that attribute. I am not look for that. I want to just describe the intent of the Entity and not that of its instances. Yes, as you said I can add an attribute but then you are asking me to filter out that from the UI screens somehow as that is not editable. Something as basic as capturing an intent of an entity, or relation or attribute or role should be part of the concept definition itself. In addition the other problem with what you are suggesting is that there is no simple way to define class constants. I wish there was a command to say "Person sub entity, has intent value "abc...." is constant". Writing a regular expression to handle such a simple thing makes it cumbersome to implement.

Regarding 3: If I define an attribute as estimatedStartDate, when I display it in the UI I want it to be displayed as "Estimated Start Date". The attribute definition and the attribute display statement go together unless you have the ability to define a relation between an attribute and another attribute. When I asked a question about nested attribute I was advised not to use it as it will change. That being said how is it a modeling issue? An attribute definition should be more like the following: estimatedStartDate sub attribute, intent "Captures the estimated start date of the activity" displayed as "Estimated Start Date" in "English".

Please tell me how I would model the above without nested attributes.

Regarding 4: Making everything an Object does not make sense for performance reasons. Here is an example: Let us say at time T1, I have an object with attribute 1 - "X", attribute 2 = "Y" and the entity has other 10 attributes. But there are 1000s of other attributes in the schema. At time T2, someone wants to indicate that he wants to change only attribute 2 from "Y" to "Z". Before he changes the object, it needs to be authorized. The system should indicate that only those 12 attributes are available to be changed. I want to define a attribute with a range that is restricted to only those 12 attributes. I do not want to define a static list of string as part of regex. I want a dynamic call due to obvious reasons. Because if I change the list of attributes on that entity tomorrow I will have to go and change all the other references as well. I want something like: changeAttribute sub attribute regex "get all the attributes for Activity entity"; This will it will be dynamic instead of saying

changeAttribute sub attribute regex "Attribute 1. Attribute 2";

Regarding 5: I want to simple do the following: mycustomroot_attribute sub attribute and then derive all attributes from "mycustomroot_attribute" as I can assign roles to this attribute.

But the system complains that I need to define mycustomroot_attribute with a datatype. So to get around it I will have to define mycustomroot_attribute_long sub attribute, datatype long and then assign roles to those attributes.

I would rather define it as "mycustomroot_attribute sub attribute" or to say "attribute plays role1" instead of creating datatype specific root attributes.

The role that I want to assign is a global role that every attribute should get. Is there any other way to do it?

Regarding 6: Please read my response to 2. In addition. I want to capture some information on relations to reflect whether it is aggregation or composition or something else. All instances of that relation will and should have the same value. A car is composed of several parts. It is an aggregation. When I define a relation "composedOf sub relation has isAggregation value "yes" isConstant" is what I need. In the business logic layer, when I inspect the relation "composedOf" I can see that it is an aggregation and so can define the corresponding behavior.

Hope the above explanations suffices. If sufficient please provide alternate options. If not clear please ping me and I would be able to provide more detailed real work explanations.

[alexjpwalker]

2- depending on what you want to achieve, this could be a good use case for an IDE plugin:

/** The length in centimetres of an entity */
length sub attribute, value double;

then hovering over length anywhere would bring up a tooltip saying "The length in centimetres of an entity".

If you want the description of an attribute to be retrievable by a grakn query, I would recommend

define
schema-attribute sub entity, has attribute-name, has attribute-description;
attribute-name sub attribute, value string;
attribute-description sub attribute, value string;

then you can create a schema-attribute for every attribute type in your schema which is easily queryable to get the description.

This is also more extendable, so you can include other "meta-properties" in it, as you ask for in point (6)

3- You could extend the schema-attribute example above to also have an attribute-displayed-name, and use Graql and your application layer to query it and handle the mapping of schema concept labels onto human-friendly names.

4- so you want to retrieve all the attribute types that a type owns? That will be possible in the future using match $x has $y; but currently there is a bug that makes that query not work.

5- Sounds like your best workaround for now is to define one "root" attribute for each of the 5 attribute value types, string, long, double, boolean and datetime.

[dynamic-modeller]

2. Provide a way to describe an attribute. This would be handy while providing a tooltip for a user. Also it makes attribute definition complete so that it can be communicated to other consumers properly

My suggestion is to use aattributes and the "has" relation, one of the most powerful aspects of typedb:

define
   a_description sub attribute, value string;
   a_display_name sub attribute, value string;

   myInt sub attribute, value long,
      owns a_description ,
      owns a_display_name;

   myString sub attribute, value string,
      owns a_description ,
      owns a_display_name;

3. Ability to define a displayed as filed so that it can be displayed in plain English to users see above

4. Ability to invoke a method or a function to populate a derived Enum or set of objects I woulde certainly like to see enum support. The idea of dynamic enums makes sense, but the question of when the dynamic update is required needs thought. Is it required to be dynamically filled on query, then you need some kind of rule to fil the enum. Otherwise if it is on some frequency (e.g. daily), then the client could pull the data and iniatie an api call for the update.

5. Ability to define roles to the OOTB Attribute field. The current inability prevents from defining roles and assign it. We cannot insert a datatype free attribute under Attribute. We end up defining a base custom attribute for each data type.

I've actually come across this issue before, for example if one wants to mimic a JSON structure, where the index to an item is either a string or an integer. In this instance it would be useful to have a common ancestor as abstract, from which int-index and string_index sub class. Further, it would be useful if the role to be played could be placed ont the ancestor and inherited by both sub classes. Currently, this requires the role to be placed on each sub class, and i had to convert integer indexes to strings.

6. Need the ability to define an attribute as a class constant so that we could implement behavior based on parameters This one is quite interesting as it acknowledges that in many ontologies, some classification occurs through classes of things, other categorisation occurs through a string-based taxonomy. Given this it seems obvious that some sub class definitions would benefit from enabling a string constant to specified for a particular property.

In general, this approach of having an attribute with a specified value, in a schema definition is useful for the specification of sub calsses, where the class is specified by data. The converse argument says that this approach can be implemented through rules on fixed values, and i'm not sure if these are equivalent.

[flyingsilverfin]

Re 5. it sounds you may want to create an entity to hold a "data" element, which can then hold attributes of different types

[krishnangovindraj]

Point 5 is a duplicate of https://github.com/vaticle/typedb/issues/3257 Schema level constants / types having attributes sounds like a valid feature request. Hence keeping this issue.