 |
 |
 |
 |
As software evolves, sometimes changes in the ontology are unavoidable. Tracker can transparently handle certain ontology changes on existing databases.
Adding a class.
Removing a class.
All resources will be removed from this class, and all related
properties will disappear.
Adding a property.
Removing a property.
The property will disappear from all elements pertaining to the
class in domain of the property.
Changing rdfs:range of a property.
The following conversions are allowed:
| xsd:integer to xsd:bool, xsd:double and xsd:string | |
| xsd:double to xsd:bool, xsd:integer and xsd:string | |
| xsd:string to xsd:bool, xsd:integer and xsd:double |
Adding and removing tracker:domainIndex from a class.
Adding and removing tracker:fulltextIndexed from a property.
Changing the tracker:weight on a property.
Removing nrl:maxCardinality from a property.
However, there are certain ontology changes that Tracker will find incompatible. Either because they are incoherent or resulting into situations where it can not deterministically satisfy the change in the stored data. Tracker will error out and refuse to do any data changes in these situations:
| Properties with rdfs:range being xsd:bool, xsd:date, xsd:dateTime, or any other custom class are not convertible. Only conversions covered in the list above are accepted. | |
| You can not add rdfs:subClassOf in classes that are not being newly added. You can not remove rdfs:subClassOf from classes. The only allowed change to rdfs:subClassOf is to correct subclasses when deleting a class, so they point a common superclass. | |
| You can not add rdfs:subPropertyOf to properties that are not being newly added. You can not change an existing rdfs:subPropertyOf unless it is made to point to a common superproperty. You can however remove rdfs:subPropertyOf from non-new properties. | |
| Properties can not move across classes, thus any change in rdfs:domain forbidden. | |
| You can not add nrl:maxCardinality restrictions on properties that are not being newly added. | |
| You can not add nor remove nrl:InverseFunctionalProperty from a property that is not being newly added. |
The recommendation to bypass these situations is the same for all, use different property and class names and use SPARQL to manually migrate the old data to the new format if necessary.
High level code is in a better position to solve the possible incoherences (e.g. picking a single value if a property changes from multiple values to single value). After the manual data migration has been completed, the old classes and properties can be dropped.