Serialisation protégé 5.6.3

[aleixpuigb]

Serialisation protégé 5.6.3

[anitacaron]

This is blocked by #3087

[anitacaron]

We have discussed in the Tech meeting a workaround while we wait for the new releases of each tool.
In all cases, as an annotation or an annotation for a logical axiom, we'll change the annotation to comment instead of IAO:0000116.

[matentzn]

I dont have any larger concerns here (especially since the PR is reasonably sized) but I do think we should in the midterm distinction between comments that are meant for the public, and comments that are meant for the curators of the ontology. So I would suggest to add "EDITOR NOTE:commentcoommentcomment" so we can clearly distinguish those, and have an easier time later to align editors notes with OMO.

[gouttegd]

There are several instances of ill-formatted comment: tags (see below for an example). The syntax of a comment: tag is

comment: this is a comment

and NOT

comment: "this is a comment" xsd:string

[gouttegd]

@matentzn

I do think we should in the midterm distinction between comments that are meant for the public, and comments that are meant for the curators of the ontology.

For the record, I believe the opposite. ;)

I don’t think there is much value in trying to distinguish between a “comment meant for the public” and a “comment meant for the curators“, it’s an unnecessary complication.

[matentzn]

I don’t think there is much value in trying to distinguish between a “comment meant for the public” and a “comment meant for the curators“, it’s an unnecessary complication.

So you dont think there is a difference between:

AnnotationAssertion(rdfs:comment <http://purl.obolibrary.org/obo/HP_4000100> "The enzyme lactase phlorizin hydrolase, located at the intestinal brush border, is necessary for the hydrolysis of lactose, the main sugar in milk. Due to the genetically programmed decrease in intestinal lactase activity that occurs post-weaning (lactase non-persistence), a large proportion of the human population loses, in adult age, the possibility to digest and absorb lactose.")

and

"TODO - split from exoskeleton? Also: See above sf item to see if this belongs in GO" xsd:string

?

[gouttegd]

And what about, for example:

property_value: editor_note "The anatomy, pathology and medical community considers the anus to be part of the large intestine, and supports the use of 'anorectum' to include rectum, anal canal and anus. Although a few resources seem to only include the distal part of the rectum in 'anorectum', this UBERON grouping term is meant to refer more broadly to the whole of rectum." xsd:string

That’s an editor note, but it sounds like something I would like to know if I was a user of Uberon.

property_value: editor_note "Modified from the original AAO source" xsd:string

Likewise. Why should the fact that the term comes a given source but has been modified from that source should be a curator-only information?

[Term]
id: UBERON:2005260
name: fenestrated capillary
[…]
is_a: UBERON:0001982 {source="FMA"} ! capillary
property_value: editor_note "the ZFA class from which this was derived is not explicitly classified as a capillary - need to verify for taxon histology differences" xsd:string

So the editor classified the term as a capillary but there is a lingering doubt about this classification. Sure, it’s something for the editors to check, but that’s again something I’d definitely like to know as a mere user.

property_value: editor_note "A quick perusal of definitions for fascia dentata suggests that it is sometimes used to refer to the entire dentate gyrus, in which case it should be a synonym, and sometimes to a specific cytoarchitectural field of dentate gyrus. More research is needed. In the meanwhile, I have not assigned it as a part of dentate gyrus, assigning instead the cytoarchitectural layers. (Maryann Martone)" xsd:string

Yep, again something I’d like to know, thank you very much.

And as soon as you ask curators to decide, when they want to add a (comment|note), whether it is more intended to other curators or to the “public”, you’re bound to have inconsistencies, because curators won’t have the same idea of what is more useful for each group of people. As I said, needless complication. Let’s just have comments and let people figure out if the comment is useful for them or not.

[matentzn]

You are arguing with "its hard to distinguish editors notes from comments" - You are not saying, correct me if I am wrong, that there are not any comments that are not meant for outside consumers.

Since an ontology is essentially a database like object, there should be a way to add annotations that are not meant for downstream consumption - I am certainly not wedded to "editors note", but there should be a way to say: "strip this annotation out before running a release". Would you like to direct the discussion more towards an axiom annotation that can be used on any annotation assertion?

[gouttegd]

You are not saying, correct me if I am wrong, that there are not any comments that are not meant for outside consumers.

Indeed, I did not say that – but I should have, and I am saying it now.

I don’t see why some comments should not be meant for “outside consumers“. We are doing everything in the open. Nothing should be “for insiders only“.

In fact for a free (as in free beer) project like Uberon I believe the distinction between “insiders“ and “outsiders“ is pointless, similarly to the distinction between “developers“ and “users“ in free software. Any “outsider” can become a contributor at anytime, even if only for one contribution (isn’t that what some people call “drive-by curation”?).

there should be a way to add annotations that are not meant for downstream consumption

I disagree.

Having two annotations to represent “comments meant for outsiders/downstream users” and “comments meant for curators” only results in the users having to always check both types of annotations, because users can never be sure that a “curator-only comment” will not contain an information that is actually useful to them (as is the case for all the examples I have given). It’s a needless complication for both editors and users and a hindrance to drive-by curation.

It would be even worse if, as you seem to be suggesting, the “curator-only comments“ were stripped from the release products, because then users would be left completely ignorant of the existence of comments that may very well be useful to them, unless they are savvy enough to check the ontology source files instead of just using the released artefacts.

[matentzn]

I never really thought this all the way through for comments, but there are certainly a lot of annotations in various editors' files that do not belong in a release (we have annotations that allow terms to violate a QC check for example, or we have annotations in one format that need to be transformed to another before release). I guess we should stop discussing this here, seems more like an OMO issue tracker issue. And we will lose all our nice argument after this is merged.

I am fine, if @anitacaron agrees with you, to leave it as is (without adding additional strings to indicate editors comments) in this case.

[anitacaron]

I think adding a string referring to the previous editor notes annotation is good for easily replacing the cases to use editor notes when the problem is solved.

[gouttegd]

No issues as far as I can tell.

No objection to adding a marker inside comments, though as I have stated I believe this is completely unnecessary.

[matentzn]

If you load - saved this with Protege LGTM

[anitacaron]

Yes, I ran normalize_src every time.

[gouttegd]

There are still some non-oboInOwl annotations that could cause the same bug to be triggered again. One of them is highlighted below.

The other two that I found after a quick look are line 113231:

synonym: "milt" NARROW [PMID:31287811, PMID:35203131] {IAO:0000232="A secretion from the glands of the male reproductive system in some aquatic animals that contains sperm and is sprayed onto the eggs."}

and line 118703:

relationship: has_part UBERON:0006844 {UBPROP:0000008="some premolars may have 3 cusps", min_count="2", comment="cardinality not allowed with transitivity in OWL"} ! cusp of tooth

[anitacaron]

sorry, I forgot to normalize before my last commit