You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The motivation for this is to support slightly more familiar format that is less verbose to produce than raw facts. In addition, there are many workflows where facts are being generated from existing objects so this is convenient format to map to.
The proposed format is below:
{// Optional valid time of the facts."time": null,// Optional embedded domain of the facts."domain": "users",// Optional operation which defaults to "assert". If "retract" is used all// of the derived facts will be retracted."operation": "assert",// The identity of the entity the attributes are associated with. If// no domain is encoded in the identity, it will use the embedded// domain if one is supplied."entity": "bob",// Attribute-value pairs of the entity. All will be parsed therefore// references (such as `users/sue`) must have an explicit domain."attributes": {"origins.attrs/label": "Bob","name": "Bob","mobile": "555-1234","spouse": "users/sue"}}
This would be expanded into the following set of facts:
domain
operation
valid_time
entity_domain
entity
attribute_domain
attribute
value_domain
value
users
assert
users
bob
origins.attrs
label
Bob
users
assert
users
bob
users
name
Bob
users
assert
users
bob
users
mobile
555-1234
users
assert
users
bob
users
spouse
users
sue
The text was updated successfully, but these errors were encountered:
The motivation for this is to support slightly more familiar format that is less verbose to produce than raw facts. In addition, there are many workflows where facts are being generated from existing objects so this is convenient format to map to.
The proposed format is below:
This would be expanded into the following set of facts:
The text was updated successfully, but these errors were encountered: