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. Le vendredi 26 février 2021 à 15:53:03 UTC+1, Irene Polikoff a écrit : > 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. > > > > On Feb 26, 2021, at 5:57 AM, tay.me <[email protected]> wrote: > > Thanks for your help and your time, it's clea for me and ask to my > questions. > > Le jeudi 25 février 2021 à 20:16:27 UTC+1, Irene Polikoff a écrit : > >> 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. >> >> On Feb 25, 2021, at 1:28 PM, tay.me <[email protected]> wrote: >> >> 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. >> >> Le jeudi 25 février 2021 à 19:10:00 UTC+1, Irene Polikoff a écrit : >> >>> 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? >>> >>> On Feb 25, 2021, at 10:44 AM, tayeb merabti <[email protected]> wrote: >>> >>> 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. >>> >>> -- >>> 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 [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/topbraid-users/1ad8e358-ee03-4fb9-816d-b2d9188d27can%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/topbraid-users/1ad8e358-ee03-4fb9-816d-b2d9188d27can%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> >>> >> -- >> 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 [email protected]. >> >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/topbraid-users/94b1cb48-f90c-4db7-bf4f-3568179b6845n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/topbraid-users/94b1cb48-f90c-4db7-bf4f-3568179b6845n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> >> > -- > 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 [email protected]. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/topbraid-users/6fab6b53-73cd-4a80-a38a-dfb96ce438d2n%40googlegroups.com > > <https://groups.google.com/d/msgid/topbraid-users/6fab6b53-73cd-4a80-a38a-dfb96ce438d2n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/467a7da1-ac1e-44b6-99e1-85693b41e306n%40googlegroups.com.
