search

SuLab / GeneWikiCentral

GeneWiki Organization
MIT License
5 stars 2 forks source link

Import ECO #3

Open stuppie opened 7 years ago

stuppie commented 7 years ago

I apologize for my delayed reply. I thought I had a quick and sensical solution (leaning toward a variation on option #2 that you suggested). My solution involves replacing used_in with another, more appropriate, relation from RO. But the solution is tied into another somewhat substantial modification to ECO - adding another root class (that may or may not be used solely for development or perhaps viewable by users). I need to give my model a little more thought and will discuss it at today's ECO group meeting. Then I want to run it by a few ECO stakeholders and ontologists like Chris Mungall. So I have just a little more legwork to do before I propose it to you and the group. I anticipate it will be ready this week. I will be sure to cc you and Andrew on my proposed solution very soon.

goodb commented 7 years ago

@stuppie we need to get this unstuck. How can I help?

stuppie commented 7 years ago

Email response from Marcus

My thoughts are:

The key issue here pertains to what we mean by "assertion" in ECO. Consider ECO:0000203, 'automatic assertion'. Do we mean to say that an "automatic assertion" is a 'textual entity' (an 'information content entity', a 'generically dependent continuant')? Or do we mean by 'automatic assertion' the 'process' of asserting (an 'occurrent')?

In fact, I consider 'automatic assertion' to be a process that generates an 'automatically generated assertion' (which is not in ECO). I mean to say that assertion as it currently exists in ECO is a 'process'. So 'automatic assertion' (ECO:0000203) has_participant 'evidence' (or 'evidence' participates_in 'automatic assertion'). And we can also speak of an assertion (the thing stated itself) as a 'textual entity' (not a process). In that case, 'evidence' is_evidence_for 'automatically generated assertion' (or 'automatically generated assertion' has_evidence 'evidence').

Anyway, I don't think we need to over model ECO. But I did a bit of that as a way of exploring what we really mean. So to answer Greg's excellent questions, I believe that some variation on option #2 would be our best bet. Indeed, I previously proposed adding "used_in" to RO several years ago, but was [rightly] told that the term label was too broad and the definition was too restrictive of domain/range. Please see here: https://github.com/oborel/obo-relations/issues/9 to learn more. Chris Mungall authored the original "used_in" definition and noted that "In the future we may use a more generic relation with weaker domain and range constraints taken from IAO or RO." So while we could "fix" used_in, I think we should use an existing RO term label more in line with the meaning of our relation, perhaps something like participates_in or contributes_to. If we went this route, then we would have to change very little in ECO: simply replace used_in with participates_in.

The only thing we have to make sure of is whether that relation (as defined in RO:0000056) is appropriate. (Ask the question, "does the process of 'automatic assertion' (ECO:0000203) actually has_participant (RO:0000057)?" Does that make sense? If so, then I think we're good to make this change.

And I need to ask whether changing used_in affects anyone or anything beyond labels, which don't really matter.

Cheers, Marcus

andrawaag commented 5 years ago

Proposed schema: https://www.wikidata.org/wiki/EntitySchema:E59

AlexanderPico commented 4 years ago

There appear to be a whole bunch of these already added, e.g, https://www.wikidata.org/wiki/Q32860428. Is the issue that these are poorly done and the proposed schema should be used consistently? Is this being debates or is this bot we could work on next?