Avoid storing each small changes in a separate file while using parallel worlds.

classic Classic list List threaded Threaded
2 messages Options
mAx
Reply | Threaded
Open this post in threaded view
|

Avoid storing each small changes in a separate file while using parallel worlds.

mAx
Hey,
i want to implement a simple graph search in an ontology. For that i have to store different changes in the database (e.g. add instances or change relations between instances), and load it later again for further modification and so on.


For that i tryed to used World(). However, World() needs for loading an own database. And each change have to be stored via .save(). It needs a lot of time to reach the goal in the graph search, if i have to load each world and write the changes in a seperate file, evan a triplet file.

So here are my questions:

1. Is it possible to store and load changed databases from cache to avoid wirting each small change in a separate file?

2. What could be a good practice to use parallel worlds, if the amount of parallel worlds are not predefined?
e.g.:

#init world_1
world_1 = World()
world_1_onto = world_1.get_ontology("path_to_world_1").load()
while True:

       world_1_onto = world_1.get_ontology("path_to_world_1.x").load()
       modify_world_1(world_1_onto)
       world_1_onto.save("path_to_world_1.x")
       world_1_onto.close() (OR?) world_1_onto.destroy()

3. Is there a other way to make changes in a default world, store it and load it for later changes? Maybe with destroy_entity(instance) in the same python object?


Thank you for any advise or recommendation :)
Reply | Threaded
Open this post in threaded view
|

Re: Avoid storing each small changes in a separate file while using parallel worlds.

Jiba
Administrator
Hi,

I see only 3 alternatives to the use of worlds:

 * Storing each version in a different ontology, with a different IRI. Using direct call to the SQLite inner database (with World.graph.execute), you can copy the RDF triple of an ontology to another ontology, and then modify it.

This solution would use a single database file, but still require to duplicate the data for each stored version.

 * Storing the ontology in a text file. If it is big, you may prefer the NTriples format which is much faster to parse. You can have one text file per version, or possibly use a versioning system like Git to avoid duplicating data.

 * Have a single ontology, and use annotations to indicate which fact have been added/removed. However, this requires to manage those annotations (e.g. you'll have to ignore removed facts that are still present but marked as removed).

Jiba