Zovda
An entity list with no relations is a glossary. A glossary is easy to build, easy to count, and hard to learn from, because nothing in it says how two entries interact.
Most relation datasets look better than they are for the same reason: the easy relations are dense and the interesting ones are absent.
Entities are not knowledge
Knowing that a paragraph mentions a drug, a dose, and a condition is extraction. Knowing that the dose applies to that condition and not the one in the previous sentence is the task.
Teams that stop at entities get a model that highlights names well and reasons about them badly.
The relation schema is the product
Write the schema before the annotation, and write it as decisions: what counts as a relation, what direction it runs, what happens when the sentence supports two readings.
Then measure coverage per relation. An aggregate count hides the fact that one relation type has forty examples and another has four.
Ambiguous mentions are where the value is
The same name referring to two different things in one document is not an edge case. It is the reason relation extraction is hard, and it is usually dropped during cleanup because it looks like an error.
Keep those rows, with the resolution written down. They are the ones that teach disambiguation.
Schema first, volume second
A small set with a complete schema beats a large set with one relation type. If the schema names six relations and the data has two, the model learns to find two and to invent the rest.
Zovda builds these collections through Datuva, where the relation schema and the rows that populate it are versioned together. The question bank collection shows the same discipline applied to structured answers.
Tell us the relations your model has to extract. We reply within one business day.