I am used to working with semantic web technology, however often the decisions made in some of the ontologies I have seen baffle me. While they are technically correct, they sometimes seem a little strange.

What I realise is that I have not gone through the exercise myself yet. Over the next few months I intend to go through the process of building an ontology, so that I may better understand why things have been done in others that I read.

I will document my progress, and thinking here, to hopefully provide guidance and insight to people who need to do the same in future.

The subject I have chosen for this is “Narrative works.” I would like to create an ontology to describe stories, characters and the relations between them…

Actually that could be split in two. One ontology to describe stories and another to describe relations, I may come back to that thought later.

Scope

This is difficult to pin down, before I have given too much thought to it. I’ll try and create a user story.

“As a narrative ontology user I would like to be able to describe a story in context so that I can analyse the story and determine facts about it.”

That is still a little woolly. How about some use cases?

Describe (in increasing detail):

• A simple fairy tail
• A play
• Something which has multiple formats eg book of the film.
• A TV series
• The life of superman.

Determne

• The story in chronological order
• The story from a characters point of view.
• Differences between versions of a story.
• Differences between versions of a character.

I may alter the scope as I go, depending on how things pan out.

There is quite a lot of philosophical discussion about naratology which I would study in depth if this were my doctorate, but as I am using this just as an example to try building an ontology I will just dip into the subject as I need to.

Some notes after creating a basic mobile tool using Drupal. Not exhaustive research but could be handy to someone trying to do the same.

Created a new theme got rid of all regions bar $content.

Also as we didn’t need them for the app, commented out tabs.

Even if you keep all content in a page small it looks like webkit will still zoom out by default. <meta name = "viewport" content = "initial-scale = 1.0"> sets the zoom level to 1.

However even with the meta tag above webkit will still zoom out if there are widths which push the content above the width of the screen.

So I had to make sure there were no CSS widths specified. Percentages seem to work well. If you are worried about how things will look on a full size screen you can use max-width (even though this won’t help those on IE6).

Even after that some form items end up being created too small so I had to do a hook_form_alter and make sure size was 20 for all textarea and password fields.

I didn’t research too much but it looks like the android webkit struggles with long class names, things like div#block-formblock-node_entry just wouldn’t match.

Quriksmode mobile browser CSS tests is also a handy find

Developers often get het up about their editor, as it has been and probably always will be. It is a very personal choice. As it is the system you will spend untold hours interacting with.

I am not going to say there is a right or wrong system. My preference is eclipse however my reason for linking it is not in any particular shortcut or way of working. My reason for liking it is that it is integrated

There are various tasks involved in development. There is of course the coding. However there is also debugging, version control, bug tracking and often time tracking. The more tightly integrated you get all of these, the less context switching you will have to do and the more effective you will be as a developer.

To illustrate this I will take an example with a fictitious un integrated system for fixing a trivial bug.

1. Open bug tracking software and find bug assigned to you and read it.
2. Open editor and fix trivial bug.
3. Build software in software building tool
4. Test software in software environment.
5. Open bug tracking software again to get reference to bug.
6. Open source control software to commit bug.
7. Open bug tracking software to mark bug as resolved

That is a lot of context switching. Compare to example with fictitious ultimate integrated environment.

1. Open next task in UIE
2. Fix bug
3. Click on build in UIE
4. Test and run test suit in UIE
5. Commit code automatically closing ticket as you do so.

The more tightly integrated things are, the less needless work you need to do and the more effective you will be as a developer. It is worth taking the time to get your IDE to be integrated. How much time is a difficult thing to estimate. In “”the mythical man month” Fredric Brooks talks about a team having one person dedicated to writing tools.

We have bigger, more powerful tools nowadays, but in a team it may be well worth having at least one person dedicated to improving the developer experience. The maths is fairly simple. If you estimate that developers can be 20% more efficient with better tools (this will vary massively depending on the technology stack) by the time you have 5 developers the equivalent of one of them will be wasted due to avoidable inefficiencies. So let them choose the tools and have the time to get things running smoothly. And you will have more efficient and happier developers. If you have a team of more than a dozen or so developers seriously consider having someone full time to keep the developers ides and machines running as smoothly as possible.

It is not just getting the developers to work more effectively. Taking the time to have a great IDE setup will pay for itself many times over. Having the bug tracking system right in the IDE will make it easier, and hence more likely that a developer will update tickets as they work. This gives managers better reporting, and stops them from distracting the developers asking for status updates.