Skip to content

o-souter/clucktology

Repository files navigation

"# cmm304-assessment-o-souter"

Clucktology: A chicken ontology project

Overview

Clucktology is an ontology-driven intelligent system designed to assist new and experienced chicken keepers in managing their flocks. The system leverages semantic web technologies to recommend suitable chicken breeds, estimate egg production, and identify potential issues within a flock, such as aggression or broodiness.


Knowledge Requirement Analysis

Since the pandemic, chicken keeping has grown in popularity, as people seek sustainable food sources, food traceability and even for companionship (Chris, L., n. d.). However, since many unexperienced people might like to start keeping chickens, it can be difficult to know where to start. Clucktology is the proposed project to help resolve this problem. It works using a chicken ontology, built from concepts established in Chicken Breeds, (n.d.), as a reasoning base, to help users plan which breeds of chickens they might like to keep. It will help to determine how many eggs to expect, and flag if there might be any conflicts between the different breeds of chickens kept.

Competency Questions

Clucktology aims to answer:

  1. How many eggs can I expect from X breed of chicken?
  2. Which of my chickens are aggressive?
  3. Which of my chickens are the best egg layers?
  4. With my current chicken keeping setup, how many eggs can I expect daily/weekly/yearly?
  5. Which chickens are prone to broodiness?
  6. With my current chicken keeping setup, is there any risk of conflict between chickens? If so, which chickens are problematic together?

Conceptual Model

The main classes and individuals of the ontology are shown in Figure 1: arrows indicate subclass relationship, with the source being the subclass and the target the superclass.

image

Figure 1: The conceptual model

Relationships between these classes are shown in Figure 2, with arrows indicating the direction of the relationship. Class names are bold and datatypes and value types are also shown. In addition defined classes are shown, and inferred for individuals that fit into their defined Type.

image

Figure 2: Relationships between classes in the model

Definitions

image

Figure 3: Definitions of Classes in the model

Relationships

image

Figure 4: Relationship definitions in the model

Instances and Individuals

  • One main group of individuals required for this ontology are the most common chicken breeds in the UK. Individuals have been created, from Chicken Breeds, n.d. as reference, which also provided a basis for the couldLayEggsPerYear property for each breed, and to help determine whether or not a chicken may be a broody chicken.

  • In addition, instances are required for the genders a chicken could be. In this environment, Male, Female and Unknown were suitable. Male and Female are standard, for cockerels and hens respectively, and the Unknown individual is for younger chickens, that are not laying yet, for which the gender is not known. Before a chicken reaches 6-8 weeks old, its sex is very difficult (How to tell if your chicks are male or female (no date)), so the Unknown gender allows for chickens that this may apply to.

  • A single instance is created for the garden, which simply contains all NamedChicken instances, and can be classified as a CalmGarden or ProblematicGarden .

Intelligent System integration

  • The ontology specified above has been created using protégé and is stored in a Fuseki Triple store and persisted.
  • In the protégé ontology, SWRL rules are used to appropriately give each NamedChicken individual the laysEggsPerYear attribute, depending on the eggs expected to be laid by their breed (couldLayEggsPerYear for instance of ChickenBreed), and their gender (Males obviously lay no eggs)
  • In the Webapp implementation, due to issues with Reasoning Inferences, related to the fuseki version, SWRL rules are instead done using javascript when needed, when the Fuseki Triple store is updated.

The main rules for the system:

image

Figure 5: Main system rules

In addition to these rules, the reasoner makes inferences to determine AggressiveChicken, BroodyChicken, FriendlyChicken defined classes for each NamedChicken individual (See fig. 2)

All chickens that a person has will be defined as instances of NamedChicken, and can be manually inserted into the ontology through the web interface or through SPARQL queries. The user can then view these unique individuals and view information about them in the web interface.

Webapp Design

The webapp will consist of two main pages:

Chicken Finder

Through input form, allows the user to select and build a NamedChicken individual by inputting the following:

  • Chicken Breed
  • Gender
  • Name
  • Age

Once these details are specified, the user can click “Add to Garden”, for the chicken to be added to their garden. This also means the individual will be created and added to the ontology using SPARQL and flask. Additionally, once a user has selected a breed, they can view information about the chicken breed, such as how many eggs can be expected, and the individual’s IRI.

Planner

This page allows the user to view their current chickens that they inputted from the previous page, in a thumbnail-card view.

image

Figure 6: The planner page of the Webapp

In each chicken card, they can view a stock chicken image, followed by the chicken’s name and age, breed, gender and eggs laid per year. This value is queried from the ontology using SPARQL and flask, and inputted into the page using JavaScript. In addition, the classes the chicken lies in are queried for and displayed, showing if chickens are Eggcelent or Aggressive, for example.

In addition, the users can view the following egg information, calculated on site using JavaScript, with the queried values:

image

Figure 7: Egg information in the Webapp

Users can also view the garden space that would be required for this number of chickens.

image

Figure 8: Garden space information in Webapp

In the Potential Issues section, the user can view information on any issues that may exist with their current setup of chickens. The below analysis was done for the above configuration of chickens.

image

Figure 9: Potential issues section in Webapp

At the bottom of the page, the user can clear all instances created using the “Clear all Chickens” button.

##Evaluation and performance on competency questions - Webapp

image image

Figures 10 and 11: Webapp competency evaluation

Evaluation and performance on competency questions - Ontology in protege

For the webapp tests, similar queries are run through flask for each competency question. Here, they can also be run through the protégé ontology.

image image

Figures 12 and 13: Ontology competency evaluation


Review and resulting actions of LLM research – Using LLM Knowledge modelling approaches to evaluate current ontology

The aim of this section is to use an existing LLM knowledge graph or ontology building system, to create and extract similar ontology concepts as the ones used for development of Clucktology. The paper, “Leveraging LLM for Automated Ontology Extraction and Knowledge Graph Generation”, by Abolhasani, M.S. and Rong, P., 2024, presents OntoKGen, a language model system used to aid knowledge graph development.

The key feature, and the one most relevant to this review, extraction of information from input text, and subsequent creation of relevant knowledge graph concepts, to aid the development of an ontology. The model used in the paper, uses chain of thought prompting to improve the reasoning abilities of the language model, allowing it to break down complex concepts into more simple steps. In addition, when prompting the language model, instructions were provided, like “lets think step by step” and the end. This would allow the language model to record its thought process step by step, to help prevent hallucinations.

When implementing as similar a methodology as possible as the paper and the same text input (Chicken Breeds, n.d.), as used for Clucktology, the following prompts were created, and given to ChatGPT. These help to introduce the paper and it’s main concepts to the language model, before the actual prompt for knowledge triples is given. (Full log can be viewed in LM logs)

image image image

Figures 14, 15, 16: Main prompts uses in LLM research

Which gave the following results, for key concepts and relationships:

image image

Figures 17, 18: Language Model results in LLM research

Instead of using a Garden, this approach suggests the use of a User that owns one or more Chicken, although these concepts are very similar in use. In addition, instead of classifying certain chickens as Aggressive, Broody, or good egg layers, through defined classes (as done in Clucktology), each chicken instead has a relationship for Aggression level, Broodiness Tendency and Egg Production rate.

The language model (in this case, ChatGPT), was very effective at extracting relevant concepts and relationships from the source document. It creates many similar concepts as to what are used in Clucktology, as well as some differences, that could be used to further adapt the Clucktology system. However, the main concepts as given by the language model are very similar to the ones used in the creation of Clucktology, suggesting that most of the key concepts, and knowledge base of the input has been correctly identified for Clucktology.

Implications

While Clucktology’s ontology aligns closely with domain knowledge, insights from the use of Language models suggest areas for refinement, particularly in modeling behavior and relationships dynamically.


References

About

An ontology-driven intelligent system to assist chicken keepers

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

 
 
 

Contributors