Update local ontology when import ontologies were updated

[tayeb merabti]

Using TopBraid, I build a new ontology (Ont1). On this ontology I created one class (c1) and import two external ontologies (using the include function under settings).

From the class that I created I added two sublcasses (sb1, sb2) from each one from the onotology that I created : sb1 rdfs:subClassOf c1 and sb2 rdfs:subClassOf c1

Suppose now that I want to delete the class sb1 in the original ontology. In my Ont1, the class is deleted but only in the tree, If I run the sparql query : select ?c where {?c rdfs:subClassOf c1} I still found the sb1 in my Ont1. I think it is a bug or maybe I skip something ??

Thanks for your help.

[Irene Polikoff]

Where did you add sb1 rdfs:subClassOf c1 statement? This sounds like you:

1. Created Ont1 and c1 in it

2. Then, added sb1 and sb2 as subclasses of c1. Where and how did you do it:

Created sb1 as a subclass of c1 in Ont1?

Created sb1 as a subclass of c1 in some other ontologies?

Created sb1 in one ontology and created sb1 rdfs:subClassOf c1 statement in another ontology?

--
You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/1ad8e358-ee03-4fb9-816d-b2d9188d27can%40googlegroups.com.

[tay.me]

Thanks.

  So, I created sb1 as a subclass of c1 in Ont1, but sb1 is a class from another ontology imported. Now, If I deleted sb1 from the original ontology, I can see in the tree that sb1 is not available but in the source of the ontology, sb1 still exists.

[Irene Polikoff]

I am still not 100% sure what statement is where, but:

Let’s say sb1 is defined in Ont A

Let’s say c1 is defined in Ont B which includes A

Let’s say the statement sb1 rdfs:subClassOf c1 is stated in B

You can’t delete sb1 in B - because sb1 is defined in A. In B, you can only remove the subclass relationship between sb1 and c1.

You can delete sb1 in A, but that does not remove the sb1 rdfs:subClassOf c1 that is stored in B. Now, you could have a situation where all information about sb1 is gone (e.g., its label, the fact that it is a class, etc.), except the rdfs:subClassOf relationship between it and c1. Thus, sb1 will no longer appear in the class tree (because it is not known to be a class), but the subclass triple will be there.

When you are dealing with a resource defined in another graph, but you added some information to it in your current graph, you need to first remove all statements in your graph and then remove the resource in its home graph. Otherwise, you will still have these remaining triples. You could remove them afterwords as well, but it becomes harder to find them.

In the upcoming 7.0 release, there are some operations that will update multiple graphs, but these operations are geared towards changing data across graphs to accommodate model updates, not changing model statements distributed across graphs. 

For example, if you need to remove a property from an ontology, you could in 7.0 request to delete all values for the property across graphs as you update the ontology. E.g., if you had a property called “date of birth”, you could delete all "date of birth" values irrespective of where they were stored. Or if you were changing the datatype of a property from let's say an integer to a string. Below are these new options:

This will not help in your situation since you are deleting a class to which you have references in another ontology.

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/94b1cb48-f90c-4db7-bf4f-3568179b6845n%40googlegroups.com.

[tay.me]

Thanks for your help and your time, it's clea for me and ask to my questions.

[Irene Polikoff]

I also want to add that when you are not in a home graph of a resource, you see that e.g., the blue “Defined in …” link shown below the resource name - to the right of the URI.

This link only appears if this is not the home graph of the resource. It is clickable, so you could first remove the editable statements from the current graph (if any) by, for example, clicking on the Edit button. This will open for edit whatever fields are editable. Although with classes, it is more complex - you may have some properties defined in this graph and some in another, so you should check this out as well. In this case, I would look at the Source Code panel to see what triples are here.

Then, after you deleted the statements you were going to delete, you can click on the blue “Defined in …” link to go to the home graph and delete the resource there.

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/6fab6b53-73cd-4a80-a38a-dfb96ce438d2n%40googlegroups.com.

[tay.me]

Thanks Irene. I see that, but in my use case the idea is:  I have the right on my ontology only so If I made a delete in my local ontology It's not mandatory  to make  delete in the external graph. But, it's important when someone (another expert)  delete in the external ontology a class that I used in my local ontology to at least can capture this information so that I can do it automatically or manually, since the class will become obsolete. When I say delete I mean any kind of update : change the label, add synonyms  or delete.

Thank you again for your help and your time I will try to handle this.