arangodb-community / arangordf Goto Github PK

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.

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)

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

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.

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)

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

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