EAV vs SPO

Knowledge Representation has been around for a long time, within database architecture, but also within abstractions of domain logic especially in area of analytics. There have been various formalisms defined for representation of such knowledge in order to derive a more structured logic for learning and reasoning from data. Databases have historically provided the persistence layer for many applications and usually hold the key to unlocking a lot of the data today. However, good data representation allows for versatility, performance, and unlocking hidden knowledge. Entity-Attribute-Value (EAV) and Subject-Predicate-Object (SPO) are similar in modelling approaches. In both cases, one is working with relationship by 3-tuples. However, EAV is a subset of SPO. Often, people who are not familiar with SPO and are more comfortable with the relational model design end up utilizing EAV, as an extension. However, in most cases, EAV is seen as an anti-pattern leading to higher development times, poor utilization of data, and undesirably more complex queries. In SPO, everything is treated as a resource and extended in a graph representation. It also allows for better reasoning capabilities for inference. SPO also lends very well to the architecture of the web, utilizing URI schemas, in a linked context, as an extension to the RESTful approach of using standard HTTP methods. On one hand, the EAV tries to build richer metadata semantics through a schema taxonomy, as an extension to the database relational model. While, in SPO the approach is more synonymous to ontologies in form of extensible linked data schema for a domain context, which is not only web friendly, but also machine readable. SPO is also linguistically inspired from natural language.

eav and spo
eav/cr model
rdf
SPO
considerations for eav
considerations for modelling eav for biomedical databases
magento eav
eav talk
understanding linked data via eav model