-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dev simon #61
Dev simon #61
Conversation
this commit fixes some bottlenecks in the reasoning by removing hasSubprocess restrictions and importing a non-inferred version of emmo.
In this newest PR, the reasoner took 20 minutes in my PC:
|
@@ -3946,13 +4265,12 @@ Cl2, Hg | Hg2SO4, and Hg | HgO, can be used as reference electrodes in aqueous s | |||
:electrochemistry_9da958fc_f76d_4654_8a78_99b5f98c118c rdf:type owl:Class ; | |||
rdfs:subClassOf emmo:EMMO_b9522e56_1fac_4766_97e6_428605fabd3e , | |||
[ rdf:type owl:Restriction ; | |||
owl:onProperty emmo:EMMO_dba27ca1_33c9_4443_a912_1519ce4c39ec ; | |||
owl:onProperty :electrochemistry_3bd08946_4e81_455d_9fca_dc7a5ead9315 ; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
However, here, it is preferred to use hasElectrolyte
. I would tend to favor using hasConstituient
as much as possible, without needing to create additional object properties. hasConstituent
something of @type: Electrolyte
is possible in linked data formats, removing the need of creating a very specific object property.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
see #61 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Most object properties removed are not so critical. At the end of the day classes are most critical to linking data. Object properties become more relevant when try to reason, or for generating schemas, or for recommendation systems. Since the most urgent application is linking data, it might not be necessary to complicate the topology of the ontology with many object properties; for now at least.
rdfs:subClassOf <https://emmo.info/electrochemistry#electrochemistry_0a03ce7e_d79f_412e_a103_b5d74de9f4d7> , | ||
[ rdf:type owl:Restriction ; | ||
owl:onProperty emmo:EMMO_3446e167_c576_49d6_846c_215bb8878a55 ; | ||
owl:someValuesFrom emmo:EMMO_4f2d3939_91b1_4001_b8ab_7d19074bf845 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Plots can also be linked to quantities. We can think about the right way to do it once the issues with the reasoner are resolved. I tried using hasVariable
, but perhaps we can borrow from terminology using in plotting software, e.g. AxisQuantity
, or something similar.
This pull request fixes some bottlenecks in the reasoner linked back to EMMO object property restrictions. It also fixes some typos and bugs in the ontologies.