Problem with deprecated classes and label-sharing

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Problem with deprecated classes and label-sharing

Chris Mungall-2
In bio-ontologies it's customary for an rdfs:label to uniquely identify a class within an ontology. The exception is deprecated classes - it's common to deprecate a class and create a new class with a different IRI that shares the same rdfs:label as the deprecated class.

This is causing a number of problems with an ontology I am working on. It's as if Protege is over-eager in making a unique label assumption.

I haven't been able to reduce this to a small test case, but the behavior can be seen on this ontology:

        http://purl.obolibrary.org/obo/uberon/releases/2012-08-09/uberon.owl

I have a non-deprecated class called "ureter" with logical axioms:

  Class: <http://purl.obolibrary.org/obo/UBERON_0000056>

    Annotations:
        rdfs:label "ureter"^^xsd:string,
        ...
   
    SubClassOf:
        ...    

And a deprecated class with the same label, with no logical axioms:

  Class: <http://purl.obolibrary.org/obo/UBERON_0001055>

    Annotations:
       
        owl:deprecated true,
        rdfs:label "ureter"^^xsd:string,
        <http://www.geneontology.org/formats/oboInOwl#consider> "UBERON:0000056"^^xsd:string,
        <http://www.geneontology.org/formats/oboInOwl#consider> "UBERON:0000057"^^xsd:string,
        ...

Unfortunately, Protege is confusing these to the extent that it's
impossible to work with this ontology.

Problem 1:

when I try and search for "ureter" in the search box, it only offers
me one "ureter", and it is rendered with strikethrough
(i.e. deprecated). When I select it, it brings me to the deprecated
class (1055).

I would expect to either see both classes labeled "ureter" offered,
one rendered in strikethrough. As it is, I have no way of navigating to
the non-deprecated class (56) through the search box.

Problem 2:

When I use the annotation search plugin, both classes are offered when
I do a regexp search for "ureter". However, *both* are rendered in
strikethrough. When I mouse-over I can see that one is the
non-deprecated, and the other is the deprecated. When I click on
*either*, it always takes me to the deprecated one. Again, there is no
way to navigate to the correct class.

This suggests it's not just a rendering issue, but that the conflation
is deeper.

Problem 3:

I have a class "left ureter" that is a subclass of the non-deprecated "ureter":

  Class: <http://purl.obolibrary.org/obo/UBERON_0001223>

    Annotations:
        rdfs:label "left ureter"^^xsd:string,
        ...
       
    SubClassOf:
        <http://purl.obolibrary.org/obo/UBERON_0000056>,
        ...

However, when I look at this class in the "Descriptions" tab, it
renders the superclass with a strikethrough. When I click on it, it
takes me to the deprecated class, even though there is no axiom that
connects my "left ureter" with the deprecated class.

This is 4.2.0 build 269 on OS-X. I have observed similar behavior with 4.1 (with the "D"
rather than strikethrough)
_______________________________________________
p4-feedback mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/p4-feedback
Reply | Threaded
Open this post in threaded view
|

Re: Problem with deprecated classes and label-sharing

Alan Ruttenberg-2
FWIW, OBI always (well, when I last looked) adds the prefix "obsolete_" to labels of obsolete terms to avoid exactly this problem. It also serves as warning to users who inadvertently still use the term.
However the problem with duplicated labels is still a problem. I'd also like to see multiple entries when there are multiple hits, and while we're at it some additional flexibility in completion - I often need to search by URI localname, or by another synonym and it would be nice if I could tell protege that I'd like the completion scope to be wider. 

Moreover this problem can happen if one uses the same URI for both a property and a class, or a class and an instance. I don't think protege is particularly good at supporting punning at the moment, but as soon as it does we'll have this same problem with one string identifying conceptually different entities in protege.

Also I'm never sure where I will land up if, for example, I select an instance in the completion list. A nice bit would be able to let me say which tab/view I'd like to switch to when I select an entity of each type. Minor complication - if I've run the reasoner I would like to see an inferred view if there is one. So perhaps a list of tabs/view to try for each type, as the preference.

Sigh, once I start it's hard to stop. One more suggestion. Integrate the annotation search into the single search box. How about if the first character in the search box is a "," then the rest is taken as a full annotation search.

Best, 

-Alan


On Fri, Aug 10, 2012 at 12:14 PM, Chris Mungall <[hidden email]> wrote:
In bio-ontologies it's customary for an rdfs:label to uniquely identify a class within an ontology. The exception is deprecated classes - it's common to deprecate a class and create a new class with a different IRI that shares the same rdfs:label as the deprecated class.

This is causing a number of problems with an ontology I am working on. It's as if Protege is over-eager in making a unique label assumption.

I haven't been able to reduce this to a small test case, but the behavior can be seen on this ontology:

        http://purl.obolibrary.org/obo/uberon/releases/2012-08-09/uberon.owl

I have a non-deprecated class called "ureter" with logical axioms:

  Class: <http://purl.obolibrary.org/obo/UBERON_0000056>

    Annotations:
        rdfs:label "ureter"^^xsd:string,
        ...

    SubClassOf:
        ...

And a deprecated class with the same label, with no logical axioms:

  Class: <http://purl.obolibrary.org/obo/UBERON_0001055>

    Annotations:

        owl:deprecated true,
        rdfs:label "ureter"^^xsd:string,
        <http://www.geneontology.org/formats/oboInOwl#consider> "UBERON:0000056"^^xsd:string,
        <http://www.geneontology.org/formats/oboInOwl#consider> "UBERON:0000057"^^xsd:string,
        ...

Unfortunately, Protege is confusing these to the extent that it's
impossible to work with this ontology.

Problem 1:

when I try and search for "ureter" in the search box, it only offers
me one "ureter", and it is rendered with strikethrough
(i.e. deprecated). When I select it, it brings me to the deprecated
class (1055).

I would expect to either see both classes labeled "ureter" offered,
one rendered in strikethrough. As it is, I have no way of navigating to
the non-deprecated class (56) through the search box.

Problem 2:

When I use the annotation search plugin, both classes are offered when
I do a regexp search for "ureter". However, *both* are rendered in
strikethrough. When I mouse-over I can see that one is the
non-deprecated, and the other is the deprecated. When I click on
*either*, it always takes me to the deprecated one. Again, there is no
way to navigate to the correct class.

This suggests it's not just a rendering issue, but that the conflation
is deeper.

Problem 3:

I have a class "left ureter" that is a subclass of the non-deprecated "ureter":

  Class: <http://purl.obolibrary.org/obo/UBERON_0001223>

    Annotations:
        rdfs:label "left ureter"^^xsd:string,
        ...

    SubClassOf:
        <http://purl.obolibrary.org/obo/UBERON_0000056>,
        ...

However, when I look at this class in the "Descriptions" tab, it
renders the superclass with a strikethrough. When I click on it, it
takes me to the deprecated class, even though there is no axiom that
connects my "left ureter" with the deprecated class.

This is 4.2.0 build 269 on OS-X. I have observed similar behavior with 4.1 (with the "D"
rather than strikethrough)
_______________________________________________
p4-feedback mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/p4-feedback


_______________________________________________
p4-feedback mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/p4-feedback
Reply | Threaded
Open this post in threaded view
|

Re: Problem with deprecated classes and label-sharing

Timothy Redmond
In reply to this post by Chris Mungall-2

I know about this problem and wrote a GForge [1] for it some time back.  
I thought at the time that it was an edge case but I did not consider
your situation.  I will talk to Matthew about what would be involved in
a fix.  (There are some obvious difficulties such as the possibility of
an interface change that will break plugins...).

> Moreover this problem can happen if one uses the same URI for both a
> property and a class, or a class and an instance. I don't think
> protege is particularly good at supporting punning at the moment, but
> as soon as it does we'll have this same problem with one string
> identifying conceptually different entities in protege.

I think that the punning case works much better.  It is true that the
search for a punned object only turns up one match (I will add this to
the GForge) but editing axioms often works.  In particular I was able to
create the axiom:

           C owl:EquivalentTo p value C and p some C.


Having the same name for two different entities of the same type creates
somewhat more havoc in Protege.

-Timothy


[1] https://bmir-gforge.stanford.edu/gf/project/owleditor/tracker/?action=TrackerItemEdit&tracker_item_id=3503&start=0


On 08/10/2012 09:14 AM, Chris Mungall wrote:

> In bio-ontologies it's customary for an rdfs:label to uniquely identify a class within an ontology. The exception is deprecated classes - it's common to deprecate a class and create a new class with a different IRI that shares the same rdfs:label as the deprecated class.
>
> This is causing a number of problems with an ontology I am working on. It's as if Protege is over-eager in making a unique label assumption.
>
> I haven't been able to reduce this to a small test case, but the behavior can be seen on this ontology:
>
> http://purl.obolibrary.org/obo/uberon/releases/2012-08-09/uberon.owl
>
> I have a non-deprecated class called "ureter" with logical axioms:
>
>    Class: <http://purl.obolibrary.org/obo/UBERON_0000056>
>
>      Annotations:
>          rdfs:label "ureter"^^xsd:string,
>          ...
>      
>      SubClassOf:
>          ...
>
> And a deprecated class with the same label, with no logical axioms:
>
>    Class: <http://purl.obolibrary.org/obo/UBERON_0001055>
>
>      Annotations:
>          
>          owl:deprecated true,
>          rdfs:label "ureter"^^xsd:string,
>          <http://www.geneontology.org/formats/oboInOwl#consider> "UBERON:0000056"^^xsd:string,
>          <http://www.geneontology.org/formats/oboInOwl#consider> "UBERON:0000057"^^xsd:string,
>          ...
>
> Unfortunately, Protege is confusing these to the extent that it's
> impossible to work with this ontology.
>
> Problem 1:
>
> when I try and search for "ureter" in the search box, it only offers
> me one "ureter", and it is rendered with strikethrough
> (i.e. deprecated). When I select it, it brings me to the deprecated
> class (1055).
>
> I would expect to either see both classes labeled "ureter" offered,
> one rendered in strikethrough. As it is, I have no way of navigating to
> the non-deprecated class (56) through the search box.
>
> Problem 2:
>
> When I use the annotation search plugin, both classes are offered when
> I do a regexp search for "ureter". However, *both* are rendered in
> strikethrough. When I mouse-over I can see that one is the
> non-deprecated, and the other is the deprecated. When I click on
> *either*, it always takes me to the deprecated one. Again, there is no
> way to navigate to the correct class.
>
> This suggests it's not just a rendering issue, but that the conflation
> is deeper.
>
> Problem 3:
>
> I have a class "left ureter" that is a subclass of the non-deprecated "ureter":
>
>    Class: <http://purl.obolibrary.org/obo/UBERON_0001223>
>
>      Annotations:
>          rdfs:label "left ureter"^^xsd:string,
>          ...
>          
>      SubClassOf:
>          <http://purl.obolibrary.org/obo/UBERON_0000056>,
>          ...
>
> However, when I look at this class in the "Descriptions" tab, it
> renders the superclass with a strikethrough. When I click on it, it
> takes me to the deprecated class, even though there is no axiom that
> connects my "left ureter" with the deprecated class.
>
> This is 4.2.0 build 269 on OS-X. I have observed similar behavior with 4.1 (with the "D"
> rather than strikethrough)
> _______________________________________________
> p4-feedback mailing list
> [hidden email]
> https://mailman.stanford.edu/mailman/listinfo/p4-feedback

_______________________________________________
p4-feedback mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/p4-feedback
Reply | Threaded
Open this post in threaded view
|

Re: Problem with deprecated classes and label-sharing

mhaendel
In reply to this post by Chris Mungall-2
Hi all,
 
A plea to please prioritize fixing this - it is really a problem for us. Also happy to help test anytime.

Cheers,
Melissa

On Aug 10, 2012, at 9:14 AM, Chris Mungall wrote:

In bio-ontologies it's customary for an rdfs:label to uniquely identify a class within an ontology. The exception is deprecated classes - it's common to deprecate a class and create a new class with a different IRI that shares the same rdfs:label as the deprecated class.

This is causing a number of problems with an ontology I am working on. It's as if Protege is over-eager in making a unique label assumption.

I haven't been able to reduce this to a small test case, but the behavior can be seen on this ontology:

http://purl.obolibrary.org/obo/uberon/releases/2012-08-09/uberon.owl

I have a non-deprecated class called "ureter" with logical axioms:

 Class: <http://purl.obolibrary.org/obo/UBERON_0000056>

   Annotations:
       rdfs:label "ureter"^^xsd:string,
       ...

   SubClassOf:
       ...    

And a deprecated class with the same label, with no logical axioms:

 Class: <http://purl.obolibrary.org/obo/UBERON_0001055>

   Annotations:

       owl:deprecated true,
       rdfs:label "ureter"^^xsd:string,
       <http://www.geneontology.org/formats/oboInOwl#consider> "UBERON:0000056"^^xsd:string,
       <http://www.geneontology.org/formats/oboInOwl#consider> "UBERON:0000057"^^xsd:string,
       ...

Unfortunately, Protege is confusing these to the extent that it's
impossible to work with this ontology.

Problem 1:

when I try and search for "ureter" in the search box, it only offers
me one "ureter", and it is rendered with strikethrough
(i.e. deprecated). When I select it, it brings me to the deprecated
class (1055).

I would expect to either see both classes labeled "ureter" offered,
one rendered in strikethrough. As it is, I have no way of navigating to
the non-deprecated class (56) through the search box.

Problem 2:

When I use the annotation search plugin, both classes are offered when
I do a regexp search for "ureter". However, *both* are rendered in
strikethrough. When I mouse-over I can see that one is the
non-deprecated, and the other is the deprecated. When I click on
*either*, it always takes me to the deprecated one. Again, there is no
way to navigate to the correct class.

This suggests it's not just a rendering issue, but that the conflation
is deeper.

Problem 3:

I have a class "left ureter" that is a subclass of the non-deprecated "ureter":

 Class: <http://purl.obolibrary.org/obo/UBERON_0001223>

   Annotations:
       rdfs:label "left ureter"^^xsd:string,
       ...

   SubClassOf:
       <http://purl.obolibrary.org/obo/UBERON_0000056>,
       ...

However, when I look at this class in the "Descriptions" tab, it
renders the superclass with a strikethrough. When I click on it, it
takes me to the deprecated class, even though there is no axiom that
connects my "left ureter" with the deprecated class.

This is 4.2.0 build 269 on OS-X. I have observed similar behavior with 4.1 (with the "D"
rather than strikethrough)
_______________________________________________
p4-feedback mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/p4-feedback

Dr. Melissa Haendel

Assistant Professor
Ontology Development Group, OHSU Library
Department of Medical Informatics and Epidemiology
Oregon Health & Science University
[hidden email]
skype: melissa.haendel
503-407-5970



_______________________________________________
p4-feedback mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/p4-feedback
Reply | Threaded
Open this post in threaded view
|

Re: Problem with deprecated classes and label-sharing

Timothy Redmond
On 8/14/12 11:05 AM, Melissa Haendel wrote:
Hi all,
 
A plea to please prioritize fixing this - it is really a problem for us. Also happy to help test anytime.

I talked with Matthew about this a bit.  There are actually several problems with distinct solutions.  They all involve ontologies that have entities of the same type that have the same rendering.

First, there is a problem with some of the renderers.  The renderers are rendering strings rather than entities and this means that sometimes when Protege should know which entity is being rendered it renders the other one.  Thus for example, the super class of 'left ureter' is the undeprecated 'ureter' but when the string 'ureter' is rendered you see the deprecated version.  It will take a bit of work to fix this one.  I don't know this code but Matthew does.

There is the problem with the search box at the top right hand side of the screen.  This is probably easy to fix.  It needs to be completely replaced; it has many problems which we are constantly working around.  The new version will not use the entity finding code but will have a separate search capability which will be able to
  • find entities by their IRI,
  • find entities by any annotation property value (maybe with some priority order?)
  • find entites with axioms involving a literal that matches the search string

The search box also has problem even when an entity is punned but if we are replacing this altogether this should also be fixed.





There is a problem when clicking on entites and when editing entities in axiom editors.  This is an awkward bug but there is a workaround that may work.  There are user interface and backwards compatibility issues.  The problem is that there are cases where the rendered versions of axioms are ambiguous and it is not clear how to nicely disambiguate them.  A hack that might work would be to modify the entity finder so that if there is a deprecated and non-deprecated entity with the same rendering, the non-deprecated entity wins.

The annotation search plugin is a co-ode plugin and not directly supported here.  We will have to look at this one.

-Timothy



Cheers,
Melissa

On Aug 10, 2012, at 9:14 AM, Chris Mungall wrote:

In bio-ontologies it's customary for an rdfs:label to uniquely identify a class within an ontology. The exception is deprecated classes - it's common to deprecate a class and create a new class with a different IRI that shares the same rdfs:label as the deprecated class.

This is causing a number of problems with an ontology I am working on. It's as if Protege is over-eager in making a unique label assumption.

I haven't been able to reduce this to a small test case, but the behavior can be seen on this ontology:

http://purl.obolibrary.org/obo/uberon/releases/2012-08-09/uberon.owl

I have a non-deprecated class called "ureter" with logical axioms:

 Class: <http://purl.obolibrary.org/obo/UBERON_0000056>

   Annotations:
       rdfs:label "ureter"^^xsd:string,
       ...

   SubClassOf:
       ...    

And a deprecated class with the same label, with no logical axioms:

 Class: <http://purl.obolibrary.org/obo/UBERON_0001055>

   Annotations:

       owl:deprecated true,
       rdfs:label "ureter"^^xsd:string,
       <http://www.geneontology.org/formats/oboInOwl#consider> "UBERON:0000056"^^xsd:string,
       <http://www.geneontology.org/formats/oboInOwl#consider> "UBERON:0000057"^^xsd:string,
       ...

Unfortunately, Protege is confusing these to the extent that it's
impossible to work with this ontology.

Problem 1:

when I try and search for "ureter" in the search box, it only offers
me one "ureter", and it is rendered with strikethrough
(i.e. deprecated). When I select it, it brings me to the deprecated
class (1055).

I would expect to either see both classes labeled "ureter" offered,
one rendered in strikethrough. As it is, I have no way of navigating to
the non-deprecated class (56) through the search box.

Problem 2:

When I use the annotation search plugin, both classes are offered when
I do a regexp search for "ureter". However, *both* are rendered in
strikethrough. When I mouse-over I can see that one is the
non-deprecated, and the other is the deprecated. When I click on
*either*, it always takes me to the deprecated one. Again, there is no
way to navigate to the correct class.

This suggests it's not just a rendering issue, but that the conflation
is deeper.

Problem 3:

I have a class "left ureter" that is a subclass of the non-deprecated "ureter":

 Class: <http://purl.obolibrary.org/obo/UBERON_0001223>

   Annotations:
       rdfs:label "left ureter"^^xsd:string,
       ...

   SubClassOf:
       <http://purl.obolibrary.org/obo/UBERON_0000056>,
       ...

However, when I look at this class in the "Descriptions" tab, it
renders the superclass with a strikethrough. When I click on it, it
takes me to the deprecated class, even though there is no axiom that
connects my "left ureter" with the deprecated class.

This is 4.2.0 build 269 on OS-X. I have observed similar behavior with 4.1 (with the "D"
rather than strikethrough)
_______________________________________________
p4-feedback mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/p4-feedback

Dr. Melissa Haendel

Assistant Professor
Ontology Development Group, OHSU Library
Department of Medical Informatics and Epidemiology
Oregon Health & Science University
[hidden email]
skype: melissa.haendel
503-407-5970




_______________________________________________
p4-feedback mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/p4-feedback


_______________________________________________
p4-feedback mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/p4-feedback