The WordPress.com stats helper monkeys prepared a 2011 annual report for this blog.
Here’s an excerpt:
A San Francisco cable car holds 60 people. This blog was viewed about 3,500 times in 2011. If it were a cable car, it would take about 58 trips to carry that many people.
co-located with the 7th International Conference on Formal Ontologies in Information Systems (FOIS 2012)
22-25 July 2012; Graz, Austria.
Conference Web site: http://purl.org/icbofois2012/
31 December 2011: Workshop and tutorial proposal submission deadline
25 January 2012: Notification of acceptance of workshops and tutorials
31 January 2012: Paper submission deadline
28 February 2012: Notification of paper acceptance
15 March 2012: Poster, early career symposium, software demonstrations and workshop papers submission deadline
15 April 2012: Notification of poster, early career symposium, software demonstrations and workshop paper acceptance
30 June 2012: Deadline for all camera-ready copies for the proceedings
Ontologies are increasingly used in the semantic description of biological and medical data from creation to publication and consumption by semantically enabled applications. To be effective, such ontologies must be of high quality and work well together. Therefore, issues like techniques for ontology use, good ontology design, ontology maintenance, and ontology coordination need to be addressed. The International Conference on Biomedical Ontology (ICBO) series is designed to meet this need. ICBO 2012, the third event in the highly successful series, will bring together representatives of all major communities involved in ontology use and development in biomedical research, health care, and related areas.
ICBO 2012 is soliciting submissions of novel (not previously published nor concurrently submitted) research papers in the areas of the application of ontologies to biomedical problems, ontology design and ontology interoperability, at any stage in the process of data creation to its use in applications. Submissions will be welcome from a broad range of approaches to ontology building and use. In particular, we would like to invite contributions on these aspects of biomedical ontologies, as well as on the use of such ontologies in knowledge management, knowledge discovery and next-generation publishing. We will accept full-length papers (5 pages), poster submissions (1 page abstracts), software demonstrations (2 page abstracts or 5 page full application papers), and early career researcher symposium submissions (2 page abstracts). We are also looking for submissions of half-day or full-day workshops and tutorials. Workshops should be working sessions with a specific outcome that can be subsequently presented at the main conference. Tutorials are educational events and may involve hands-on practicals.
Submission is via EasyChair (https://www.easychair.org/conferences/?conf=icbo-2012), according to the templates provided on the conference web site.
For more information or to offer sponsorship, please send us a note at contact.icbo2012@gmail.com
General Chairs: Ronald Cornet (Amsterdam, The Netherlands) and Robert Stevens (Manchester, UK)
Workshops and Tutorials Chair: Melanie Courtot (Vancouver, Canada)
Early Career Consortium Chair: Ludger Jansen (Rostock, Germany)
Software Demonstration Chair: Trish Whetzel (Stanford, USA)
Proceedings Chair: Janna Hastings (Geneva, Switzerland)
Local Chair: Stefan Schulz (Graz, Austria)
I realised, that having made the Heraldry Ontology (HO) to have an ontology containing unicorns, that I’d not actually put in an escutcheon using a unicorn. Said beast is there in the HO as a mythical creature that can be used as a charge, but I really neded an actyual escutcheon using a unicorn, rather than just having it implied by the HO. The following blazon is, I think, such an escutcheon:
Vert with unicorn argent attired gules with eroteme argent
this has a green background with a white unicorn, with a red horn, with a white eroteme (question mark) underneath.
I’ve extended the HO in a couple of ways to do this a little more properly:
This is how I build up the complex class expressions with everything closed off so my implementation of the rule of tincture would work:
The existential of the escutcheon:
Individual: 'Vert with unicorn argent attired gules with eroteme argent'
Annotations: [in heraldry]
label "Vert with unicorn argent attired gules with eroteme argent"^^string
Types: [in heraldry]
hasPart some
(Field
and ('is charged with' some
(Eroteme
and ('has tincture' some Argent)
and ('has charge priority' value 2)))
and ('is charged with' some
(Unicorn
and ('has creature profile' some Dexter)
and ('has tincture' some Argent)
and (hasPart some
(Horn
and ('has tincture' some Gules)))
and ('has charge priority' value 1)))
and ('has tincture' some Vert)),
Escutcheon
|
Note the unicorn has a part a horn that is red; that is, “attired gules”. I suppose I should say that it has a part “exactly 1 horn” as it is a unicorn… or maybe that goes on the unicorn class. I should also say how many unicorn and so on, but I haven’t.
Putting an “onlysome” on the has tincture some Gules, we get
Individual: 'Vert with unicorn argent attired gules with eroteme argent'
Annotations: [in heraldry]
label "Vert with unicorn argent attired gules with eroteme argent"^^string
Types: [in heraldry]
hasPart some
(Field
and ('is charged with' some
(Eroteme
and ('has tincture' some Argent)
and ('has charge priority' value 2)))
and ('is charged with' some
(Unicorn
and ('has creature profile' some Dexter)
and ('has tincture' some Argent)
and (hasPart some
(Horn
and ('has tincture' onlysome Gules)))
and ('has charge priority' value 1)))
and ('has tincture' some Vert)),
Escutcheon
|
After some automatic re-formattting we get:
(Horn
and (('has tincture' some Gules)
and ('has tincture' only Gules))))
and ('has charge priority' value 1)))
and ('has tincture' some Vert))
|
going all the way through, we get:
Individual: 'Vert with unicorn argent attired gules with eroteme argent'
Annotations: [in heraldry]
label "Vert with unicorn argent attired gules with eroteme argent"^^string
Types: [in heraldry]
* 'Coloured Escutcheon and metal charge',
(hasPart some
(Field
and (('has tincture' some Vert)
and ('has tincture' only Vert))
and ('is charged with' some
(Eroteme
and (('has tincture' some Argent)
and ('has tincture' only Argent))
and ('has charge priority' value 2)))
and ('is charged with' some
(Unicorn
and (('has tincture' some Argent)
and ('has tincture' only Argent))
and ('has creature profile' some Dexter)
and (hasPart some
(Horn
and (('has tincture' some Gules)
and ('has tincture' only Gules))))
and ('has charge priority' value 1)))
and ('is charged with' only
((Eroteme
and (('has tincture' some Argent)
and ('has tincture' only Argent))
and ('has charge priority' value 2))
or (Unicorn
and (('has tincture' some Argent)
and ('has tincture' only Argent))
and ('has creature profile' some Dexter)
and (hasPart some
(Horn
and (('has tincture' some Gules)
and ('has tincture' only Gules))))
and ('has charge priority' value 1))))))
and (hasPart only
(Field
and (('has tincture' some Vert)
and ('has tincture' only Vert))
and ('is charged with' some
(Eroteme
and (('has tincture' some Argent)
and ('has tincture' only Argent))
and ('has charge priority' value 2)))
and ('is charged with' some
(Unicorn
and (('has tincture' some Argent)
and ('has tincture' only Argent))
and ('has creature profile' some Dexter)
and (hasPart some
(Horn
and (('has tincture' some Gules)
and ('has tincture' only Gules))))
and ('has charge priority' value 1)))
and ('is charged with' only
((Eroteme
and (('has tincture' some Argent)
and ('has tincture' only Argent))
and ('has charge priority' value 2))
or (Unicorn
and (('has tincture' some Argent)
and ('has tincture' only Argent))
and ('has creature profile' some Dexter)
and (hasPart some
(Horn
and (('has tincture' some Gules)
and ('has tincture' only Gules))))
and ('has charge priority' value 1)))))),
Escutcheon
|
Which, I think, is particularly “manly OWL” (or MOWL). It also, perhaps, shows how writing this sort of thing by hand is so beastly or just shouldn’t be done at all… Putting the charge priorities and creature profiles into the already expanded escutchia will be a real pain, but will just be a matter of being systematic.
Anyway, it classifies proply in the HO as a coloured escutcheon with metal charge. This version of the HO is available.
BFOites often use unicorns as a stick with which to beat those that question the particular sect of realism portrayed in BFO. The argument goes something along the line of “well if you don’t wish to model only universals then you’re prepared to model “unicorn”".
Just so that I can say I’ve built an ontology that has the notion of “Unicorn” I’ve built an ontology of heraldry. As an ontology it is not really up to much, except (as with any ontology) building it has thrown up some modelling issues. Of course, I have to say now, that I suppose everything in this ontology is some kind of information, so I’m not really claiming I havbe an ontology with a “real” unicorn in it; nevertheless, I have an ontology that describes unicorns and other mythical creatures… Also, I’m not describing anything that wouldn’t be captured somewhere in a BFO compliant ontology.
In heraldry, almost anything (a charge) can be placed upon a field. these can be animals (real and mythical), animal parts, man made objects, geometrical symbols, and so on. A field may also be uncharged, that is, plain. With some twiddly bits, the field plus the optional charge is an escutcheon.
the field and charge have a tincture. The tinctures (colours) are traditionally more restricted and divided into “colours” and “metals”. the rule of tincture stipulates that metal should not be placed on metal and vice versa. This stops an argent (white) horse being charged on a field of Or (yellow). There is an exception where the natural tincture of the charge is placed on a field of the same tincture –”a horse argent proper”; I’ve not attempted this at the moment.
We can capture the rule of tincture in OWL, but it is a bit convoluted. there are three options:
My Heraldry Ontology (The HO) captures the ruel of tincture. I’ve done it using option three in the following way:
The four classes involved are:
1.
Class: Escutcheon
Annotations: [in heraldry]
comment "A shield; can have a shield with a field but no charge."^^string,
label "Escutcheon"^^string
EquivalentTo: [in heraldry]
* Escutcheon,
'Plain escutcheon'
or 'Coloured Escutcheon and metal charge'
or 'Metal escutcheon and coloured charge'
SubClassOf: [in heraldry]
hasPart only Field
|
2.
Class: 'Plain escutcheon'
Annotations: [in heraldry]
label "Plain escutcheon"^^string,
comment "A tinctured field with no charges."^^string
EquivalentTo: [in heraldry]
* 'Plain escutcheon',
Escutcheon
and (hasPart some
(Field
and (not ('is charged with' some Charge))
and ('has tincture' some Tincture)))
|
Here we need an individual representing a plain escutcheon to have a tincture, and only that tincture, and to be known to have no charge. With the open world assumption just not saying there is a charge doesn’t mean there isn’t one. Our individual will have to say there isn’t a charge on this escutcheon.
3.
Class: 'Metal escutcheon and coloured charge'
Annotations: [in heraldry]
label "Metal escutcheon and coloured charge"^^string
EquivalentTo: [in heraldry]
* 'Metal escutcheon and coloured charge',
Escutcheon
and (hasPart some
(Field
and ('is charged with' some
(Charge
and ('has tincture' some Colour)
and ('has tincture' only Colour)))
and ('has tincture' some Metal)
and ('is charged with' only
(Charge
and ('has tincture' some Colour)
and ('has tincture' only Colour)))
and ('has tincture' only Metal)))
|
Here we say that the field must have a metal tincture and can only have a metal tincture, and vice versa for the charge. Note the care with which everything is closed off.
4.
Class: 'Coloured Escutcheon and metal charge'
Annotations: [in heraldry]
label "Coloured Escutcheon and metal charge"^^string
EquivalentTo: [in heraldry]
* 'Coloured Escutcheon and metal charge',
Escutcheon
and (hasPart some
(Field
and ('is charged with' some
(Charge
and ('has tincture' some Metal)
and ('has tincture' only Metal)))
and ('has tincture' some Colour)
and ('is charged with' only
(Charge
and ('has tincture' some Metal)
and ('has tincture' only Metal)))
and ('has tincture' only Colour)))
|
we can add various individuals with fields and charges and the HO captures them well enough (it is a limited part of blazon that I’ve implemented). If we add an individual for “Argent with latin cross Or” like this:
Individual: 'Argent with latin cross Argent'
Annotations: [in heraldry]
comment "Should break rule of tincture"^^string,
label "Argent with latin cross Argent"^^string
Types: [in heraldry]
(hasPart some
(Field
and (('is charged with' some
('Latin cross'
and ('has tincture' some Argent)
and ('has tincture' only Argent)))
and ('is charged with' only
('Latin cross'
and ('has tincture' some Argent)
and ('has tincture' only Argent))))
and ('has tincture' some Argent)
and ('has tincture' only Argent)))
and (hasPart only
(Field
and (('is charged with' some
('Latin cross'
and ('has tincture' some Argent)
and ('has tincture' only Argent)))
and ('is charged with' only
('Latin cross'
and ('has tincture' some Argent)
and ('has tincture' only Argent))))
and ('has tincture' some Argent)
and ( 'has tincture' only Argent))),
Escutcheon
|
Note that everything on this individual is a type assertion to anonymous individuals for charges and their tinctures. Note that this lets me be very closed about what I say; I’ve used universal quantification to help me close this down. I’ve used some functional properties for other qualities of things. Being this closed is really hard, largely from a syntactic point of view. It is just hard plugging all the gaps. Uli Sattler had to help me out after I’d stared at a mass of parentheses for too long and not seen the problem of an “openness gap” that I knew was there.
With this individual, the HO becomes inconsistent. That is, this instance cannot exist in this ontology. this is because it breaks the rule of tincture by having a white cross on a white background; though the reasoner doesn’t say this. I have to use Matt Horridge’s wonderful explanation gadgets. The explanation for this inconsistency is (as a not very beautiful table):
|
1
|
Escutcheon EquivalentTo Plain escutcheon or Coloured Escutcheon and metal charge or Metal escutcheon and coloured charge
|
2
|
|
2
|
Plain escutcheon EquivalentTo Escutcheon and (hasPart some (Field and (not (is charged with some Charge)) and (has tincture some Tincture)))
|
2
|
|
3
|
Argent with latin cross argent Type (hasPart some (Field and ((is charged with some (Latin cross and (has tincture some Argent) and (has tincture only Argent))) and (is charged with only (Latin cross and (has tincture some Argent) and (has tincture only Argent)))) and (has tincture some Argent) and (has tincture only Argent))) and (hasPart only (Field and ((is charged with some (Latin cross and (has tincture some Argent) and (has tincture only Argent))) and (is charged with only (Latin cross and (has tincture some Argent) and (has tincture only Argent)))) and (has tincture some Argent) and (has tincture only Argent)))
|
2
|
|
4
|
Argent with latin cross argent Type Escutcheon
|
2
|
|
5
|
Argent SubClassOf Metal
|
2
|
|
6
|
Coloured Escutcheon and metal charge EquivalentTo Escutcheon and (hasPart some (Field and (is charged with some (Charge and (has tincture some Metal) and (has tincture only Metal))) and (has tincture some Colour) and (is charged with only (Charge and (has tincture some Metal) and (has tincture only Metal))) and (has tincture only Colour)))
|
2
|
|
7
|
Metal escutcheon and coloured charge EquivalentTo Escutcheon and (hasPart some (Field and (is charged with some (Charge and (has tincture some Colour) and (has tincture only Colour))) and (has tincture some Metal) and (is charged with only (Charge and (has tincture some Colour) and (has tincture only Colour))) and (has tincture only Metal)))
|
2
|
|
8
|
Light tincture EquivalentTo Metal
|
2
|
|
9
|
is charged with Range Charge
|
1
|
|
10
|
Light tincture DisjointWith Dark tincture
|
2
|
|
11
|
Dark tincture EquivalentTo Colour
|
2
|
The table has the axiom number, the axiom itself, and the final column indicates in how many explanations the axiom is involved. Basically, what this says is that this individual has broken the rule of tincture. The axioms say that there is a field that has a metal tincture and only has a metal tincture. There is a charge that has a metal tincture and only a metal tincture. Escutcheon is covered by 3 escutcheon types, and due to the tinctures of this individual’s charge and field, there is an inconsistency; the two types of tinctyure are disjoint, so Argent must come from one and not the other (as Argent is a kind of “Metal”).
Getting all of this to work is conceptually easy enough, but actually hard to implement. it is all about closing down the open worldness in both the TBox and ABox.
Note that the escutcheon Or with lion regardant passant coward vert has classified just under escutcheon and not under one of the three escutcheon types that cover “Escutcheon”. This is because the individual for this escutcheon is under-constrained. I’ve left it open as to whether either the field or charge can have another tincture to that already specified. As we know it is an escutcheon, but not which of the three types that cover Escutcheon, this individual is, it doesn’t break the constraint of the covering axiom. Only after we’ve ruled out that it can’t be any one of the three covering types wil the covering axiom come into effect and the ontology becomes inconsistent.
The things left to do on the HO (if I choose to) include:
Returning to my flower anatomy ontology. the variation, even within one kind of plant, is large. The variations cause problems for making descriptions of plants. this becomes a particular problem when making the kind of precise descriptions I’ve tried to do in the flower anatomy. For example, when trying to describe a particular plant I’ve found with an aim to classify the thing against my ontology, I find different kinds of leaves (some ovate, some obovate, etc); I thind different numbers of branches and leaf segments etc. of course, one usually takes some normative view of a plant (a cnceptualisation of some cannonical plant), but it would be good to be able to capture the range and variety within a kind of plant in the TBox description.
We can exemplify this with a fairly randomly picked entry from Stace’s New Flora of the British Isles. The entry is:
“CFOSMOS Cav. Mexican Aster
Annuals; leaves all opposite, 2-3-pinnate with linear to filiform segments; phyllaries in 2 dissimilar rows, the outer narrower, herbaceous with membranous border, the inner membranous; capitula radiate; receptacle flat, with scales; pappus of (0)2(-3) bristles with usually backward-directed barbs; ligules numerous, pinkish-purple, rarely white; disc flowers yellow.”
A New flora of the British Isles 1997 page: 755. New York
— Clive Stace
We can dissect such a description, bearing in mind the universality of OWL’s class level restrictions; that is, each and every instance of class x holds some relationship to at least one instance of some other class.
Lots to explore in all this; for now, I’l ljust choose “2-3-pinnate with linear to filiform segments”.
One could model the “pinnateness” of a leaf and model a range of pinnateness with max and min cardinalities. this, however, doesn’t capture the physical nature of the sub-divided leaves — especially if I wished to say something about the subm-divisions. For instance, in the mountain ash, I want to say that the final division is arranged “herring-bone” fashion.
At the moment, the clumsy pattern I’ve outlined is the best I’ve come up with. At some point I’ll actually try and do it, then put the ontology up for inspection. meanwhile I wil think more and write more on the other aspects of describing the variation in plant descriptions.
Protege is a complex tool. By deafult it offers a user all that it is possible to do with OWL (relationships, quantifiers, class expressions, and so on) and there can be choices at any point. Often Protege is too complex, especially at an early stage of authoring an ontology where one might simply wish to “sketch” something out; perhaps for migrating to a more sophisticated form later. Andrew gibson, when he worked in our group, wanted a simple tool for “sketching” an ontology. Such a tool would be based on a simple “blob and line” model, corresponding to classes, subclass axioms and existential restrictions. Matt Horridge developed a tool called Montage from Andrew’s specification; it was only ever a prototype and never saw the light of day outside that particular office.
Inspired by this, I offered a third year undergraduate project to develop a “simple knowledge organisation tool” — SKOT. A student called Mark Jordan took this project on and has done a good job, given the restrictions of time involved in a University of Manchester Computer Science third year undergraduate project.
Mark developed a tool called SKOT – the Simple Knowledge Organisation Tool. It is an open source project under an LGPL licence and the SKOT code is available on source forge.
The picture shows SKOT at a point just before the user is about to export the sketch into an OWL file. There is a “term list”, where words or terms that might form the blobs or classes in the ontology are “stored”. The example is the traditional “university” modelling example, with the terms “University”, “Person”, “Student”, “Undergraduate”, “Mark”, “Postgraduate”, “Teaching Assistant”, “Lecturer”, “Lecture” and “TA Lecture”. These terms can be selected and dragged on to the canvass, where they become blogs that represent classes or individuals (for the term “Mark” in the list above). %Relationships are created by selecting a blob, choosing to create a relationship, moving to the “target” and then finishing the interaction. Relationship sub- super-class or of other types as specified by the users. To do this, SKOT takes the following approach:
There’s a lot of user interface work involved in SKOT. groups of blobs can be selected and each member of the group forms a subclass relationship to a selected superclass. The layout is in the hands of the user.
James Eales used SKOT to make a toy ontology of fish, starting by just typing in a load of words about fish. This is fine, but hooking SKOT up to an automatic term recognition tool, as well as hand-typing, would be good. Once in the word list, they are ready to drag into the window where the “ontology” can be sketched.
Next, James moved terms from the list on to SKOT’s sketch canvass and made a basic hierarchy of terms. Note that classes and instances are differentiated. Other types of relationship than the subclass are possible, but not used here.
This was then saved into an OWL file, imported into Protege and shown using OWLViz.
Note that the export from SKOT to OWL appears to have gone wrong – Cod is now a warm water fish, where in SKOT it was a cold water fish; I’m sure this is easily remedied.
Mark did a basic evaluation, getting some people to install and use SKOT to draft some ontologies. Two of these made ontologies — one an onmtology of guitars and one an ontology of fish. All the users were basically impressed, but also gave long lists of things to do — one user, for example, just found it difficult to work out what to do on start up; however, once he got going, all was basically OK.
SKOT is currently a stand-alone application and it really should be a Protege plugin. there’s also a lot more to do on SKOT, both little things and big things. On the list of little things are to fix various labels on the UI to make better sense. On the larger side of things, we need:
Mark’s report on SKOT and how it was built is available.
As part of the e-LICO project, Simon Jupp and I, together with Julie Klein and Joost Schanstra, colleagues from INSERM in Toulouse, have made a kidney and urinary pathway knowledgebase (KUPKB). We have used a mixture of OWL and RDF based technologies to create a resource for KUP biologists to query across many levels from gross KUP anatomy through cells to cell components, gene products and genes. It also includes diseases and experiments (metabolomic, transcriptomic, proteomic) on various aspects of the KUP field. Most importantly, we haven’t left our KUP biologists to use SPRQL in order to exploit the KUPKB, instead simon Jupp has made the iKUP browser, a GWT Web application for browsing and querying the kUPKB. We’ve written up our KUPKB work in the Journal of biomedical Semantics.
Our JBMS paper describes our process in much more detail, but the outline is:
We used OBO ontologies, especially the GO and a mouse anatomy, the cell ontology and so on. We took portions of Uniprot and Bio2RDF. We also added in lots of experimental data to make the KUPKB.
We used lots of off-the-shelf ontologies to make the KUPKB and this is good. In places, however, we made our own and avoided some on-going efforts there are on-going efforst to standardise experiments, such as microaray, in rdf, but we couldn’t wait. We just wanted very simple questions to be answered. Much time in standards is devoted to edge cases and the time scales involved don’t match the project in question. Also, we are content to gloss over some of the niceties of the experiment as our users want just enough information to go and read the paper properly. We don’t actually need everything about the experiment in the computational knowledge at the moment, but this isn’t to say we won’t in the future. Of course, we’d happy to have it eventually, as it will almost certainly be useful at some point. This is, in essence, the case for application ontologies; they do what is necessary for an application setting, rather than being a reference for all to use and “refer” to for a normative view. This is not to say, however, that a reference ontology cannot be used in an application setting – though one might not use all of such an ontology.
The KUPKB is small for an RDF store, only around 20 million triples, and the RDF store has worked OK for us. Having to upload the whole set of triples in order to delete something is a pain. The advent of SPRQL has made querying easier, with the inclusion of aggregation. Ultimately, we’d like to keep the whole lot as OWL and use automated reasoners, but at the moment they are not really up to it in this setting. We use automated reasoners on the KUPO, to put in the inferred subsumptions and to “check” it out; we’ve also reasoned over smaller portions of the KUPKB, like expereiments, to provide some reasonable queries. The iKUP application does use the OWL API to reason over a bit of the KUPO to help us out with some queries, but we can’t do it all.
the KUPKB is really a bespoke RDF KB; it hasn’t gone for size, which seems to be an aim of a lot of work at the moent. Instead, we’ve pulled together a bespoke set of information, as RDF, in order to meet a particular application need. In doing so, we’ve used portions of the large RDF publications, but not used them as the large publications. Also, as well as publishing some RDF, we’ve been determined to have it consumed as well. This means providing some kind of interaction with the KUPKB that isn’t just a SPRQL end point.
One of the really nice things that Simon has done is to create a front end to the KUPKB using GWT. This is the iKUP browser, and forms the access point to the KUP)KB. It provides, at the moment, a gene centric way to browse the KUPKB and retrieve experiments on certain genes. For instance, one can browse anatomy, down to cells, to isolate genes/gene products that are involved in a particular process in a particular disease and then retrieve experiments that involve those genes or gene products. So far, the response from the KUP community to the iKUP browser has been very positive and it will expand to offer various ways of browsing. Some hypotheses found via iKUP are being tested in the laboratory, which for me is very exciting.
Whilst the bits and pieces of the iKUP browsers are generic to almost any presentation and interactionw with an RDF KB, I don’t really believe in generic tools for presenting and interacting with such KB. I believe in generic tool bits, but not in “one size fits all” for this kind of interaction. There may be a place for such generic tool kits, but tailoring to a specific situation will always give the better results. What we need are high-level tool kits for making such front ends. What Simon has done with GWT was reasonably straight forward and didn’t take too much time. Simon has also used GWT for the Logical Gene Ontology Annotations (GOAL) browser, a UI for querying Gene Ontology Annotations with OWL, again with similar straightforwardness.
I have a plan for a series of OWL and ontology tutorials along the following lines:
The trick with these tutorials is to find a modelling example that first covers the features one wishes to address and second uses an example that is accessible to all the potential attendees. This second point is often tricky and one must avoid trivialising a subject area too much, something that happens too easily in a subject like biology where there are few examples that are accessible to all biologists, let alone those outside that domain. Many years ago, when we were first talking about the ontological modelling version of the tutorial, Andrew Gibson, who then worked in our group, suggested the field of travel as a suitable tutorial subject area. It is possible to make a Travel Ontology that covers any modelling situation one would wish to cover in such a tutorial and the topic is something that everyone can appreciate; we all either do or know about undertaking the process of moving from one place to another for a variety of purposes.
With travel as our field of interest, we can cover the major ontological distinctions:
In doing so, all of this and much more will touch on many of OWL 2’s features, from classes to individuals, property hierarchies, property chains, property characteristics, and so on. In such an ontology we can show off the language, modelling and the use of automated reasoning.
By bringing in the kinds of ontological distinction outlined above and the goals of the tutorial, we immediately suggest upper level ontologies. My experience with such things has been to find the decision making about what goes where under an upper level all rather hard. I have little confidence that with the current material we have at hand for this kind of modelling that, given an arbitrary set of classes, independant groups or individuals will come up with the same placement of classes in an ontology. I would like to try and fix this – for at least one upper level ontology so that one doesn’t have to spend years teaching oneself bits of philosophy in order to use an upper level ontology. Of course, effort is inevitably involved, but it should be at the level of engineering (ideally at the level of choosing patterns), rather than consulting a guru.
Over the past several years, I have made a Travel Ontology and put it under an upper level ontology. I have used, up until now, a cut down version of Alan Rector’s Simple Upper Bio, but with the biomedical bits chopped out. So far, I’ve put the following things into the Travel Ontology:
I want to be able to describe things like a walking holiday in Italy, in the first two weeks of June, during which I visited several historical monuments and sent a postcard to my Mum of the forum in Rome. I want to describe a holiday on a narrow boat on a series of canals in England during the summer, passing through Birmingham and ending up on the regent’s canal in London. I haven’t done time points and durations yet (time is always such a pain), but it will be a vital part of the Travel Ontology.
I haven’t done much with the Travel Ontology for a while, but I want to start again and finish something off to the level to which I can do a tutorial about this kind of modelling. Alan Rector’s upper level ontology is no longer maintained as it has sort of been overtaken by Stefan SCHULZ’s BioTop. So, I really want a replacement and I’ve gone with the Semantic Science Integration Ontology (SSIO). The main reasons for this choice are: I like the words used (avoidance of words like “continuant” and “occurrant”); it is young and there is discussion on its formation; I know the people and know that sensible discussion is possible (there is an open world assumption involved in my making these statements). I also like the attribution policy put in place for SSIO.
In moving over to the SSIO, I want to do an experiment. As I place the major classes underneath the SSIO, I want to discuss the choice of where it goes on the SSIO mailing list. From the discussion and the questions I’ve had to ask myself, I want to create a guide to using the SSIO; eventually I’d like to be able to use this in an ontology tutorial and refine it to the level where one can reasonably reliably get consistent placement of classes and choice of relationships. I want attendees of such a tutorial to do exercises in which protocols are followed to “guide” placement of classes and choices of relationship. This guideance will involve “how to think about an entity” – what questions to ask myself about an entity such that I make reasoanbly sensible decisions – and be able to record those decisions.
The work wil go something like this:
This will be hard work, but can be done piecemeal and may not have to involve only me! The result I want is an ontology placed under an ontology that is used by more than one group; a set of documentation on how it is done; a set of nice modelling examples to use in another ontology tutorial.
The BioHealth Informatics group at the University of Manchester are pleased to invite you to participate in their internationally renowned OWL Ontology tutorials. It is to be hosted at the University of Manchester on 11 and 12 July 2011.
This two-day introductory “hands-on” workshop aims to provide attendees with both the theoretical foundations and practical experience to begin building OWL ontologies using the latest version of the Protégé OWL tools (Protégé4). It is based on Manchester’s well-known “Pizza tutorial“.
This tutorial will cover the main conceptual parts of OWL through the hands-on building of an ontology of pizzas and Their ingredients. A series of practical exercises take attendees through the process of conceptualizing the toppings found on a pizza; the entry of this classification into the Protégé environment; the description of many types of pizza. All this is set in the context of using automated reasoning to check the consistency of the growing ontology and to use the reasoner to make queries about pizzas.
Since 2003 this tutorial, in various forms, has been given over thirty times and been attended by hundreds of budding ontologists.
The aims of this tutorial are to:
Dr. Robert Stevens, is a Reader in BioHealth Informatics in the Bio and Health Informatics Group at the University of Manchester. His main areas of research interests include: (1) the development and use of ontologies to describe biology and to make knowledge about molecular biology computationally useful; (2) communal building of ontologies — enabling domain experts to use the power of formal, expressive languages, such as the Web Ontology Language (OWL); and (3) semantic description of content through ontologies in e-Science research.
Dr. Georgina Moulton is a Senior Teaching Fellow at the Northwest Institute of BioHealth Informatics (NIBHI). She develops and presents Continued Professional Development courses to national and international researchers from a range of disciplines. Georgina has a background in Bioinformatics and Biochemistry.
In total there are 15 places. The cost of the course is £350 per day.
To register and for further information please visit the
Pizza tutorial registration website at: http://www.nweh.org.uk/ViewCourses.aspx
A realist ontology only represents portions of reality; that is, classes of things that really really have instacnes out there in this one world in which we live. I’m told that if I’m not a realist, then I’m prepared to have unicorns in my ontology; that is, just fil the ontology up with nonsense. I’m not a realist and I’ve been criticised for therefore being willing to have unicorns in my ontologies. whilst I try and describe entities in biology, I have to deal with things that seem problematic from the realist perspective (I was involved with Phil Lord in writing a paper about some of these points). colour models, numbers, mathematics, all appear to create more heat than light from a realist perspective. I also remain to be convinced that I need a true account of numbers, units etc. just to be able to describe biological phenomena. the critical thing is a common way of doing it and this is not the same as saying the only way to achieve that common approach is to capture the “reality” of numbers and units and so on.
Here are several unicorns that I’m happy to have in one of my ontologies that apparently make my ontologies poora :
Our amino acid ontology is full of simplifying assumptions that make it non-realist. It is full of arbitary defined classes combining the attributes of charge, polarity, aliphatic/aromatic side chain, size (a simple value partition that wil not be “real”), hydrophobicity, and so on. For instance, how we talk about charge is a simplifying assumption. Aimino acids have different charges in diffeerent conditions, but it is convenient to talk, for instance, of lysine having a positive charge; it helps biochemists explain its role in proteins.
As has been observed by others, a realist approach to modelling a domain is fraut with issues. Even ontologies that claim a realist stance cannot really claim to be properly realist with non-existent anatomies and useful, but untrue, simplifying assumptions about physics. Any non-real entity makes an ontology not a realist ontology, just as one cannot be a bit pregnant.
Such useful untruths may be practical, but the need to compromise on reality so we can have practicality is all too telling for a reality only approach; practicality will make an ontology non-realist. We need practicality in capturing what we need to say to accomplish what we need to do in describing our data. We don’t describe real entities very much, we describe data bout real entities; collections of those entities; approximations and smears of probability about entities. Precise simple rules are all very good, but when a complex world has to be changed in order to fit the simplistic model, things have gone wrong.
Simple messages are, however, easier than complex messages; compromise is always a bit mealy mouthed. The criteria for pragmatism and the rules that govern it are woolly, but we do need to move away from “just ask the guru” or “I feel it in my bones” – something that is all too common in bio-ontology building at the moment. The pragmatics agenda will be developed.
