Checklist of things for REO prior to importing into go-lego

[cmungall]

• Should pass ROBOT QC checks @dougli1sqrd
  • In particular, rdfs:labels should be uniquified in the same manner used for the rest of NEO. Are robot templates overkill here?
• decide on final form of URIs, currently we have e.g. http://model.geneontology.org/R-HSA-72571 which is not great. We should see if Reactome tech team has a pref
• need to decide on final form of uniprot IRI (id.org vs uniprot). See Please use http://purl.uniprot.org/uniprot or http://purl.uniprot.org/isoform/ IRIs for UniProt concepts neo#34
• inject biolink categories
• make it easier to traverse from a REO entity to the relevant uniprot class
• decide on name. REO is taken in OBO. Even though we won't want to release on OBO(?) best to avoid confusion. REACTO? REON?

[goodb]

@fabregat I wonder if there are any opinions from the Reactome team here? Summing up quickly, we are building an OWL ontology that represents the physical entities used in Reactome. (See #70 for more on why.) This is constructed automatically from a BioPAX export. Do you have any interest in using or contributing to this ontology? Any thoughts on the URIs used or the name?

[goodb]

@dougli1sqrd could you tell me about robot QC requirements?

[goodb]

@deepakunni3 what is the expected pattern for adding biolink categories to classes in an OWL ontology?

@cmungall on that issue, is it time to add biolink categories to all of the other ontologies the group maintains?

[goodb]

@cmungall @balhoff regarding "make it easier to traverse from a REO entity to the relevant uniprot class"

I think we need a generic pattern for encoding what a 'relevant' gene class is in the NEO/go-lego context. 2 ideas to start with:

1. a property on the relevant gene classes (annotation isCanonicalGene TRUE or subClassOf CanonicalGene or subClassOf CanonicalHumanGene) and then retrieve by running up the class hierarchy until one is found. That would work for REO as it stands as all the entities that could map to uniprot are defined as subclasses of the uniprot genes.
2. an annotation property like 'canonicalGene' that could be used to link anything to the uniprot (or other default) gene regardless of whether it was a subclass. If we shift to a different architecture for NEO to reduce tbox size, this might be useful. Of course that might also impact the way REO is created in general.

A key first use case for this structure is the generation of uniprot-centric GPAD from GO-CAM models that use Reactome entity ids. See #52 on that.

?

[ukemi]

One little nuance here is that only a subset of UniProtKB identifiers are valid as gene stand-ins. Those are the ones that have been blessed as gene-centric representative proteins (GCRP)s. Do the Uniprot identifiers that Reactome maps to always come from this set?

[goodb]

Hi @wdduncan !

[goodb]

@ukemi I'm not sure how to answer that question about GCRPs. If Reactome referenced a non-GCRP record for a protein, should the REO generating process try to figure out what the appropriate GCRP term is and use that instead of what Reactome asserted? That makes me a little uncomfortable - seems like it ought to be up the Reactome curators to make that decision.

[goodb]

@cmungall could you elaborate on "rdfs:labels should be uniquified in the same manner used for the rest of NEO" ?

Shame REO is taken. It appears that the owners have abandoned it? http://www.ontobee.org/ontology/REO

I like REACTO - very xmen.

[goodb]

@cmungall @balhoff @kltm based on lack of response, I think it is up to us to decide on a URI pattern for the ontology currently known as REO. I would be excited if we could support Linked Data style URIs - e.g. resolving to RDF. Though potentially independent entities, the same thought pertains to the go-cam models themselves (including the URIs used within them). go-cams are a great application of the semantic web approach and I would like to see us follow through and deliver them in ways that encourage others to use the RDF/OWL versions of the content as much as possible. Providing Linked Data helps keep things moving in that direction.

OBO library ontologies have an established pattern for URIs. Should we apply something similar for RDF products generated by the group that are not in OBO? How does this relate to rdf.geneontology.org ? Is anyone thinking about this?

[deustp01]

@ukemi I'm not sure how to answer that question about GCRPs. If Reactome referenced a non-GCRP record for a protein, should the REO generating process try to figure out what the appropriate GCRP term is and use that instead of what Reactome asserted? That makes me a little uncomfortable - seems like it ought to be up the Reactome curators to make that decision.

Assuming that all SwissProt instances are GCRP and all TrEMBL ones are not, Reactome curators should always use a SwissProt entry in preference to its TrEMBL counterparts and UniProt is organized to make this easy. So, any non-GCRP usage should either be for instances where SwissProt curators have not yet assembled a definitive SwissProt record from the available TrEMBL records or a mistake. I think our QA catches cases where we curated something before a SwissProt record was available and one has been created since.

So a list of non-GCRP usages found in the Reactome import should be short and will be another instance of useful QA provided by the GO-CAM import process.

[goodb]

Going with REACTO with URL
http://purl.obolibrary.org/obo/go/extensions/reacto.owl

supported by physical URLs like:
http://current.geneontology.org/ontology/reacto/reacto.owl
http://release.geneontology.org/2020-01-01/ontology/reacto/reacto.owl

with internal URIs following the GO pattern
http://purl.obolibrary.org/obo/REACTO_R-HSA-72571

Will try to work the create and update process into the standard ontology build makefile.

(unless @balhoff @kltm or @cmungall would like something else).

[balhoff]

My only issue here is that the term URIs will not resolve without registering for an OBO library prefix.

[goodb]

I don't see this being a full on OBO ontology. Is there another mechanism?
Otherwise we could make them like http://purl.obolibrary.org/obo/go/extensions/reacto.owl#REACTO_R-HSA-72571

such that they just resolve to the entire ontology.

[kltm]

@goodb The Makefile is fine for me--we can easily test it on a branch of the pipeline. If another build process starts to look more promising, let me know and we can work out the best way to test it out.

[balhoff]

Otherwise we could make them like http://purl.obolibrary.org/obo/go/extensions/reacto.owl#REACTO_R-HSA-72571

I think this might be the way to go, unless someone has a better idea. @cmungall?

[goodb]

@kltm where should I put the models - assuming that their creation is part of the build process here. ??

[kltm]

@goodb That will take a little workshopping; I think that the most likely spot would be skyhook for the time being. I'm not sure that they are ready for release. We can take a little time at how that looks in the pipeline when we need it.

[goodb]

@kltm when you say 'skyhook' I have no idea what you are talking about...
Okay. I will try to get the ontology part of this working now as it is an immediate, blocking requirement holding up a push of the latest batch of models into noctua-dev. We can return to the pipelining of the models themselves in the future.

[kltm]

This will part of your training that we'll do to get you up to speed on the pipeline.
For now, it is a public intermediate store for pipeline products.
http://skyhook.berkeleybop.org

[goodb]

Noting here that model validation via shex and owl work a little differently for the reactome models than for the rest because of the use of reacto. Other models currently gather the upper level types for genes and other entities by request to a golr server. These requests do not work for reactome as reacto entities are not present in that server. This is okay for the moment because the reacto ontology contains the required information linking each entity to an upper level class (just as neo did previously for everything else.).

[goodb]

I think for the purposes its going to be used for, REO (not reacto) is done for now.