It's in contrast to Object-Oriented Programming. In OOP, you define classes of objects, with behaviors/functionality attached to them.
In Bevy, the focus is on the data. The ECS is like a big table (if you are not familiar, you can think of it by analogy with a database or spreadsheet). It stores all your data. Components are like the columns of the table, and entities are like rows.
You then write functionality separately. You can query the ECS to get the data you need. Your logic is not attached to any particular "object instance" or "object type".
Broadly it means there's an emphasis on creating your content declaratively, often in a config file format (i.e., not in code). Saying "there's an entity X, it has these behaviors, it has these properties" in XML or JSON or whatever else. And then actual code is written separately, to handle specific logic that uses those declarative properties.
I'm sure somebody else can give a more precise definition
I personally consider us to be "both" (and we've ping-ponged back and forth on the right term to use in our taglines). Our app model is "data driven" in that we encourage users to drive logic off of raw data whenever possible and provide tools to respond to data changes. We are also "data oriented". We spend a lot of time optimizing our ECS data structures to maximize cache efficiency. We are _also_ "data driven" in that we try to use hard numbers to motivate design decisions whenever possible (although i consider that to be a secondary descriptor of the project).
In Bevy, the focus is on the data. The ECS is like a big table (if you are not familiar, you can think of it by analogy with a database or spreadsheet). It stores all your data. Components are like the columns of the table, and entities are like rows.
You then write functionality separately. You can query the ECS to get the data you need. Your logic is not attached to any particular "object instance" or "object type".