Modifications to ontology
This week we revise our ontology based on feedback on LMS and the two times of meeting with Elisa and Prof. McGuinness. The feedback mainly described the lack of annotations, and it obstructed the understanding of the ontology structure. Basically, we thoroughly added annotations for classes and restrictions. Similarly, we expanded all the acronyms to improve readability for classes. We also change the name of classes to make the criteria of classifications clear, such as ‘NonPowerConsuming Component’ and ‘PowerConsumingComponent’. We reintegrated ‘QuantitativeAndUnits’, and based on our references, such as ‘Flower ontology’ and ‘QuantitiesAndUnits’, we separate delta buckets into indoor-indoor delta buckets and indoor-outdoor delta buckets. Additionally, we separately added instances for delta buckets.
What we learned
When we first started working on our ontology, we went all-in on numeric measurements and values, not realizing that a reasoner can’t handle arithmetic well. We received feedback from the teaching staff that said as much, and in response, we ditched numbers entirely and focused instead on qualitative buckets. However, in meetings with Elisa and Prof. McGuinness this past week, we learned that we should actually pursue a “compromise” approach that specifies numeric values and lets a rule engine map them to qualitative buckets on which we can use a reasoner.
Issues and Challenges
This week we have continued to struggle in the development of the structure that will handle operations on the qualitative buckets representing our environment attributes and environmental challenges. Even though we wrote out and “whiteboard-ed” a practical example of a situation our system should work on, the best method of solving our problem still feels very ambiguous, as we have only a small amount of familiarity with design patterns in ontologies, how certain relationships should be represented most effectively, and what relationships should be represented as object properties, data properties, data types, or individuals. Additionally, while we have known that SPARQL would be useful in our system, we don’t have any practical experience with it, and haven’t known what design patterns are the most compatible with SPARQL— this is certainly a challenge we will be reading ahead on over the next week.
How individuals are used
The most important individuals in this ontology are those representing the Baseline Environment, Outdoor Environment, and Target Environment. Each of these individuals holds as much environment attribute data as possible. Additionally, a Room individual is created, and has the relationship ‘has component’ with individuals representing room components. Examining what components the Room individual has will restrict the system to using only those types of components to find a solution.
Contributions
Kelsey:
Jihoon:
Gabriel: