An accessible front end to Google Calendar

September 15, 2014

I’ve not written about being blind and using computers in this forum before, but I actually have something to say – my new Accessible Google Calendar (AGC) is ready and I like it. As can be appreciated, a calendar or diary is tremendously useful things. Not having effective (as far as I’m concerned) access to electronic calendars, and share commonly used calendar mechanisms with colleagues, makes working more trying than it need be.

 

The advent of on-line calendars and so on should have made life easier, but the two-dimensional table layout of calendars/diaries makes it too much like hard work. In addition, the Web 2.0 nature of tools like google Calendar is not to my screenreader’s cup of tea. As a consequence, for many years I had to organise my diary vicariously and, as a result, badly.

 

My first step along the path to a solution was a little command line gadget made for me by Simon Jupp, one of my research associates. This gadget took some arguments that scoped time and then printed out that portion of my google Calendar diary to the screen. Additions to my diary had to, of course, be done by someone else.

Dimitris Zlitidis then did my M.Sc. project on creating an accessible front end to Google Calendar and this allowed me to both read and write to my google Calendar. This project gave the design of the AGC’s user interface I describe here. I’ve been using this for many years. Google changing their calendar’s API has prompted a re-write by Nikita Abramovs, a vacation student at the School of Computer Science of the University of Manchester, and it’s this re-write I now describe.

 

The Accessible google Calendar (AGC) tool was written in C#; this has all the user interface stuff that is native to Windows, the operating system I use, so its interface is inclined to work with my screenreader JAWS immediately. I then looked at scoping and prioritising what I wanted done. There’s a lot that one can do with Google Calendar – a lot of management of calendar type stuff – who can edit the entries; inclusion of schedules of public holidays etc. I left these out. When I want them I will work with the Web version and do so vicariously as necessary. The two things I really want to do are:

 

  1. Look at entries in the portions of time that I most frequently wish to look;
  2. Add, modify and delete entries. I want to do this with access to the facilities for specifying times (all day and fragments of days) and to do recurring events.

As the “past is a foreign country”, the main things I want to do are to look at the “now” and the “future” events in my diary. So, there’s a list of simple patterns of ways in which I choose events at which to look:

 

  1. Today and tomorrow;
  2. This week and next week;
  3. This month and next month
  4. “Select month period” extends the month functionality by being able to choose months further into the future, which the option of a) single month; b) all months; c) intervening months;
  5. For the rare dates that fall outside this scope there’s a choose date dialogue where I can specify start and end days.
  6. Finally, I can use a search date for events by their content.

 

AGC’s Event Tab is shown here:

 

Figure 1An image of AGC’s Events tab showing a week’s events and the various controls for selecting events; details are in the rest of the text.

 

Events are shown as a simple list that I can move up and down with my cursor key. Unconfirmed events are indicated by a “*” at the start of the entry. I can update events by clicking (pressing return) on the event, which brings up an update event dialogue (similar to the add event dialogue described below). There’s a settings tab that allows me to specify things like: Showing end times; 12 or 24 hour clock; separators for parts of dates (space, slash or dash); and some sounds or text to indicate errors.

 

AGC’s add date functionality is a moderately complex dialogue, but it flattens out any two-dimensional calendar presentation from which to pick dates. Nearly everything is done via little spin boxes that let me pick years, months and days via my cursor keys. As I fix the start time, the end time dialogue keeps track, defaulting to one hour later, to reduce the amount of “setting” I have to do. Checkboxes for whole day events limits the interaction to setting the day date and a recurring events checkbox exposes dialogue for setting for how long the recurring holds and on which days the recurring event happens. Finally the dialogue allows me to set a reminder time and whether or not the event is confirmed. There’s also an “add quick event” tab that lets me use Google’s controlled natural language for setting dates – “Dinner with Isaac Newton 7 p.m. next Friday” does as it says on the tin. There’s a menu of template CNL sentences from which to pick.

The Add Event tab, showing the recurring events bit, is shown here:

 

Figure 2An image of AGC’s Set events tab showing an event that recurs weekly from September to December

 

I’ve used the original version of AGC for several years and it’s been a vital tool. Dimitris and I got the user interface more or less right and Nikita’s re-write and update has made it even better. I rarely need to get outside intervention in my diary setting and the view events tab has a nice regularity, symmetry and simplicity about it that I rather like. I rarely use the choose date and search functions (though they are nice to have for the odd occasion); just having today, tomorrow, this week, next week, this month and next month does it for me nearly all the time. The user interface, having been used for years, has had lots of testing and, while the user base is not extensive (me), it does all that I need to do on a frequent and regular basis. It’s good that Google have exposed the API to their calendar. Ideally I’d like the Web offering of their calendar to work well for me, but I need to do my diary now and AGC is my solution.

 

The AGC installer can be downloaded from

https://github.com/TheOntologist/AGC/releases. There is a short readme file with a description of AGC functionality and how to install it can be found at: https://github.com/TheOntologist/AGC/blob/master/README.md

Learning about a domain from an ontology

June 20, 2014

One of the things I (and I think we collectively have done to a great extent) is forgotten about or neglected ontology as “tutorial”. We used to talk about this way back in TAMBIS days and others did so as well. The idea is that by looking at an ontology I can learn about a field of interest. Our idea in TAMBIS was that one should be able to look at the TAMBIS ontology and learn about the basics of molecular biology and an operational aspect of bioinformatics (though this exact idea was never explored or evaluated). Ontologies are often described as the “background” knowledge of a discipline; they contain the entities in a domain, their definitions, descriptions and inter-relatedness. From this, a “reader” of an ontology should be able to get some kind of understanding of a domain.

With an ontology, there are two ways I can learn about a field of interest: First, I can look at an ontology for that field, explore it and from that derive an understanding of how the entities of that field “work”; Second, I can write an ontology about that field and, in doing so, do the learning. This latter one only works for small topics or learning at a fairly superficial level. I’ve done this for heraldry; cloud nomenclature; anatomy of flowers; plate armour; galenic medicine; and a few others. This isn’t scalable; we can’t all write ontologies for a field of interest, just to learn about it. I have, however, found it a useful way to help myself structure my understanding, even if the resulting ontologies rarely, if ever, amount to very much at all (these have also largely been for fun and not an endeavour to drive some research).

 

Is this tutorial aspect of ontology going to give a full understanding? For most ontologies of which I’m aware, looking at that ontology will not act like a college course in that subject area. Looking at an ontology is more like looking at an encyclopaedia; it is a list of things and descriptions of those things, which is all an ontology is really trying to do. A so-called reference ontology can fit into this encyclopaedic role well; an application ontology should do so, but just for that application area. However, I should be able to look at an ontology or a collection of ontologies and get a decent overview of a domain.

 

Having said this, however, we can make quite a good encyclopaedia from an ontology or set of ontologies, especially if there are an adequate number of semantic relationships between entities, as well as good editorial and other metadata around those entities. I say “ontologies” as just having an encyclopaedia or ontology of molecular function (as an example) tells me what molecular functions there are and how they’re organised, but it doesn’t give me, as a learner, much of a biological context. This isn’t the fault of the ontology; I just need to look at a broader picture of biology to really learn anything. If I could ask questions such as “what molecular functions exist in the mitochondria of mammals and in what processes do they participate”, then I have something to work with (I suspect). There then, of course, remains the question of how all this information knowledge should be presented. I feel there’s mileage in a standard sort of encyclopaedic form, using the label (term), synonyms, natural language definitions,, together with the structure of the ontology to present something useful.

 

I’m still sort of taken with the idea of ontology as tutorial; I should be able to look at the ontologies from a field of interest and learn about that field of interest. It probably won’t be an in-depth learning; shallower even than that offered by the excellent resource Wikipedia, which can readily be used as an introduction to a subject area. However, I should be able to get a decent enough view of a field of interest from its ontologies that I can structure my learning from other resources.

The Software Ontology (SWO)

June 19, 2014

Our paper on the Software Ontology (SWO) has just been published in the Journal of Biomedical Semantics (JBMS) thematic issue on ontologies. The paper is:

 

James Malone, Andy Brown, Allyson Lister, Jon Ison, Duncan Hull, Helen Parkinson, and Robert Stevens. The software ontology (swo): a resource for reproducibility in biomedical data analysis, curation and digital preservation. Journal of Biomedical Semantics, 5(1):25, 2014.

 

There’s also a lot of information about how we went about making the SWO at the SWO blog.

 

We now have a range of bio-ontologies covering sequences, gene products, their functions, the processes in which they participate, cellular and gross anatomy, to diseases and phenotypes. These are primarily used to describe the entities in the masses of data biology now produces. More recently, there’s been work on describing the investigations by which these data were produced and analysed; the SWO fits into the ontology landscape at this location. The data is just a load of stuff; we detect things in these datasets with some software and the provenance trail of how these entities were detected needs to include the software that was used.

 

The SWO describes software, the software suites of which it is a part, its inputs and outputs, the tasks it supports, its versions, licencing its interface, and its developers. It doesn’t capture the hardware upon which the software runs, the software’s dependencies, cost of ownership (not the price in lucre, but does it need a lot of sys admin kind of thing), software architecture… (see the paper and blog for more)

 

The scope of the SWO is thus wide and we could have included a whole lot more than we did; much of the stuff not included is important and useful, but resources are scarce and some of the features, like the hardware, is v hard to represent. One of the major problems in writing an ontology is scope and mission creep – how do we stop modelling the world and spending inordinate amounts of time on pathological edge cases? To help us in this we used some Agile techniques in producing the SWO. Perhaps the most useful was the “planning poker” and “buy a feature” games we played. In the SWO project we used a bunch of stakeholders to help us out and the use of these techniques in the SWO went something like this:

 

  1. We did the usual thing of asking for competency questions (which play the role of user stories); clustering them and drawing out a set of features that needed to be modelled.
  2. For the planning poker, we asked people to estimate the effort needed to represent the feature on a numeric scale. Here the trick is that everyone has cards with notional costs written upon them. All cards are held up simultaneously to prevent bias from the first to reveal his or her card. Discussion ensues and a consensus effort for the ontological feature is decided upon.
  3. We then did the same thing for choosing a feature. Depending on the values for effort an amount of “money” is calculated and distributed evenly amongst the stakeholders; there is not enough money to buy everything. Each feature has a cost and each stakeholder can spend his or her money on the features he or she thinks most important. negotiating and so on takes place and features to be modelled are either bought or not bought.

This actually worked well and produced a list of prioritised SWO features. We didn’t do it often enough, as priorities and cost estimations change, but features to be modelled could be seen to be changed on one iteration of the planning. In the SWO we think this technique struck a good balance between what was needed and what was achieveable.

 

We also needed to add content for these features to the SWO. In the first round this was driven by what our customers needed – this was largely, but not exclusively, the EBI’s Gene Expression Atlas. Later on, we’ve been a bit more systematic about what to put into the SWO. Using a named entity recogniser for bioinformatics software and databases (BioNERDS) we’ve done a survey of all PMC for mentions of said bioinformatics databases and software. We pulled out the top 50 of these software mentions and we’re slowly ploughing our way through those (I’ve put this list at the end of this Blog).

 

The paper itself is one in the JBMS thematic series on ontologies; it does for ontologies what the NAR annual database issue does – describes, in this case, ontologies, their state of play and what updates have happened. This is what the SWO paper does. It has the motivation – we need to know how our data were produced and analysed and software plays a crucial role in this analysis. The paper describes what features were bought by our stakeholders, how we axiomatised descriptions of these software features and outlines some of the more tricky modelling issues. My two favourite tricky bits were:

 

  1. Versions of software. The vast variety of versioning schemes is horrid to represent; we did it with individuals of the class “version name”representing a version for a given bit of software. These versions are linked to preceding and succeeding versions to support the obvious queries. It’s not beautiful, but works well enough.
  2. Licences for software. Again, this has to support the variety of the multitude of licences,but the interesting thing here is to be able to infer that, for instance, a bit of software is open source – the paper describes the axiom pattern to do this trick.

 

 

The paper also describes the SWO’s merger with EDAM, which has brought a lot of content into the SWO. The SWO is being used, and not just by the EBI (the paper has some examples) and will continue to grow. The SWO represents a complex field of human developed artefacts. In doing so the SWO team has very much taken a pragmatic approach in its representation. The SWO is already quite complex, but we have tried to avoid being too baroque.

 

Here’s the top 50 as produced by BioNERDS (it’s actually 49 and there’s a couple of glitches in this data, but it’s good enough)

 

R

PSI-BLAST

BLAT

Firefox

neighbor

BLAST

FASTA

Entrez

Tree View

PSSM

UCSC Genome Browser

MATLAB

RepeatMasker

Weka

SAM

Q

Apache

Image

PAML

Phred

Network

Cytoscape

MIPS

EMBOSS

TMHMM

ClustalW

BLASTN

DAVID

ClustalX

BLASTP

Bioconductor

SAM

MEME/MAST

T-COFFEE

MUMmer

Cluster

HMMER

MUSCLE

SOAP

Primer3

analysis

PHYLIP

PostgreSQL

Match

PhyML

 

Excel

MEDLINE

Microarray Suite

SEQUEST

       

MAFFT

Exploring what authors actually do when creating an ontology

May 12, 2014

 

Following our qualitative investigation into the issues people have in using ontologies, we’ve been delving further into what a group of experienced ontology authors actually do when they’re creating an ontology. This is all part of a wider goal of exploring the HCI of ontology authoring so that we can gain a better understanding of how people go about authoring, their patterns of activity and when they need support in understanding the consequences of their actions in a cognitively and perceptually challenging situation. This is all part of the EPSRC funded “What if…?” project where we’re looking at “what if..?” questions – that is, “what happens if I add this axiom….?”; The work reported here has been done by Markel Vigo, Caroline jay and myself. In brief, what we’ve done is to:

  • Instrument a version of Protégé 4 so that all actions (button presses, edits, mouse movements etc.) are recorded and time-stamped in a log-file – this is Protégé for user studies (Protégé4US);
  • We used an eye-tracker to record at what authors were looking at while they were authoring their ontology;
  • Capture full screen and audio recordings;
  • Ask our participants to undertake a series of ontology authoring tasks.

The tasks we asked the authors to undertake were based on creating an ontology of potato varieties that described their cropping time, yield and culinary role. One of the tricks about this kind of experiment is to find examples that are reasonably accessible to a wide variety of authors; this example arrived because I was planting this year’s potatoes. In three stages, we asked authors to add the classes and restrictions necessary for each aspect of potato varieties, increasingly complex defined classes, and then to reason and look at the ontology.

The paper entitled “Protégé4US: Harvesting Ontology Authoring Data with Protégé” at the Human Semantic-Web Interaction (HSWI) workshop at ESWC 2014 is available and gives more details on the work, below I pick out a few high-lights. The pictures are generated from the log files, which enable re-construction of what the author has done, from button presses, mouse clicks, etc. to the OWL constructs used in the tasks.

For instance, the picture below reconstructs the authoring events visualised as a web diagram, where the thickness of the arrow indicates a higher frequency of transitions between events (circles indicate reflexive transitions). For this particular user, we can observe how some interesting transitions stand out:

  • The expansion of a class hierarchy is followed by another expansion; similarly, the selection of an entity is followed by another selection. This suggests that users are drilling down the hierarchy; also, they click on classes to view their description.
  • The reasoner is invoked when entities have been modified. For instance, adding a property to a class or making a class defined is often followed by saving the file and invoking the reasoner.


The time diagram below shows a complementary visualisation of the same participant, where the Y-axis indicates the event and the X-axis is the time elapsed in minutes. The blue blocks denote the time in between events and the red dots are mouse events such as mouse hovers or mouse clicks. These have been plotted as well so that we know when there is user activity.

 


In the strategies described above we said that users click on classes to view their descriptions. This is a hypothesis supported by our preliminary data analysis and by our observations. Eye-tracking data will accurately shed light on what users do during the periods of interaction inactivity, especially in situations in which users are looking to the consequences of their actions in Protégé.

As well as the log-files, we also collected self-reported OWL and Protégé expertise. With this information we were able to explore, for example, correlations between expertise and task completion, time and task completion, number of actions and task completion time, the ngrams of UI actions, the Protégé tabs used, and, as described above, patterns of activity in what authors are doing as they create an ontology. More things are reported in the paper, but this rich recording of what authors do enables us to explore many aspects of authoring and suggests hypotheses for further investigation.

The HSWI paper shows the kinds of analysis it is feasible to do with a tool such as Protégé4US and the things we pull out in the paper are:

  • We identified two types of users based on how they use the tabs of Protégé;
  • Find correlates between interaction events and performance metrics that corroborates our initial insights: a higher number of times the reasoner is invoked and the class hierarchy is expanded indicates trouble and thus, longer completion times;
  • Visualise emerging activity patterns: e.g. an ontology is saved before invoking the reasoner and after modifying an entity.

This suggests that Protégé4US has potential to deliver data whose analysis will expand our knowledge about the ontology authoring process, identify its pitfalls, propose design guidelines and develop intelligent authoring tools that anticipate user actions in order to support ontology authoring in the future. Next comes more analysis and doing more interesting ontology authoring tasks and eventually looking at authors actually doing their ontology day jobs on the ontologies they actually create. There’s not much HCI around in the ontology and OWL field, especially in the evaluation of ontology tools and looking at what users actually do in fine detail. This work and Protégé4US is a first step in this direction.


 

Competence questions, user stories and testing

February 2, 2014

The notion of competency questions as a means of gathering requirements for and a means of evaluation of an ontology comes from a paper by Gruninger and Fox in 1994: “These requirements, which we call competency questions, are the basis for a rigorous characterization of the problems that the enterprise model is able to solve, providing a new approach to benchmarking as applied to enterprise modelling and business process engineering. Competency questions are the benchmarks in the sense that the enterprise model is necessary and sufficient to represent the tasks specified by the competency questions and their solution. They are also those tasks for which the enterprise model finds all and only the correct solutions. Tasks such as these can serve to drive the development of new theories and representations and also to justify and characterize the capabilities of existing theories for enterprise modelling.” And “We use a set of problems, which we call competency questions that serve to characterize the various ontologies and microtheories in our enterprise model. The microtheories must contain a necessary and sufficient set of axioms to represent and solve these questions, thus providing a declarative semantics for the system.” Here we read “enterprise model” as ontology (or, more correctly, that an enterprise model may have as a part an ontology, as a KR can have other thins than an ontology…).

 

Below you can see examples of what we gathered as competency questions during some Pizza tutorials. They mostly take the form of example questions:

 

  • Find me pizza with hot spicy peppers
  • What sorts of pizza base are there?
  • What vegetarian pizzas are there?
  • What pizzas are there with more than one type of cheese?
  • What kinds of pizza contain anchovy?

     

     

    What we usually do is to cluster these in several ways to find the major categories we need in the ontology; we also extract example class labels and so on. It also feeds into the abstractions; gathering together Vegetable, fish, meat as types of ingredient. The CQ can also pull out things like qualities of these ingredients – spiciness and so on. Usually there are many versions of the same kind of questions. A few examples are:

     

  • Find pizza with ingredient x
  • Find pizza with ingredient x, but not y
  • Find pizza without ingredient z
  • Find pizza with ingredient that has some quality or other

 

We can view the informal, natural language competency questions like user stories in agile software engineering techniques. We use a typical template for a user story:

 

As a role I want to do task for a benefit

 

Usually, “benefit” boils down to money. We can adapt the “five whys” technique for problem solving; ask why the role holder of the user story why they want the task (return on investment) and, when applied with some skill, one can get to a root justification for the user story. Often it is money, but sometimes users ask for edge cases – this is often especially true of ontology types – some fun, intricate or complex modelling or logic can ensue for no real return. I’ve done this kind of thing a bit and found it rather useful at weeding out spurious user stories, but also getting better justifications and thus higher priorities for a user story.

 

I’ll carry on this blog with the CQ

 

“Find pizza with anchovy but not capers”

 

We could take our example CQ and do the following (in the context of the Intelligent Pizza Finder):

 

“As a customer I wish to be able to find pizza that have anchovy but no capers, because I like anchovy and don’t like capers”

 

And abstract to

 

As a customer I want to find pizzas with and without certain ingredients to make it easier to choose the pizza I want.

 

The benefit here bottoms out in money (spending money on something that is actually desired), but goes through customer satisfaction through finding what pizza to buy with more ease. Such a user story tells me that my ontology must describe pizza in terms of their ingredients, and therefore have a description (hierarchy) of ingredients, as well as needing to close down descriptions of pizzas (a pizza has this and that, and only this and that (that is, no other). Other CQ user stories give me other requirements:

 

As a vegetarian customer I want to be able to ask for vegetarian pizzas, otherwise I won’t be able to eat anything.

 

This suggests I need abstractions over my ingredients. User stories can imply other stories; an epic user story can be broken down into smaller (in terms of effort) user stories and this would seem like a sensible thing to do. If CQ are thought of in terms of user stories, then one can bring in techniques of effort estimation and do some planning poker. We did this quite successfully in the Software Ontology.

 

In engineering, and especially Agile software engineering, these CQ or user stories also gives me some acceptance tests – those things by which we can test if the product is acceptable. A competence question obviously fits neatly into this – my ontology should be competent to answer this question. Acceptance tests are run against the software, with inputs and expected outputs; a user story is not complete until the acceptance test(s) is passed. For competence questions as acceptance tests, input data doesn’t really make sense, though results of the competence question do make sense as “output” data.

 

If we take a natural language CQ such as

 

Find me pizza with anchovy, but no capers

 

We may get a DL query like

 

Pizza and (hasTopping some AnchovyTopping) and (hasTopping only not CaperTopping) 

 

Which I can use as a test. I was stumped for a while about how not necessarily having any ontology and not knowing the answer makes running the test “before” and knowing whether it has passed or failed hard. However, it may all fall out easily enough (and may have been already done in some environments); here’s the scenario

 

  1. I have my query: Pizza and (hasTopping some AnchovyTopping) and (hasTopping only not CaperTopping) and no ontology; I’m setting up the ontology and a “test before” testing style.
  2. The test fails; I can pass the test by adding Pizza, hasTopping AnchovyTopping and CaperTopping to my currently empty ontology; the test passes in that the query is valid
  3. I also add pizzas to my test that I expect to be in the answer – NapolitanaPizza; again, the test fails
  4. I add NapolitanaPizza and the test is valid in that the entities are there in the ontology, but I need to add NapolitanaPizza as a subclass of Pizza for there to be any chance of a pass.
  5. I do the addition, but still the test fails; I need to re-factor to add the restrictions from NapolitanaPizza to its Ingredients (tomatotopping, CheeseTopping, Olivetopping, Anchovytopping and Capertopping)
  6. My test passes

 

 

I’m bouncing between the test itself passing a validity test and the ontology passing the test. It’s easier to see these as tests all working in a test after scenario, but it can work in a test before scenario, but seems a bit clunky. This could perhaps be sorted out in a sensible environment. I could even (given the right environment) mock up parts of the ontology and supply the query with some test data.

 

My example query does imply other test queries as it implies other bits of pizza ontology infra-structure. There’s an implication of a pizza hierarchy and an ingredients hierarchy. We’d want tests for these. Also, not all test need be DL Queries – we have SPRQL too (see, as an example, tests for annotations on entities below).

 

There are other kinds of test too:

  1. Non-logical tests – checks that all classes and properties have labels; there’s provenence information and so on.
  2. Tests that patterns are complied with – normalisation, for instance, could include test for trees of classes with pairwise disjoint siblings.
  3. Tests to check that classes could be traced back to some kind of top-level ontology class.
  4. Tests on up-to-dateness with imported portions of ontology (Chris Mungall and co describe continuous integration testing in GO).

 

Some or all of which can probably be done and are being done in some set-ups. However, as I pointed out in a recent blog about the new wave of ontology environments needs to make these types of testing as easy and as automatable and reproducible as it is in many software development environments.

Issues in authoring ontologies

January 31, 2014

We’ve recently had a short paper accepted to Computer Human Interaction (CHI) where we describe the outcomes from a qualitative study on what ontologists do when they author an ontology. The paper is called “Design Insights for the Next Wave Ontology Authoring Tools” and the motivation is a desire to understand how people currently go about authoring ontologies (the work was carried out by Markel Vigo in collaboration with Caroline Jay and me). Ultimately we want to understand how people judge the consequences of adding axioms so that we can support the answering of “what if…?” questions (and we’ll do this by creating models of ontology authoring). So, if I add some axiom to a large system of axioms what will be the consequences. As we work up to this, we’re doing studies where we record what people are doing as they author an ontology, logging all activities in the Protégé 4 environment, as well as capturing screen recordings and eye-tracking data.

 

This first study was a qualitative study where we asked 15 experienced ontology builders a series of open questions:

 

  • Can you describe the authoring tasks you perform?
  • How do you use tools to support you in these tasks?
  • What sort of problems do you encounter?

 

You can read the details of the method and analysis in the paper. We chose to do this study with experienced ontology authors as this will, in the fullness of time, inform us about how authoring takes place without any confounding factors such as not fully understanding ontologies, OWL or tools being used. Understanding issues faced by novices also needs to be done, but that’s for another time.

 

The 15 participants partition into three groups of five: Ontology researchers; ontology developers; and ontology curators. These, in turn, are CS types who do research on ontology and associated tools and techniques; ontology developers are CS types that work closely with domain experts to create ontologies; curators are those that have deep domain knowledge and maintain, what are often, large ontologies.

 

The tools participants use are (here I list those with numbers of users above one): Protégé (14 users), OWL API (6), OBO-Edit (4) and Bioportal (3). We didn’t choose participants by the tools they used; these are the tools that the people we talked to happened to use.

 

The analysis of the interviews revealed themes based on the major tasks undertaken by ontologists; the problems they encounter and the strategies they use to deal with these problems.

 

  1. Sense-making, exploration and searching: Knowing the state of the ontology, finding stuff, understanding how it’s all put together – “making sense” of an ontology.
  2. Ontology building: Efficiently adding axioms to an ontology en mass and effectively support what we called “definition orientated” ontology building.
  3. Reasoning: Size and complexity of ontologies hampering use of ontologies.
  4. Debugging: Finding faults and testing ontologies.
  5. Evaluation: is it a good thing?

 

The paper describes in more detail the strategies people use in these five themes. For instance, speeding up reasoning by restricting the ontology to a profile like OWL EL and using a fast reasoners like ELK; chopping up the ontology to make reasoning faster; relying on user feedback for evaluation; using repositories and search tools to find ontologies and re-use parts of them; using the OWL API to programmatically add axioms; and so on (the paper gives more of the strategies people use).

 

There will be other issues; there will be ones we may not have encountered through our participants and there will be important issues that were in our interviews, but may not have been common enough to appear in our analysis.

 

There may well be tools and techniques around that address many of the issues raised here (we’ve done some of them here in Manchester). However, this sample of ontology authors don’t use them. Even if tools that address these problems exist, are known about and work, they don’t work together in a way that ontology authors either can use or want to use. So, whilst we may have many useful tools and techniques, we don’t have the delivery of these techniques right. What we really need to build the new wave of ontology authoring environments are models of the authoring process. These will inform us about how the interactions between author and computational environment will work. This qualitative study is our first step on our way to elucidating such a model. The next study is looking at how experienced ontology authors undertake some basic ontology authoring tasks.

Manchester Advanced OWL tutorial: Family History

January 28, 2014

Manchester Family History Advanced OWL Tutorial

Dates: 27th/28th February 2014

Time: 10am – 5pm

Location: Room G306a Jean McFarlane Building, University of Manchester.

The Bio-Health Informatics Group at The University of Manchester invites you to participate in a newly developed OWL Ontology that covers more advanced language concepts for OWL.

The overall goal for this tutorial is to introduce the more advanced language concepts for OWL. This new tutorial builds on the Manchester Pizza Tutorial, by exploring OWL concepts in greater depth, concentrating on properties, property hierarchies, property features and individuals.

 

The topic of family history is used to take the tutee through various modelling issues and, in doing so, using many features of OWL 2 to build a Family History Knowledgebase (FHKB). The exercises involving the FHKB are designed to maximise inference about family history through use of an automated reasoner on an OWL knowledgebase (KB) containing many members of the Stevens family. The aim, therefore, is to enable people to learn advanced features of OWL 2 in a setting that involves both classes and individuals, while attempting to maximise the use of inference within the FHKB.

 

By the end of the tutorial you will be able to:

  1. Know about the separation of entities into TBox and ABox;
  2. Use classes and individuals in modelling;
  3. Write detailed class expressions;
  4. Assert facts about individuals;
  5. Use the effects of property hierarchies, property characteristics, domain/range constraints to drive inference;
  6. Use property characteristics and subproperty chains on inferences about individuals
  7. Understand and manage the consequences of the open world assumption in the TBox and ABox;
  8. Use nominals in class expressions;
  9. Appreciate some of the limits of OWL 2;
  10. Discover how many people in the Stevens family are called “James”.

 

The tutorial is led by Professor Robert Stevens and run by a team of experienced OWL users and researchers from Manchester.

 

Supplementary material for the tutorial can be found at: http://owl.cs.manchester.ac.uk/publications/talks-and-tutorials/fhkbtutorial/

The cost of the course is £250 per day.

 

Registration and Further Information

To register, please email Kieran O’Malley

(kieran.omalley@manchester.ac.uk) prior to February 21st 2014. Payment options will be returned to you following reservation. For further information please visit the website at:

http://owl.cs.manchester.ac.uk/

Generating natural language from OWL and the uncanny valley

January 28, 2014

There is this phenomenon called the uncanny valley where, in situations like CGI, robotics etc., if as the human-like thing gets closer and closer to being human, but not quite human, then the human observer is sort of weirded or creeped out. If the human-like thing obviously isn’t human, say a simple cartoon, all is OK, but if it is almost human then people really don’t like it.

 

In our recent work on natural language generation (NLG) from OWL I’ve noticed a related phenomenon; readers aren’t weirded out by the generated and somewhat clunky English, but are irritated or piqued by it in a way they wouldn’t be by, for instance, some Manchester Syntax for the same axioms or some hand-crafted, but not perfect, text. The Manchester Syntax is further away from “naturalness”, but apparently less irritating – perhaps because the expectations are less. Manchester syntax for some axioms is easy enough to make a “correct” instance of what it is (Manchester Syntax); it’s not so easy to make natural language “natural”, but if we get close-ish, we’ve met a “valley”, perhaps of irritation. It’s not really an uncanny valley we’ve seen in our work with natural language generation from OWL ontologies, but when we generate sentences and paragraphs from OWL readers like the NLG form, but are caused irritation by English that is almost English, but not quite “natural” natural language. As we’ll see, this may be the nature of the errors; they’re basic errors in, for instance, the use of articles and plurals – not grammar fascism.

 

Doing NLG from an OWL axiom is sort of obvious; an axiom is a correlate of a sentence and we have nouns (and adjectives) in the form of classes and individuals, then properties (relationships) often do verby like things. A class or concept is the correlate of a paragraph; it’s what we want to say on a topic. So, we can take a set of axioms for classes from Snomed CT like

 

Class: Heart Disease

SubClassOf: (Disorder of Cardiovascular System) and (is-located-in some Heart Structure)

 

and similarly for hypertensive heart disease:

 

Class: Hypertensive heart disease

SubClassOf: (Heart Disease) and (is-associated-with some Hypertensive disorder)

 

And produce paragraphs like

 

A heart disease is a disorder of the cardiovascular system that is found in a heart structure.

 

and

 

A hypertensive heart disease is a heart disease that is associated with a hypertensive disorder.

 

These paragraphs are oK (produced by OntoVerbal), but are not “beautiful” English prose. In these cases, we’ve got the articles right etc, but it all seems a little plodding. There is some clunkiness that is a little irritating, but overall I think they’re pretty good and give a decent view on a set of axioms that can be fairly hard work to read. It is possible to produce better English, but at the cost of making a bespoke verbaliser for each ontology, especially for the “unpacking” of complex class labels to get articles and plurals correct; OntoVerbal is generic (though we did a little local fixing to help out with articles for Snomed classes). However, what we did do in OntoVerbal is to try and generate coherent, structured paragraphs of text for a class’ axioms. To get this coherence (rather than a set of sentences from unordered axioms for a class) we used rhetorical structure theory (RST) and mapped various types of OWL axioms to roles within RST. Example RST roles are evidence, motivation, contrast, elaboration, result, cause, condition, antithesis, alternative, list, concession and justification. these may be implicit within a text, but are often signalled by “discourse markers”; as “because” for evidence, “in order to” for enablement, “although” for antithesis, “but” for concession, “and” for list, “or” for alternative, etc You can see how we put all of this together in our IJACSA paper.

 

 

In the IJACSA paper we did an evaluation to look at the acceptability of these types of rendering and whether they were faithful enough to the OWL to allow “round-tripping” – that people experienced in OWL could take the verbalised OWL and re-produce the OWL axioms in Manchester Syntax. We also looked at the quality by comparing the machine verbalisations to human generated verbalisations. The argument is that a human produces good quality text (under the constraints given), so if the OntoVerbal text is similar to the human written text, then it should be of reasonable quality. Below are the OWL axioms from SNOMED for 10 classes. There are natural language verbalisations generated by a human (not in the project) and by OntoVerbal.

 

 

Number

OWL input

OntoVerbal

Ontologist

1

pelvic structure SubClassOf: lower trunk structure

lower trunk structure SubClassOf: structure of subregion of the trunk

pelvic structure SubClassOf: the pelvis and lower extremities and the abdomen and the pelvis and lower trunk structure

A lower trunk structure is a kind of structure of subregion of the trunk. A more specialised kind of lower trunk structure is pelvic structure. Another relevant aspect of lower trunk structure is that a pelvic structure is defined as the pelvis and lower extremities, the abdomen and the pelvis and a lower trunk structure.

A lower trunk structure is a structure of the subregion of the trunk. A pelvic structure is a subtype of a lower trunk structure.

2

procedure on the brain SubClassOf: intracranial procedure

intracranial procedure SubClassOf: procedure on the central nervous system

intracranial procedure SubClassOf: procedure on the head

intracranial procedure EquivalentClass procedure by site and has a procedure site some intracranial structure

An intracranial procedure is a kind of procedure on the central nervous system and procedure on the head. A more specialised kind of intracranial procedure is procedure on the brain. Additionally, an intracranial procedure is defined as a procedure by site that has a procedure site in an intracranial structure.

An intracranial procedure is a procedure on the central nervous system and a procedure on the head. Any procedure by site in which the procedure site is an intracranial structure is also an intracranial procedure. A procedure on the brain is a subtype of intracranial procedure.

3

abdominal vascular structure SubClassOf: abdominal and pelvic vascular structure

abdominal and pelvic vascular structure SubClassOf: vascular structure of the trunk

abdominal vascular structure SubClassOf: abdominal structure and abdominal and pelvic vascular structure

An abdominal and pelvic vascular structure is a kind of vascular structure of the trunk. A more specialised kind of abdominal and pelvic vascular structure is abdominal vascular structure. Another relevant aspect of abdominal and pelvic vascular structure is that an abdominal vascular structure is defined as an abdominal structure and an abdominal and pelvic vascular structure.

An abdominal and pelvic vascular structure is a vascular structure of the trunk. An abdominal vascular structure is a subtype of an abdominal and pelvic vascular structure.

4

chronic disease of the genitourinary system SubClassOf: chronic disease

chronic disease of the genitourinary system SubClassOf: disorder of the genitourinary system

chronic hypertensive uraemia SubClassOf: chronic disease of the genitourinary system

chronic disease of the genitourinary system EquivalentClass: chronic disease and disorder of the genitourinary system and has a finding site some structure of the genitourinary system

Chronic disease of the genitourinary system is a kind of chronic disease and disorder of the genitourinary system. A more specialised kind of chronic disease of the genitourinary system is chronic hypertensive uraemia. Additionally, chronic disease of the genitourinary system is defined as chronic disease that is a disorder of the genitourinary system, and has a finding site in a structure of the genitourinary system.

A chronic disease of the genitourinary system is a chronic disease and a disorder of the genitourinary system. Any chronic disease which is also a disorder of the genitourinary system and is found in the structure of the genitourinary system is also a chronic disease of the genitourinary system. A chronic hypertensive uraemia is a subtype of a chronic disease of the genitourinary system.

5

finding of the head and the neck region SubClassOf: finding of the body region

head finding SubClassOf: finding of the head and the neck region

finding of the head and the neck region EquivalentClass: finding of the body region and has a finding site some head and neck structure

head finding EquivalentClass: finding of the head and the neck region and has a finding site some head structure

A finding of the head and the neck region is a kind of finding of the body region. A more specialised kind of finding of the head and the neck region is head finding. Additionally, A finding of the head and the neck region is defined as a finding of the body region that has a finding site in a head and neck structure. Another relevant aspect of finding of the head and the neck region is that a head finding is defined as a finding of the head and the neck region that has a finding site in a head structure.

A finding of the head and the neck region is a finding of the body region. Any finding of the body which is found in a head and neck structure is also a finding of the head and neck region. A head finding is a subtype of the finding of the head and the neck region.

6

nephrosclerosis SubClassOf: degenerative disorder

degenerative disorder SubClassOf: disease

arteriosclerotic vascular disease SubClassOf: degenerative disorder

degenerative disorder EquivalentClass: disease and has an associated morphology some degenerative abnormality

Degenerative disorder is a kind of disease. More specialised kinds of degenerative disorder are nephrosclerosis and arteriosclerotic vascular disease. Additionally, degenerative disorder is defined as disease that has an associated morphology in a degenerative abnormality.

A degenerative disorder is a disease. Any disease which has an associated morphology of degenerative abnormality is also a degenerative disease. Nephrosclerosis and arteriosclerotic vascular disease are subtypes of degenerative disease.

7

kidney graft material SubClassOf: urinary tract material

kidney graft material SubClassOf: solid organ graft material

kidney graft material SubClassOf: urinary tract material and solid organ graft material

transplant of the kidney EquivalentClass: kidney operation and solid organ transplant and renal replacement and has a method some surgical transplantation action and has a direct substance some kidney graft material and has an indirect procedure site some kidney structure

A kidney graft material is a kind of urinary tract material and solid organ graft material. Another relevant aspect of kidney graft material is that a transplant of the kidney is defined as a kidney operation that is a solid organ transplant, and is a renal replacement, and has a method in a surgical transplantation action, and has a direct substance in a kidney graft material, and has an indirect procedure site in a kidney structure.

Kidney graft material is a urinary tract material and a solid organ graft material. A kidney operation, solid organ transplant and renal replacement which has a method of surgical transplantation action, a direct substance of kidney graft material and an indirect procedure site of kidney structure is a type of transplant of the kidney.

8

graft SubClassOf: biological surgical material

tissue graft material SubClassOf: graft

tissue graft material SubClassOf: graft and body tissue surgical material

A graft is a kind of biological surgical material. A more specialised kind of graft is tissue graft material. Another relevant aspect of graft is that a tissue graft material is defined as a graft and a body tissue surgical material.

A graft is a biological surgical material. Tissue graft material is a subtype of graft as well as a body tissue surgical material.

9

benign essential hypertension complicating and/or reason for care during pregnancy SubClassOf: essential hypertension complicating and/or reason for care during pregnancy

essential hypertension complicating and/or reason for care during pregnancy SubClassOf: essential hypertension in the obstetric context

essential hypertension complicating and/or reason for care during pregnancy SubClassOf: pre-existing hypertension in the obstetric context

essential hypertension complicating and/or reason for care during pregnancy SubClassOf: essential hypertension in the obstetric context and pre-existing hypertension in the obstetric context

benign essential hypertension complicating and/or reason for care during pregnancy SubClassOf: benign essential hypertension in the obstetric context and essential hypertension complicating and/or reason for care during pregnancy

Essential hypertension complicating and/or reason for care during pregnancy is a kind of essential hypertension in the obstetric context and pre-existing hypertension in the obstetric context. A more specialised kind of essential hypertension complicating and/or reason for care during pregnancy is benign essential hypertension complicating and/or reason for care during pregnancy. Another relevant aspect of essential hypertension complicating and/or reason for care during pregnancy is that benign essential hypertension complicating and/or reason for care during pregnancy is defined as benign essential hypertension in the obstetric context and essential hypertension complicating and/or reason for care during pregnancy.

An essential hypertension complicating and/or reason for care during pregnancy is an essential hypertension in the obstetric context and a pre-existing hypertension in the obstetric context. A benign essential hypertension complicating and/or reason for care during pregnancy is a subtype of essential hypertension complicating and/or reason for during pregnancy.

10

procedure on artery of the abdomen SubClassOf: procedure on the abdomen

procedure on artery of the abdomen SubClassOf: procedure on artery of the thorax and the abdomen

abdominal artery implantation SubClassOf: procedure on artery of the abdomen

procedure on artery of the abdomen EquivalentClass: procedure on artery and has a procedure site some structure of artery of the abdomen

A procedure on artery of the abdomen is a kind of procedure on the abdomen and procedure on artery of the thorax and the abdomen. A more specialised kind of procedure on artery of the abdomen is abdominal artery implantation. Additionally, a procedure on artery of the abdomen is defined as a procedure on artery that has a procedure site in a structure of artery of the abdomen.

A procedure on artery of the abdomen is a procedure of the abdomen and a procedure on artery of the thorax and the abdomen. Any procedure on artery which has a procedure site of structure of artery of the abdomen is also a procedure on artery of the abdomen. An abdominal artery implantation is a subtype of procedure on artery of the abdomen.

 

 

 

You can see that the verbalisations are fairly similar. Given the task of being faithful to the OWL and enabling “round-tripping”, very similar texts are produced by a human and OntoVerbal; the machine and human verbalisations are of a very similar quality. Evaluators could use both to round-trip to the OWL axioms, but did better with the OntoVerbal generated axioms. This is, we think, at least in part due to OntoVerbal being more “complete” in its verbalisation. The human verbalisation is smoother, but presumably not as smooth as a description written by a human domain expert could be (though do look at James Malone’s blog on this topic). However, I suspect that such smooth, natural language texts would be much harder to match to a set of OWL axioms.

 

Where does this leave my uncanny valley or valley of irritation for generated natural language? Domain expert humans writing definitions without the constraint of being faithful to the ontology’s axioms will probably avoid the valley of irritation; if there’s too much “ontologising” in the verbalisation there will be irritation (this came up in another paper on an earlier verbalisation); if there’s clunky English there is irritation. In a generic tool like OntoVerbal this is probably inevitable and I suspect it’s irritating as these are minor English errors that are always irritating as they disrupt reading. However, the use of rST does seem to give OntoVerbal’s NLG verbalisations a good level of coherence and fluency, even if they’re not perfectly fluent. They are also cheap to produce…. As they are close to the OWL they give an alternative view on those axioms – one thing I’d like to find out is if a verbalised view is any better (or worse) at allowing error spotting – and whther it is the verbalisation or just the alternative that does the job). One could also provide a variety of verbalisations – hand-crafted, luxury ones; ones close to the OWL and ones with and without the often inpenetrable words used in ontologies (especially for relationships).

My first publication discovered

December 24, 2013

I’ve been poking around in the long-tail of my publications as gathered by Google Scholar. Within this I found the following little publication:

 

Five glycyl tRNA genes within the noc gene complex of Drosophila melanogaster.

YB Meng, RD Stevens, W Chia, S McGill, M Ashburner

Nucleic acids research 16 (14), 7189-7189 1988

 

And this must be me. I did my undergraduate biochemistry project with bill Chia and I sequenced, by hand, some tRNA genes in drosophila. This is the first I’ve known of this publication and it has made me happy – that my sausage like fingers clumsily squirting stuff around willy nilly in bill’s lab actually earnt me a name on the paper; it is a lovely thing to find.

 

This should be my opportunity to drone on about pouring polyacrylamide gels, doing dideoxy reactions, running gels, exposing autoradiograms, reading gels, etc etc., but that’s enough of that. I should also perhaps say that using the lab’s BBC microcomputer to run a programme over-night to find tRNA genes was the start of my interest in bioinformatics – but it wasn’t. It was, however,a continuation of an interest in what was then known as molecular biology; ultimately bioinformatics has been a way of carrying on that interest.

Making scholarly articles born semantic

August 14, 2013

In Sepublica 2012 I did the invited keynote talk entitled “Semantic Publishing: What does it all mean anyway?”. This was on the back of an increasing interest I have in semantic publishing, motivated by the work Phil Lord and I have done on the Ontogenesis knowledgeblog. The invitation itself was, I suspect, also on the back of the fun I had with the ontology submission I did to sepublica that year, which was just of the RDF of the Amino Acids Ontology. Nevertheless, I did the keynote and one of the things I did in the talk was to make the distinction between a scholarly article being born semantic and made semantic.

 

We can author a scholarly document and then add semantics post hoc – for instance, labelling entities with their semantic type – authors, proteins, genes, tools etc., as well as elements of document structure, the nature of the citations (and other stuff you will find in the Semantic Publishing and Referencing Ontologies (SPAR) suite of ontologies). All this is done after the author writes, by hand or through text-mining, etc.

 

In contrast, this could also be done at authoring time, with the encoding of the semantics being done by the author at the time of authoring – rather than by a third party post publication, which would typically be the case in being “made semantic” – with all the obvious issues of such things. So, the author does the same kind of semantic mark-up as before, but as he or she writes the document; the semantics then persist through the publication process and then the semantic content is available both for readers and machines

 

When talking about this to my colleague Sean Bechhofer, he made the analogy with analogue and digital photographs and music being either “born digital” or “made digital”: “However, as of yet, few born-digital (defined in opposition to “made digital” or “digitized” photographs, which are created by scanning analogue sources), photographs have been acquired by archives.” (Becoming Digital: The Challenges of Archiving Digital Photographs, Karen Rae Simonson, University of Manitoba (Canada), 2006). Similarly, in music recordings we had Analogue (A) and Digital (D) recording, Mastering and Publication as either A or D. Compact disks were labelled with AAD to DDD depending of what combinations of analogue/digital recording, mastering and published were used. A piece of music that is DDD is “born digital” music; anything else is “made digital”. A gramophone record would be AAA. So, a scholarly bpublication can be “born semantic” if it is semantic from the start or “made semantic” if the semantics are added post hoc.

 

WE talked about how to make scholarly publications “born semantic” in our “three steps paper“. It’s all very well wanting all this semantics in a paper from its birth, but it doesn’t happen for free. A made semantic paper costs resource and a born semantic paper also costs – in this case for the author. If we think about the three players in the scholarly work game, the author, the reader and the mediating machine, the advantages of semantics are fairly obvious for the reader and the machine. The reader can get better search, active documents where the machine’s ability to use the semantics of a document’s entities can enhance the reading experience by, for instance, doing protein sequence things with things it knows are protein sequences etc etc. the machine, knowing what thins are, can do appropriate things with those entities; it becomes computationally more effective.

 

This leaves the author; what’s in being born semantic for the author? Grief and pain if we’re just asking an author to do loads of mark up. Just as there are advantages for being born semantic for the reader and machine, there needs to be an advantage for the author. This means that the adding of semantics either has to help the author in his or her task or it has to come for “free” as a side-effect of something else the author would do anyway.

 

Phil Lord has started doing some of this in the knowledgeblog. There’s some simple markup that indicates a thing is an author name or a citation . By labelling a DOI or PubMed id as a citation, all my refernces get compiled and styled; one can imagine adding a CiTO attribute as well, though it’s a bit tricky to work out what’s in it for the author). Knowledgeblog does a bit with knowing that a string is an author, but one can imagine labelling something as an ORCID and getting all sorts of stuff for free-a semantically marked up affiliation. On the “semantics bby stealth” side of things, we could have style sheets already marked up with elements of rhetoric structure and so on. This doesn’t really help the author, but should aid machine processing down-the-line; the key is that it costs nothing. (the 3 steps paper above gives more examples.)

 

One of the “not making demands” of an author (without payback) is that a new tool or specialised environment won’t work. Whatever born semantic stuff we use for authoring, it’s got to work in Ms Word, Latex or whatever. Nice WYSWYG tools or v simple markup (if markup is your thing). Any additions by the author have to be low-cost or they won’t happen. This may mean we don’t get a lot of semantics, but that may just be the way that it is – unless the payback is down-the-line with demonstrably more readers and, of course, citations. The other thing that needs to happen is to do away with strange publisher processes that take camera-ready (possibly semantic) documents and re-do them from scratch, which would remove the semantics gained at birth.


 


Follow

Get every new post delivered to your Inbox.

Join 141 other followers