Updating the GRC-20 data model, sought to simplify the model, improve data integrity, add ontological flexibility, and increase indexer performance.

First, the ID scheme is changing from Base58 to UUID. This migration is being done by decoding previous base58 IDs back to UUID format. If the previous ID is UUID, it stays the same. If a previous ID is an erroneous format, it is deterministically converted into valid UUID by taking an md5 hash of the string, seeding that into a UUID4 generator.

The data model is moving on from the concept of a triple and instead using an an entity-value oriented framework.

Entities will remain much the same as in the previous data model with a few small changes:

Note: Triples are now referred to as values

First, value types are now referred to as data types. Since we are moving away from a triple based framework, each value will not define its own data type. Instead data types will be defined on the property. Property data types are a now immutable and they are verified by the indexer in order to promote data integrity.

A limited set of data types are used to simplify guidelines on what should be a data type and what shouldn’t. Types that existed previously have been redefined as renderable, which are used to separate data storage format and display customization (e.g. relation vs. image or text vs. url). For more information on renderable types, see section 3.5.

In the previous data model, the distinction between entities and relations is a bit fuzzy. Both entities and relations can have properties (values or relations) defined on them. But relations, specifically have "To", "From", and "Relation type" properties. Relations also have "Index" and "Verified" properties as well.

For the sake of this update, let's imagine that relations are made up of these specific properties (To, From, Relation type) and have an attached entity that holds the rest of the properties defined on the relation. That is exactly what we have done.

Relations will now be made up of the following:

[1] Note: The id, type, to_entity, and from_entity values are immutable on these lightweight relations. If you need to change these immutable fields, you would need to delete the relation and create a new one. The new relation could point to the same relation entity, if desired.

[2] Note: you can now define a specific space or version of an entity you would like a relation to point to or from

[3] Note: if the entity is left blank, an entity ID will be generated and a blank entity will be used as the relation entity. But, you can now set a relation entity by ID, this enables hypergraph edges which I will detail below.

Geo UI update needed - Ability to re-use relation entities when creating a relation. Bonus capability to encourage the use of hypergraph edges for certain relation properties.

In the GRC-20 library, the CREATE_RELATION op will be used to create a new relation. The UPDATE_RELATION op or UNSET_RELATION_FIELDS op will be used to update any of the mutable values on a relation. The DELETE_RELATION op will be used to delete a relation.

First, let evaluate the previous GRC-20 data model. Imagine that we want to represent Yaniv’s relationship to Geo. Let’s create a “Works at” relation from Yaniv to Geo. Further, there could be a “Roles” relation stemming from the “Works at” relation signifying what role Yaniv has at Geo.

Extending our example, let's create Geo’s perspective on this working relationship as a “Team members” relation from Geo to Yaniv.

Note: the two “Roles” relations contain duplicate data. Since the GRC-20 update clearly separates lightweight relations from entities, we can re-use relation entities between different relations, which enables a concept known as a hypergraph edge (a relation with multiple inlets / outlets). Using a hypergraph edge, we can simplify the above data structure.

Now, let’s convert the our example to this new model. We get a much cleaner representation of the data.

In the previous data model, properties are defined as entities with "Types" "Property". "Value types" set on these property entities serve as hints to the knowledge graph for which value types should be used for a property. These hints however are not strict because the value types can be changes triple by triple on each entity.

First, we are changing our terminology from "Value type" to "Data type"

In order to improve indexing performance and data integrity, data types will now be set on the property. They will be immutable and they will be strictly enforced (i.e. you will no longer be able to change the data type of a property entity by entity).

To enable this functionality, we have separated a lightweight property where ID and Data type will be set globally and immutable. All other properties related to a property entity will be set on an entity with the same ID as the lightweight property.

Geo UI update needed - new flow to create lightweight property, define data type, and set other properties

In the GRC-20 library, the CREATE_PROPERTY op will be used to create a new property. Lightweight properties cannot be deleted.

In the new data model, we will be limiting the list of data types to those that impact indexing performance. See the list below.

Notice, that we have removed two common data types: Image and URL. These data types did not effect indexing at all because Images are just stored as relations and URLs are just stored as text. Instead, these only effect rendering. So, we are now adding the concept of a renderable type, where image, url or other render types can be set.

In the previous GRC-20 model, format options can be set value by value, similar to value types. Now, formats will also need to be set on the property. The only things that will be set on the value is language for text data types and currency for number data types. A default value for both can be set on the property entity but overridden on the value, if desired.

Notice that because these properties (renderable type, options, name, etc) are mutable, they can be adjusted space by space, using multi space entities. So, if you wanted to render the same property with a different name, you could turn it into a multi space entity and publish a different property name to use in your space. This same concept would work with renderable types and options.

This update to the GRC-20 data model will increase indexing performance and enable hypergraph edges. While these changes may seem significant they can be summarized in two categories: lightweight relations and lightweight properties. Further, migrating the data is entirely backwards compatible. In order to fit the new data into this spec, all we need to do is use existing relation ids as the id for a relation's entity and generate a new ID for the relation itself.