arangodb-community/arangordf

The RDF adapter for ArangoDB

arangordf's Issues

Input Directory Support

Add support for supplying a directory as an import location. Ideally, this could account for multiple formats either by ignoring files without the specified format or offer a way to supply multiple formats.

adb_graph = adb_rdf.import_rdf("./examples/data/", format=["xml", "ttl"], config=config, save_config=True)

Introduce basic test suite

We can use some of the ArangoRDF demo snippets listed in README.md and tests/test.py to create a set of unit tests via pytest. This should then solidify the reason for some CICD via Github Actions.

The following functionality should be tested:

• Import RDF into ArangoDB
• Export RDF from ArangoDB
• Re-import RDF export into ArangoDB
• Setting/getting configurations

Introduce CICD via Github Actions

Following #10, it would be best to create a set of Github Workflows to cover the following:

1. Code analysis via CodeQL action
2. Build/test automation (I.e install dependencies, lint codebase with black/isort, run tests via pytest, pubblish coverage to coveralls
3. Release automation (build automation, release via twine, update changelog)

Should not require access to _system

ArangoRDF/arango_rdf/main.py

Line 37 in e8f23b7

self.connection = ArangoClient(hosts=host)

Requiring _system level access does not seem necessary and is a blocker for many (including our tutorial notebooks)

RDF to Linked Property Graph Translation (Remove `import_ontology` methods)

Translate RDF to be more ArangoDB styled graph.
Possible additions:

• Initialize collections based on OWL/RDFS meta model via parsing supplied file/url
• Collections are created for RDF types (ex: song collection containing song documents)
  • Class collection containing classes (ex: document describing song class type)
• Literals become properties on statement documents

Currently, the import_ontology methods attempt to perform these operations, but the method name and current functionality are not functional and require a lot more work.

Implementing this translation method will align with the ArangoDB model better and offer better performance and analytics use cases.

Context Preserving for Statements Missing

Currently, on import, a statement is defined as an edge, and its _from and _to attributes are hashed values.

IRI/123 -> Statement/ea84082de (predicate) <- Literal/a4a (Fred)

This same statement could be generated in the event that the same IRI points towards Fred, and as the _key values are generated based on at least _type and _value, the documents will be updated by default and the same goes for the edge statement.

This is a correct outcome but does not fit 1-1 when attempting to export and isn't aware of the context for the statement. This could be describing a different Fred or the same thing could be being said about Fred by another person. So, even though it is the same statement, it could have a different context. This is currently not accounted for with our current implementation and should be addressed.

Consider bulk import into ArangoDB

The ArangoRDF import_rdf API is currently inserting RDF objects into ArangoDB one at a time, resulting in having to make at least one HTTP request per object to insert.

We should consider re-configuring how the RDF data is handled such that we can make use of https://docs.python-arango.com/en/dev/specs.html#arango.collection.StandardCollection.import_bulk