Later, as I was adding object properties to link my new classes together, I accidentally duplicated a property name and (very appropriately) received an error message and a refusal to create a duplicate property. I decided to change the first instance, so I renamed the old property and tried again to create the new property. I continued to get the error message until creating the new property with a new name, then editing it to change it back to the name I wanted. Somehow the duplication checker had out of date information about what names were already in use. The edit mode either works better, or doesn't employ a duplication checker at all.
Brian J Lowe added a comment - 28/Sep/12 12:59 PM
OK, this is behavior occurs because the URI dupe checker looks for any use of the URI anywhere in any triple, including inferred triples. When a property is deleted, inferred axioms using that property remain until Pellet has had time to finish reclassifying the TBox. This can take a few minutes. After the inferences are updated, the URI can be used again.
We may want to relax the dupe checker so it, for example, only checks for use of a URI as subject in triples where the predicate is rdf:type. But it doesn't seem appropriate to make this kind of change arbitrarily for a point release.
We should reconsider this for 1.6, and also consider whether the URI changer should employ the dupe checker. I think the assumption so far is the URI change is a power tool for someone who knows exactly what they want to accomplish, while the regular add property/class forms are more likely to be used by someone unfamiliar with the exact URIs of the ontology entities.
Jon Corson-Rikert (Migrated from VIVO-162) said:
Moved from https://issues.library.cornell.edu/browse/NIHVIVO-3914, dated 7/16/12:
Frances reports from her Vitro experience today:
Later, as I was adding object properties to link my new classes together, I accidentally duplicated a property name and (very appropriately) received an error message and a refusal to create a duplicate property. I decided to change the first instance, so I renamed the old property and tried again to create the new property. I continued to get the error message until creating the new property with a new name, then editing it to change it back to the name I wanted. Somehow the duplication checker had out of date information about what names were already in use. The edit mode either works better, or doesn't employ a duplication checker at all.
Brian J Lowe added a comment - 28/Sep/12 12:59 PM OK, this is behavior occurs because the URI dupe checker looks for any use of the URI anywhere in any triple, including inferred triples. When a property is deleted, inferred axioms using that property remain until Pellet has had time to finish reclassifying the TBox. This can take a few minutes. After the inferences are updated, the URI can be used again.
We may want to relax the dupe checker so it, for example, only checks for use of a URI as subject in triples where the predicate is rdf:type. But it doesn't seem appropriate to make this kind of change arbitrarily for a point release.
We should reconsider this for 1.6, and also consider whether the URI changer should employ the dupe checker. I think the assumption so far is the URI change is a power tool for someone who knows exactly what they want to accomplish, while the regular add property/class forms are more likely to be used by someone unfamiliar with the exact URIs of the ontology entities.