ro_import does not include domain/range constraints #1182
Comments
|
When domain/range constraints are added, The produces output: The class @cmungall I could not determine the source of the error: |
|
Adding domain/range constraints also results in violating the DL profile. This robot command: Produces output: |
|
Thanks @wdduncan, great detective work! So I think the unparseable triple warning is distinct from everything else here. I would make a separate ticket for this. You can find some more context on this here: obi-ontology/obi#1289
Great, this is exactly what we want. We want to be able to detect all incoherencies in the ontology, and fix them as soon as possible, otherwise they leak upstream and cause all kinds of issues. We need to first fix the incoherencies in ENVO. These are. like compilation errors in programs, we just shouldn't be releasing the ontology with these in. Let's fix this: Immediately after we put the stricter check into the pipeline so this doesn't happen again
Good catch. So what I notice about this list is that it is all RO. Yet RO does not itself have this profile violation. This means there is something in envo.owl that is interacting and causing this. I imagine it is one of two things:
|
|
RO has the simple properties:
The definition for has primary input is quite broad. Are we happy with using this property for things like earthquakes? |
|
I am not sure I would use these terms here
Earthquake is currently classified under material transformations. What is
the input material and what is the output material?
I think in order to close this ticket and move on we want to make the
minimal change possible to remove the owl error. This is a fake OP
subproperty of has participant
But we should also make a new ticket for earthquake modeling that can be
tackled at slower pace. We want to do an analysis of the process the same
way we do for go. What is the start and end? Where does the process occur?
What are its causal relationships to other processes? I suspect we will
ultimately use occurs in to relate ac quake to a plate or region of the
earth's crust overlapping plates
…On Thu, Aug 26, 2021, 09:37 Bill Duncan ***@***.***> wrote:
RO has the simple properties:
- has primary input or output
<http://purl.obolibrary.org/obo/RO_0004007>
def: p 'has primary input of output' c iff either (a) p 'has primary
input' c or (b) p 'has primary output' c.
- has primary input <http://purl.obolibrary.org/obo/RO_0004009>
def: p has primary input c if (a) p has input c and (b) the goal of
process is to modify, consume, or transform c.
The definition for has primary input
<http://purl.obolibrary.org/obo/RO_0004009> is quite broad. Are we happy
with using this property for things like earthquakes?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1182 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAMMOIUWE74OCGDCSYITZLT6ZUTTANCNFSM46YNI7VQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email>
.
|
|
Earthquake is a tricky one. From an engineering viewpoint, an earthquake is ground movement (vibration) at a location, as a result of various source phenomena at a distance. The characteristic properties are time, amplitude, acceleration etc at the observing location. From the viewpoint of most geologists and geophysicists, the earthquake is the source phenomenon. Usually underground fault-slippage or fracturing, but maybe cavity collapse, an underground explosion, etc. The characteristic properties are location, timing, focal-mechanism, moment, etc of the natural or artificial phenomenon at the source. These phenomena are causally related, but different, though often given the same name. |
|
Thanks @dr-shorthair. Yes we should make a separate ticket for earthquakes. I guess the question now (as @wdduncan put it in #1072) is do we use some simple object properties to replace OPs |
|
@kaiiam - great idea to put the cardinality as an axiom annotations on a plain existential axiom using the existing object property. Would that be acceptable to you @pbuttigieg? |
|
@wdduncan I was trying to recap what you had suggested there so we can make a decision on it. @cmungall @pbuttigieg thoughts or preferences? |
This allows issues like #1181
Because the import can be problematic (modularity issues, RO needs various classes across OBO for D/Rs), I suggest a step in
make testwhich does a merge of ro full and envo and runs hermit, longer term we can work on base files etcThe text was updated successfully, but these errors were encountered: