MarcOnt/Projects/WMap/Meetings/2006 09 06

From Corrib Clan Wiki

monracc The meeting of WMap group concerned Versioning Plan for MarcOnt. A few ideas have been given:

• SemVers is no use, since it doesn't exist ;)
• YARS fourth element can be used to create a specific 'modification tree' - the root element of this tree would keep the RDF model and the children would contain its modifications
• implementing this kind of idea on the text layer would need to create a list of N3 triples in the root element and then a list of N3 triples that have been added, and then the list of N3 triples that have bben deleted
• then we came to a conclusion, that this still wouldn't be enough, Sebastian has brought a RdfList example which wouldn't work well with this idea (blank nodes are a problem)
• but why should we work on the text layer - normal versioning works that way, but that is because an atomic change in a text file is adding or removing a letter (a change of only one byte, so it's better to put all the changes alltogether) - in RDF and OWL an atomic change is always a change in the graph, so let's keep those atomic changes of the graph in the versioning system.
• so let's keep the original RDF model in the root file and keep the actions, that change the graph in the tree nodes. This can be possible in every system that let's you change the RDF model. If the model is changed via an RQL statement, let's keep the statement, if it's changed via a Jena method, let's keep this method's parameters.
• ok, so if we have a 1000 nodes' deep tree, we will need this system to take an original graph and put it through at least 1000 filters. We will get a graph that we wanted but it could take a hell lot of time. This can be optimised in an easy way - first, there is a possibility to (from time to time) keep the rendered version instead of a change, the more frequently this is done, the less time we need to render the version and the more database memory we are using. There surely is a compromise. Second thing - the ontology could be divided somehow into separate bags and each bag would have its own history tree. This idea is similiar to the threads idea, that we have written with Pawel about. This is needed because of the time/memory optimisation problem (easier to keep a rendered version of one bag, not of the whole ontology), because of the ontology size problem (right now it's more than 5 MB of data which makes it virtually impossible to work on it with a modem or ISDN - much easier to work only on one thread) and because of the sophistication problem (easier to focus on a fragment of ontology).
• how to divide this RDF graph is a modified metric k-center problem and there are some pseudooptimal solutions. This question is still open and some other questions arise (ie: what if someone changes something that is on the ede of two bags/threads and influences them both)