I’m not 100% sure, but a basic ecommerce site I think would be a classic example for a relational data model or key-value data model if you want to be fancy. Assuming the former, we’d then expect that in this data domain we could only come up with one maybe two predicates.
Without thinking too hard and deep, this seems true. An Order HAS Items, an item HAS a price, a customer HAS Orders, Addresses, etc.
I think you’d get quite far modelling the entire problem just with HAS.
But "has" isn't a predicate. "Has" is a relation. If we take "has an item" an "has a price" and "has an order" to be predicates, then we already have three predicates. So that can't be the definition of predicate.
Yes HAS is a relation, but in my example it's also the predicate.
A predicate is a statement that may be true or false depending on the values of its variables. In my example we'd have HAS(order_i, item_2), where both the order and the item are variables (or vertices) in our graph.
It wouldn't make sense to model with HAS_AN_ITEM(order_i), because as you say you'd proliferate predicates all over the place when you introduce new entities.
So yes, HAS is a predicate, and it handles nicely models a shopping cart.
DGraph models this with a 'PostingList' anchored on the predicate (they call it the "attribute"). This model is not particularly advantageous though in this shopping cart case as using a single HAS predicate means that in practice almost every 'PostingList' will have the same predicate and thus we will more often find ourselves joining across PostingLists when doing single predicate queries, which shouldn't happen.
Without thinking too hard and deep, this seems true. An Order HAS Items, an item HAS a price, a customer HAS Orders, Addresses, etc.
I think you’d get quite far modelling the entire problem just with HAS.