How do SPARQL and RDF relate to AQL and ArangoDB?
SPARLQ is a language designed to work on top of RDF, so we first need to compare data stores:
RDF VS. ArangoDB Collections
While both refer to their entities as a “document," they are different in many ways. Although RDF provides schemas even with custom data types , ArangoDB is schematic and only supports specific json data types. RDF uses a construct derived from the XML namespaces for these data types. These namespaces can be nested. There are implementations storing RDF in SQL databases. Obviously, RDF grammars must be translated into ArangoDB collections (similar to these things RDF / SQL). The Foxx service layer can provide an abstraction that implements these additional data types; mapping a single namespace to a single collection is likely to result in many collections with very few documents.
As Wikipedia describes this in its article on the Resource Description Framework :
For example, one way to represent the notion "The sky has the color blue" in RDF is as the triple: a subject denoting "the sky", a predicate denoting "has", and an object denoting "the color blue". Therefore, RDF swaps object for subject that would be used in the classical notation of an entity–attribute–value model within object-oriented design; Entity (sky), attribute (color) and value (blue). RDF is an abstract model with several serialization formats (ie, file formats), and so the particular way in which a resource or triple is encoded varies from format to format.
While RDF has its triple model, ArangoDB is more likely to use an object-oriented design.
So, we have this source model in RDF:
sky -hasColor-> blue
Let's try to compare this model with ArangoDB:
If we emulate that this is "similar" to RDF, the namespace will be a collection, each document is an entity in this namespace:
Collection "Objects": Document "sky": {_key: "Sky"} Collection "Colors": Document "blue": {_key: "blue"} EdgeCollection "hasColor" Edge {_from: "Objects/sky", _to: "Colors/blue"}
Object-oriented aproach as its native to ArangoDB (and thus allows it to scale best) translates into something like this:
Collection "Object": { _key: "sky" "hasColor": "blue" }
The second aproach uses the fact that instead of a meta-view of your data, you already have a rather sharp image of your data, you can specify indexes (i.e. On hasColor ) for better query performance. While the first approach is a flat mapping of the RDF for ArangoDB will produce a lot of overhead; many collections with many very simple documents, without any indicators.
SPARQL vs AQL
While you can map the basic set of SPARQLs WHERE clauses - in AQL FILTER expressions - in the Foxx service (and possibly join other collections) using the easily accessible javascript analyzer, SPARQL may be inevitable, but it may not give the correct results.
I also experimented with some javascript RDF parsers to parse some of the publicly available RDF datasets to import into ArangoDB, but it looks like these js parsers are not yet ready for prime time.
Conclusion
If there are overlaps between RDF + SPARQL and ArangoDB + AQL, there are also significant gaps that need to be filled. While we will support others filling these gaps, we currently cannot focus on this. To ensure a satisfactory experience with ArangoDB, in the end one could rely on manual translation of the RDF schema, which most likely could not be requested by automatically translated SPARQL.
Steps that could be taken:
- find / fix parser RDF
- find the smart (er) method than above to automatically convert the RDF schema to a collection schema that scales well with ArangoDB
- Use the parser to analyze SPARQL and accept it to the specified schema and build AQL.