Forem: Octa

Ontologies - part 2 : definitions & vocabulary

Octa — Tue, 08 Dec 2020 09:37:29 +0000

Why are we even doing this?

As I'm reading further along about ontologies one thing is clear to me. The point of this entire thing is to take the real world - something you innately know and understand - and try to extract from your brain categories and relationships between them that a computer can understand. Once you've got that, said computer can answer queries, create a knowledge base and be trained to play around with the data at astonishing speed.

Definition

These definitions so far seem the best to me:
An ontology is a formal explicit description of concepts in a domain of discourse.
An ontology together with a set of individual instances of classes constitutes a knowledge base.

Ontologies consist of classes (eventually subclasses) or concepts. Classs have properties (features and attributes of the class, sometimes calles slots as well) and there can be restrictions on those slots or properties (those restrictions can also be called facets).

Vocabulary & OOP

Like with all new domains you need to be familiar with a few words before you can understand something like the definition above.
Object oriented programming in this case is both something that can help and that can hurt. Ontologies are composed of classes and subclasses, and have instances. Sounds familiar, right?

You can safely use your understanding of what an instance is in OOP to help you understand instance in an ontology. For classes however, it's a bit different. In OOP you tend to use classes along with methods, and creating a class will entail you coding the methods, thinking whether or not they're in the right place or need to be split off, instantiating classes so you have access to their methods etc. In ontologies a class is much more descriptive. When you create the ontology you describe the properties of the class and think much more in terms of structure than in terms of what the class does. An ontology is a mapping, not a program. It can be part of a program however, but that's for a later post.

Ontologies - part I: Introduction

Octa — Wed, 02 Dec 2020 10:39:40 +0000

As someone who studied philosophy back in the day (am I old yet?) I've thrown the word ontology around a lot. As someone who is now a web developer, I've heard it in passing in the corridors. But as someone in a 3-man IT/DEV/OPS team, I have been gifted the task of diving into it because someone had to.

Luckily I like a challenge.

A major aspect of this challenge will be to explain to my coworkers what this is and how they will need to wrap their minds around, so this series of posts will be an exercise in summarizing and condensing what I learnt each day.

Basically, what is an ontology?

Before you think of data, think of the real world. You know fruit comes from a tree, not from a seed. You don't know how you know or when you learnt, but you know that you plant a seed, get a tree, get some fruit. One type of fruit comes from one type of tree. Carrots are edible, so is fruit, but a carrot is not a fruit.
All these statements are description of reality. What if someone tried to unravel the matrix behind reality, break all of the fruit-stuff I mentioned before to tiny bits of reality, then classify those in neat boxes and relationships between said boxes?
Basically that's an ontology. Classes and relationships.

Why do we need this?

The main advantage is that those relationships and classes can be translated into a language the machine can understands, ie, your computer. If someone says "this carrot came from the carrot tree" you know it's wrong - but how does your computer know that this can not be true in reality?

Is this the same as a taxonomy?

Most of us are more familiar with a taxonomy. At the very least you've seen one in biology class.

Species: Vulpes vulpes -> Genus: Vulpes -> Family: Canidae -> etc.
Taxonomies are hierarchical, they formalize the relationships. It's a type of structure, and you can often easily visualise it as a tree-like structure. They tend to be applied to one domain. You classify documents, you classify tools, but how do you connect information in documents about the tools? That's where ontologies help.
This post was very helpful to me.

Enough for one blog, see you later hopefully for the rest.

Which autism accommodations have helped you / your colleagues?

Octa — Tue, 10 Nov 2020 06:31:50 +0000

This will be a small drop in an ocean of posts, but I hope it can get some replies. I need help, and maybe at the same time this post can help others. As I'm starting out my career as an autistic developer, I am running into many difficulties, burnout, anger, lack of direction, overstimulation.

The pandemic has many of us working from home, which for autistic people means that there is a better control on over- or understimulating circumstances, noise, the clothes we can wear or not.

In general I think this is one area where adaptations can make life easier for autistic developers.

There is also the issue of videocalls. It has been proven they are tiring, for everyone. However they are still a big feature of WFH, and not every boss or colleague is understanding of your desire to turn off the camera, or to communicate via email, though I think those could be a step in the right direction.

One of the worst aspects in my work environment specifically has been the lack of structure. While Agile (the more common organisation in CS) has its perks and downfalls, it represents a system with rules and things one can plan for. If you have a less organised workplace but your colleagues are at a desk's distance, you can turn around and ask. However in remote working conditions "just ask" seems to work really badly. I think in this case it's one of the more complex areas to ask for accommodations, as you're asking colleagues to regularly go out of their way just to make you more comfortable - which is something else entirely than just letting you have noise-cancelling earphones.

In any case, please let me know what you think and what worked for you.

TIL: errors are good and important

Octa — Fri, 21 Feb 2020 09:17:46 +0000

A bit of a diary post but I realised today that I need to stop focusing on results only and enjoy the debugging journey.

I suppose we all know this: You're coding and you've just written a few extra lines, suddenly your app crashes, nothing loads and you have this big fat error, warning, or nothing at all. Oops.
I used to see this as a failure, as my code not being good enough. It's important to realise that's not what it is.

It's a learning opportunity.

"But how do I make sure that I don't lose too much time on this?"

This was one of my big questions. I'm straight outta bootcamp and I am a junior so it's bound to happen a lot. Here is what I think can help:

- Set a time-deadline after which you go ask for help

Sometimes you have to deliver x or y by the end of the day and you can't afford too many hours on it. So, when you start debugging, look at the clock and set a deadline after which you'll go ask.

- Set a frustration-limit after which you go ask for help

I once got so frustrated and flustered that I deleted my entire code, doing the digital equivalent of a tableflip ragequit. It was a good lesson that sometimes one can be too frustrated to continue working on something. It will probably take time to know when you reach that point, but if you notice you're there, step away from the computer, hands in the air, and go get a fresh pair of eyes to look at it.

- Make notes of what you've learnt.

Maybe you needed to dig through the entire structure of your linux distro, maybe it was your IDE, maybe you had to read up on OOP because you hadn't understood something. Once it works, open up a note-taking system and jot down quickly things like the language, the error, what was wrong, how you fixed it (and maybe a link to the Stack Exchange solution, or post that helped you). This keeps a trace of your learning and if weeks down the line it happens again, a quick search in that file can help.

The last tip especially helps me see bugs and errors as ways of learning, rather than mere obstacles.

If you have any tips or helpful methods, feel free to leave them in the comments below, as they might also help me and other beginners.