Possible synchronization issues

Whenever changes are done to a model such as deleting or adding resources, Composer buffers the changes and does not immediately commit them to the server. Changes are only committed when you save the file. This approach not only allows you to discard changes that you didn't mean to share, but is also more efficient: all changes can be committed to the server in a single transaction.

As a consequence of this change model, and the fact that each Composer client maintains a local cache of certain values, your co-workers may not immediately "see" the changes that you have committed in their user interface. For example, if user A creates and saves a new instance of Person, then user B may not see this new Person immediately on his machine because the instances may be accessed from its local cache. Similarly, if user A deletes a class, TopBraid Composer would also delete associated statements as well as any resource that belongs only to the deleted class. After A saves changes, user B may still have deleted resources and triples in his local cache and may be building connections to them. As a result, when user B saves his changes, they may contain some "dangling references' to deleted resources.

If user B wants to make sure he sees the recent changes made by others, he needs to explicitly refresh, using Model > Refresh all database caches and windows. This will rebuild the caches from the server and re-populate all open windows such as the class tree.

Note that in order to get to see all changes, it may also be required to reset the inferences, using the Reset inferences button in the main tool bar. This is not done by default because computing the default inferences may be a lengthy process. However, for example if a co-worker has added a new top-level class to the hierarchy, you will need to reset the inferences because otherwise your local client will not "know" that the new class is positioned right under owl:Thing.

In order to ensure that no "conflicts" arise in multi-user mode, you may want to perform a refresh immediately prior to committing your changes to the server. This way, you can find out whether someone else has deleted a resource that you have annotated etc. Refreshing your caches will not delete your local modifications, but you can decide to not commit them after you have seen what else has changed in the meantime. You may also need to coordinate changes with your team members using instant messaging and other collaboration tools.

Exporting into and from repositories

You can use the Export Wizard to write RDF data from other formats into remote repositories and back. This wizard can be used to populate an empty repository on the server with existing data, for example from a local database or file.

Backing up data

Like with all large scale database solutions, your administrators should set up back-up facilities so that you can roll-back to previous snapshots of data and recover from errors caused by network outages, etc. Please find the corresponding settings and instructions in the database manuals.

Combining database connection files

While the database connection files are placeholders for a repository connection, you can use the Project Explorer to open them just like any other RDF model. You can also import them into other models. In principle you can mix any type of Composer back-end with any other one, for example to have a hybrid project that has a private ontology file, a local database, a D2RQ database and one or more remote repositories. Note, however, that the more repositories you add to your project, the slower the performance will be, because queries need to be issued to all sub-models.