I'm not sure the words themselves have significance here. The document you're referring to is simply calling out the base of our datamodel for the two different UDM object types (events and entities).
When you're writing a parser and wish to write a UDM event then all the fields that are mentioned in that document will need to be prefixed with event.idm.read_only_udm. Alternatively, when you're writing a parser and wish to include a UDM entity then all of the fields mentioned will be prefixed with entity.graph
In reality the name doesn't even have to begin with event or entity, it can begin with any string, but for the sake of readability we stick to event/entity. You could use the prefix my_awesome_event_like_object.idm.read_only_udm or no_enitity_to_be_seen_here.graph as long as the rest of the fields are kept correct. You just have to make sure that the final merge into @output is done correctly
mutate {
merge => { "@output" => "my_awesome_event_like_object" }
}
or
mutate {
merge => { "@output" => "no_entity_to_be_seen_here" }
}
There are underlying reasons for the naming scheme that have to do with the protobuf definitions, but that doesn't really explain it any better nor does it have any impact on the way things are written. Just consider <something>.idm.read_only_udm and the corresponding <something>.graph to be a requirement.
I suspect that someone could probably explain the historical reasons for the naming scheme, but that will be getting more into the equivalent of the etymology of a word versus the definition of it.
LinkedIn
Twitter
