Ik weet niet zeker of ik het eens zou zijn met het gevoel dat veel mensen SPARQL niet leuk vinden. SPARQL 1.0 had enkele tekortkomingen, maar het pakte heel goed aan waarvoor het was ontworpen, en de nieuwe iteratie, SPARQL 1.1, bouwt erop voort door veel constructies van SQL toe te voegen die mensen verwachtten te zien in de originele specificatie, inclusief subquery's, aggregaten &semantiek bijwerken. Ik denk dat het feit dat het standaard is en je kunt verwachten dat je in elke triple store dezelfde ontleding en semantiek zult zien, in tegenstelling tot dialecten van SQL, een leuke functie is.
Ik zou ook beweren dat alle triple stores grafische databases zijn; je kunt eigenschappen op specifieke randen in RDF plaatsen, zij het niet zo mooi als je kunt met Neo4j. Maar triple stores hebben het voordeel van een echte querytaal, een w3c-standaardgegevensrepresentatie waardoor het triviaal is om uw gegevens naar een andere triplestore te brengen, en voor een aantal triplestores, de mogelijkheid om redeneringen uit te voeren op basis van OWL.
Ik weet niets over de schaalbaarheid voor de meeste grafische db's, maar over het algemeen schalen de commerciële RDF-databases vrij goed. Ze kunnen allemaal worden opgeschaald naar de miljarden triples, die een groot aantal use-cases afhandelen. Hoewel de manier waarop ze met schaal omgaan enorm verschilt van leverancier tot leverancier, wat betreft opschalen of uitschalen, clusteren, enz. Je zult ook behoorlijk verschillende mem- en hardwarevereisten zien om bij de implementaties voor elk te passen. Voor mij had ik de neiging om gewoon een EC2-instantie te pakken, meestal een 2XL of 4XL, een EBS te monteren die groot genoeg was om de gegevens te bevatten, en ik ben redelijk goed ingesteld.
Bovendien integreren sommige drievoudige winkels met Lucene of vergelijkbare technologieën om omgekeerde indexen over de gegevens te bieden, en velen beginnen nu georuimtelijke en tijdelijke indexen op te nemen. Dit zijn zeer handige functies waarvan ik niet zeker weet of ze beschikbaar zijn in zoiets als Neo4j.
Dat gezegd hebbende, ze zullen niet zo goed schalen als relationele databases, ze zijn gewoon niet zo volwassen. Maar je zult ook niet genaaid worden als je ook "echte" hoeveelheden gegevens hebt. Natuurlijk is een van de voordelen van triples-winkels redeneren, wat op schaal presteren lastig is, maar dat is voor een groot deel de reden waarom de verschillende OWL-profielen zijn gemaakt. Maar je kunt jezelf in een hoekje schilderen als je niet vooruit denkt.
Ik denk dat grafische databases, met name triple stores, een goede match kunnen zijn voor veel applicaties die worden gebouwd, maar ik denk niet dat dit betekent dat alles ermee moet worden gedaan. Net als al het andere zijn het tools met hun goede punten en hun slechte punten, dus je moet de juiste keuze maken op basis van je toepassing. Maar ze verdienen tegenwoordig waarschijnlijk altijd op zijn minst een overweging.