Dois modelos de grafo, propósitos diferentes. RDF (W3C, triplas, SPARQL) é orientado a interoperabilidade semântica e inferência. LPG (Neo4j, Cypher) é orientado a performance bruta de travessia e propriedades em arestas. Não é "qual é melhor" — é qual encaixa no seu problema.

Em uma tabela

RDFLPG (Neo4j)
StandardW3C (RDF, SPARQL, OWL, SHACL)De facto (Neo4j); GQL/openCypher ainda emergindo
UnidadeTripla (sujeito-predicado-objeto)Nó + relação rotulada com propriedades
IdentidadeURI globalmente únicaID interno do banco
Propriedade em arestaNão nativo (reification ou named graph)Nativo (relação tem propriedades direto)
Linguagem de querySPARQL (pattern matching)Cypher (caminho declarativo)
InferênciaOWL reasoner nativoNão — código de aplicação
Validação de schemaSHACLCypher constraints + opcional schema
FederaçãoSPARQL SERVICE (cross-endpoint)Limitado / via app
Interop públicoWikidata, DBpedia, schema.orgQuase nenhum dataset público
Performance travessiaBom; varia por engineExcelente (index-free adjacency)
Curva de aprendizadoAlta (URI, OWA, SPARQL, vocabulários)Média (Cypher é intuitivo)
EcosistemaJena, RDFox, Stardog, GraphDB, VirtuosoNeo4j (dominante), Memgraph, TigerGraph

A grande diferença filosófica

RDF é dados-como-fatos-com-significado. Toda URI tem semântica resolvível; vocabulários públicos garantem que sua tripla foaf:knows significa a mesma coisa que a tripla de qualquer outro. LPG é dados-como-grafo-otimizado. Você modela e otimiza para travessia. Significado é problema da sua aplicação.

Propriedade na aresta — o ponto sensível

Caso clássico: "Card A foi reprintada em Card B com erro de tradução em 1998". A relação tem propriedades (ano, motivo).

  • LPG nativo:(A)-[r:REPRINTED_AS {year: 1998, error: 'translation'}]->(B)
  • RDF (reification): precisa criar um recurso de Statement que descreva a tripla — verboso
  • RDF (RDF-star/RDF*): nova extensão que permite tripla sobre tripla nativamente
  • RDF (named graphs): separar o "contexto" da relação em outro grafo
Por que escolheria RDF em vez de Neo4j para um knowledge graph de produto?
Quatro razões típicas. (1) Integração — precisa unir dados de múltiplas fontes que usam vocabulários públicos (schema.org, Wikidata, GS1). (2) Inferência — quer que "Card é Permanent é Card" seja deduzido automaticamente, não codificado. (3) Padronização — empresa tem política de Linked Data, ou cliente expõe SPARQL endpoint. (4) Validação semântica — SHACL shapes versionadas como contrato de domínio. Se nenhuma dessas se aplica, Neo4j provavelmente é mais simples e mais rápido — não force RDF por estética.