CS710 is for MPhil students and PhD students who are writing up their theses this year. I am taking this course for the second time, as a PhD student, having taken it as an MPhil student in 1998. I am taking it again because I need all the help I can get with my PhD, I feel that doing CS710 will motivate me to write my thesis, and I think it is a very experimental, evolutionary course: I expect to learn much more by taking it twice - closer to 2.0 than to 1.0 times as much as from taking it once, I hope! :-)
I am keeping my 1998 summary of CS710 online, because I'm sure that the union of CS710 1998 and CS710 2001 will be considerably greater than either on their own, so I suggest that you read the 1998 summary too.
CS710 is a very interactive course, in which we each have to present the work we've done on our thesis so that we can get feedback on it. Don't think of CS710 as a course to be passed (even though it does carry credits) - the aim of CS710 is to help us with our theses rather than to be a hurdle in itself.
CS710 aims to teach us what we want out of the course, rather than just teaching us what David Br�e thinks we need to learn, so he is very receptive to suggestions.
The course has two major parts:
The first six weeks or so (four, according to the plan below) of CS710 are for discussing various aspects of thesis-writing. They are driven by David Br�e, but are more interactive than most taught courses, given that CS710 is about us trying to take what we want out of it.
The plan for the teaching sessions of this year's CS710 are as follows:
Impressing the examiner/reader: The first things (and in many cases, the only things ;-)) that a reader tends to look at are the abstract, the table of contents, and the first and last chapters (i.e. the introduction and the conclusion), and also - and this surprised me - the references (they may prejudge you according to whether you cite reputable people).
Who are you writing for? You need to consider your intended audience as you write your thesis. It may be someone like you, starting in the field. So be explicit (don't assume they are already an expert in your field).
After the teaching sessions come the thesis presentation sessions. I've now moved this section to a page of its own.
We discussed this in the seminar today, and the following suggestions were made as to what issues should be covered in CS710:
What I want out of CS710 this year is much more focus on the strategic level than in 1998, when there was too much emphasis on the tactical level. It degenerated into a high-school English class at times! ;-) I want CS710 to be about how to structure the thesis in terms of the contributions (and how to identify what the contributions are so that you can do this effectively), how to write it up coherently in a contribution-oriented (as opposed to implementation-oriented) style, and so on.
I also want a week on evaluation, which is a very important and very difficult aspect of doing a successful PhD.
Advice on the PhD viva (oral exam where you defend your thesis - there usually isn't one for an MPhil, although the examiners could call you up - most unlikely) should be included somewhere, too - templates of typical nasty viva questions and how to tackle them.
David Br�e gave us the examiners' criteria for an MPhil on an OHP slide. He said that the form was from an MPhil thesis which he had examined, and that the candidate was actually sitting in the room. I wondered who it was, and got quite a shock when I looked up and saw ANDREW P. BROAD on the slide! (David Br�e was the internal examiner for my MPhil - for the record, I passed without needing to resubmit, or even having to make minor corrections, which is unusual! ;-))
The examiners' criteria for an MPhil thesis are:
(This pertains to MPhil Examiners' Criterion 3.)
There are two extreme ways to do a literature review:
The literature is there to help you, but you are there to help the literature!
What is the significance of your research in the general field? How does it link in with everything else?
Examiners are asked to provide a full report on the thesis, including:
By next week's seminar, we are to read two chapters of William Strunk's The Elements of Style, which are available online:
Write down any questions that are not answered in Strunk, so that we can discuss them in the seminar.
This week's seminar covered tactical considerations (at the sentence level and below). I must admit that I didn't find this session terribly useful (English is my first language, most of the advice in this seminar wasn't specific to English anyway, the tactical level is bread-and-butter to me, and it's the strategic level that I really need help with).
"I'd love not to be able to give this session!" (David Br�e)
These two are commonly confused:
If the sentence ends in parentheses, put the full stop after the right parenthesis.
`John likes fast algorithms (provided they are easy to write).'
If an entire sentence is put in parentheses (i.e. the left parenthesis follows a full stop), then the full stop goes before the right parenthesis.
`John likes fast algorithms. (He also likes easy-to-write algorithms.)'
`Have you read Which?'
However, if the title were enclosed in quotation marks, it would require two question marks:
`Have you read "Which?"?
If you don't know something like this, look it up in:
A style-sheet contains all the decisions you have made when there are choices (e.g. whether to put titles in italics). If you use LaTeX, it's easy to incorporate a style-sheet - put the decisions in your header file so that they're up front.
Modern editors use `eg', but `e.g.' is better. Some journals will accept the latter but not the former, and some will accept neither - they insist on `for example' instead.
In LaTeX, it's easy to do replacements:
\newcommand{\eg}{e.g.}
Another abbreviation is `cf', which means `compare' (Latin); more modern editors use `cp'.
`brain wave'
`brainwave'
`brain-wave'
There's no hard-and-fast rule - you have to make a decision and stick to it consistently.
For example, `co-occurrence' looks better than `coocurrence' or `co occurrence', does not it?
`Occurrence' is a commonly-misspelled word, by the way.
`birds, bees and fleas'
`birds, bees, and fleas'
In UK English, the second comma is optional; in US English it is mandatory.
The golden rule is clarity. (Clarity takes precedence over consistency.) Remember that the function of a comma is to group related words together, and each comma goes either `in' or `out':
`birds, bees and wasps, and other flying insects'
If the items in the list are short (one clause), then the list may be treated as a sentence, separated by semicolons and terminated by a full stop.
`The algorithm is as follows:
1. set i = 0;
2. while i < n do ...;
3. print j.'
The alternative, especially if each list item contains more than one sentence, is to treat each list item as a paragraph of sentences, ending in full stops.
`The algorithm is as follows.
1. Set i = 0. Then ... .
2. While i < n do ... .
3. Print j.'
Strictly speaking, it should be `as follows.' in the second case, but `as follows:' looks better IMO.
For guidance on such issues in mathematical and scientific writing, see:
The preferred order is ||<{[(...)]}>|| - from inner to outer: parentheses, square brackets, braces, angled brackets, and fancy double-line brackets that I don't know how to get in HTML ;-)
The one in `pre-cache' is a hyphen.
The one in `pp. 2-5' is an em-dash, which is slightly longer.
The one in `Mr. T-' is an en-dash.
`John's book'
The issue of whether to use 's or just ' at the end of a name ending in s is resolved by how it is pronounced:
`Charles's book'
`James's book'
`Moses' Law'
`In Jesus' Name'
Do you know that NP = P?
Well, neither do I. That's because...'
The first paragraph of a section is never indented. Second and subsequent paragraphs may either:
I prefer the latter, perhaps using the former for nested paragraphs (I wouldn't recommend using nested paragraphs because they are just a construct that I have invented! ;-)).
As a general, it is a heinous practice to ever split an infinitive. ;-) In languages other than English, it is morphologically impossible to split infinitives because each infinitive is a single word.
However, there are occasions on which it is appropriate to break this rule. For example, rewriting the Star Trek catch-phrase `to boldly go where no man has gone before' to avoid the split infinitive would rob it of intensity.
For a discussion of rules that can be broken sometimes, see Chapter 11 of:
This is another example of a rule which should be broken on occasions, especially in spoken rather than written English (which is more conservative): `Which town did you go to?' `To which town did you go?'
We will look at how to compose sentences, how to order words in a sentence, how to build paragraphs out of sentences, and how to build sections out of paragraphs. So we're moving towards the strategic level, although I consider these issues to be at the tactical level, still. In my book, the strategic level is about how you plan the thesis structure in terms of the contributions, the points which add up to those contributions, and the dependencies (pre+postconditions) between those points, which determine the order.
CS710 is thus taking a bottom-up approach to teaching thesis-writing, whereas I am taking a top-down approach to writing my thesis, planning it at the strategic level before writing the actual text of the thesis. Some people prefer to just dive into writing the text, with perhaps only a list of the chapters and sections of the thesis, but the pitfall with this is that it tends to lead to a badly-structured, unfocused thesis with the points in the wrong order (because the dependencies haven't been planned out), which may have to be radically rewritten.
This seminar covered what I would regard as the upper tactical level - a level up from last week, but below the strategic level. This seminar concerns sentences and paragraphs.
The sentence level is especially difficult for non-native speakers of English, when they try to translate thoughts from their mother tongue to English. For example, the German expression "seit f�nf Jahren" translates literally to "since five years", but we say "for five years" (it's the same for Dutch).
Useful books for sentence-level and paragraph-level considerations are:
There are no hard-and-fast rules for constructing sentences - only guidelines/heuristics/rules of thumb. (Actually, there are some hard-and-fast rules - for example, a sentence must have a verb - but these are at the grammatical level rather than the upper tactical level.)
In general, you should do what your supervisor tells you, as it's much harder for a supervisor to support someone who rejects their advice. Bear in mind, however, that times have moved on since your supervisor was a student!
Rules of thumb for constructing sentences:
A further issue is where to place inserted phrases:
One idea per paragraph is the basic guideline. I personally don't like very long paragraphs - if I find I have written a long paragraph, I look for a way to split it. But don't use anaphora ("he", "she", "it", "this", "they", etc.) when referring to something in another paragraph, because a paragraph should be a self-contained chunk that the reader can break off from, and understand the next paragraph based on their understanding of the previous paragraphs rather than the syntactic details of those paragraphs.
There are three types of paragraph that readers are used to, expect to see, and find easier to understand:
To be considered, a dissertation should:
The abstract of Georgios Paliouras's PhD thesis, Refinement of Temporal Constraints in an Event Recognition System using Small Data Sets (1997, supervised by David Br�e), was given as a handout today.
We were asked to read this abstract in class before discussing it with respect to the sentence and paragraph levels. The main thing I noticed as I did so was that the paragraphs seemed to be of type Topic-Refinement (there was nothing I could see that appeared to be Illustration).
We analysed the first paragraph in class:
> The central aim of this thesis is to develop novel approaches to the representation and the
> refinement of event recognition models.
Who are you writing for? In general, you are writing for a scientific audience. Your thesis should be understandable by a computer scientist who is not a specialist in your area.
Note that this thesis is concerned with recognising events, not with classifying events (cf face recognition/classification).
In this context, refinement means learning the parameters of the model, but a general computer scientist wouldn't know this!
He writes "novel approaches", as in two of them! In fact, one subsumes the other, but this is not stated here.
There's no mention of evaluation, or of small data sets (which is a key feature of this work - it's in the thesis title).
> The event recognition system is viewed as a temporal expert system, which searches for
> interesting patterns in a stream of temporally indexed data.
This sentence uses the passive voice.
Given>New: "event recognition system" is given in the title.
"viewed as a temporal expert system": it isn't a temporal expert system, so why not just drop this phrase?
The word "interesting" is redundant.
This sentence should be the first sentence, and so the existing first sentence - the claim - should become the second sentence.
i.e. The event recognition system searches for patterns in a stream of temporally indexed data. A novel approach to the representation and refinement of event recognition models is presented.
> The format of the input stream is unusual in comparison to standard work on event recognition,
> such as speech and sound recognition. It consists of time-stamped events, rather than a set of
> signal properties measured at fixed time intervals. This format has only recently been studied
> in the area of temporal event recognition.
Given>new: it should say what the standard usually is (analogue), and then what the new format is.
The second side of today's handout was a review by Robert Skidelsky of a book called Open Society: Reforming Global Capitalism by George Soros. We studied the first paragraph as an example which makes a big impact, reads wonderfully, is exciting and catchy, is written by an academic, and makes good use of the given>new rule:
> George Soros is the best-known financial speculator of our time, godfather of hedge funds,
> those fast-moving and largely unregulated raiders in the corporate jungle that make their killings
> from fluctuations in the prices of stocks, commodities, currencies.
Apart from the fact that I don't like the subject matter, I think this sentence is too long. It also needs to have the word "and" before "currencies".
The good points about it are:
> When he writes books readers might reasonably expect tips on how to make money.
> They will be disappointed.
This is the killer sentence. There's a lot to be said for making the key sentence short and strong like that.
> Soros's ambitions are altogether more exalted. Having become a billionaire, he has set himself
> up as the philosopher and statesman of global capitalism, tirelessly telling the world that it now
> needs to remove the ladder by which he himself climbed to fame and fortune. On January 2 he
> was reported predicting a "hard and bouncy" landing for the US economy.
How do we start writing like that? (Well, I wouldn't want to write like that, but P.G. Wodehouse springs to mind as an author whose writing style I admire.) We should read good literature (novels, as well as (of course!) scientific literature), so that the style rubs off. "If you read better, you'll write better" [David Br�e]
How to construct your whole thesis. David Br�e has just uploaded some strategic-level hints by Aaron Sloman, which are very AI-like. We should read them by next week's seminar.
The mailing list for this course has at last been set up: you can send email to [email protected], which should reach everyone in the class. Let's get some added value out of this course by discussing it by email between seminars! :-) :-)
Those who are writing PhD as opposed to MPhil theses, note that the CS710 thesis presentations begin in two weeks (i.e. Week 5 will be the last teaching session). All of the PhD students will be expected to present before the MPhil students (in both senses of the word `before'! ;-)).
We went over the abstract and table of contents of this thesis in today's seminar, thereby covering his thesis at a level of detail commensurate with one hour.
Ian Horrocks's PhD thesis:
I've had dealings with Ian Horrocks before, as he gave guest lectures in CS2422 and CS3411 in 1996, when I was a BSc student and he was a PhD student here - he's now a lecturer in this department!
I also selected his PhD thesis as an example when I was trying to derive my thesis structure: I took three or four PhD theses, read their first and last chapters to analyse what their contributions were, and analysed how their contributions were reflected in the structure of their thesis (as given by the table of contents). I concluded from this exercise that most successful PhD theses tend to have an introduction chapter, one or two background chapters, a chapter for each contribution, and finally a conclusion chapter. None of them adopted an implementation-oriented thesis structure (my first attempt at my PhD thesis plan was organised in terms of the implemented systems; I had to radically rewrite it to make it contribution-oriented).
Optimising Tableaux Decision Procedures for Description Logics
This sets up an expectation that the abstract will explain what tableaux decision procedures and description logics are, for the benefit of non-formal-methods computer scientists.
See the BCTCS page (theoretical computer science) for a great example of a readable abstract.
A Distinguished Dissertation must be readable outside its own area (an ordinary thesis need only be readable within its own area, except presumably for my thesis, as comparative code understanding isn't an established area! ;-)).
Anyway, let's analyse Ian Horrocks's abstract, paragraph by paragraph (bold indicates the bits that David Br�e highlighted in class, and the subheadings are his):
Explanation of area
> {Paragraph 1} Description Logics form a family of formalisms closely related to semantic
> networks but with the distinguishing characteristic that the semantics of the concept description
> language is formally defined, so that the subsumption relationship between two concept
> descriptions can be computed by a suitable algorithm.
This says what DLs are, assuming that the reader knows about semantic networks. It would have been nice if it had also said what subsumption is (it's the DL community's term for the a-kind-of, or superclass/subclass, relationship, e.g. person subsumes lecturer).
Problem
> Description logics have proved useful in a range of applications but their wider acceptance has
> been hindered by their limited expressiveness and the intractability of their subsumption
> algorithms.
This tells you what the problem is that he's going to tackle.
Claim + Method used
> {Paragraph 2} This thesis investigates the practicability of providing sound, complete and
> empirically tractable subsumption reasoning for a Description Logic with an expressive
> concept description language. It suggests that, while subsumption reasoning in such languages is
> known to be intractable in the worst case, a suitably optimised algorithm can provide acceptable
> performance with a realistic knowledge base. This claim is supported by the implementation and
> testing of the FaCT system
This paragraph claims to have solved the problem specified in the first paragraph, and then supports that claim by saying what the method of solution is.
Method + Proof
> {Paragraph 3} FaCT is a Description Logic classifier for an expressive concept description
> language which includes support for both transitive roles and a role hierarchy.
This defines what FaCT is.
> A tableaux calculus style algorithm for subsumption reasoning in this language is presented
> along with a proof of its soundness and completeness. The wide range of novel and adapted
> optimisation techniques employed by FaCT is also described and their effectiveness is evaluated
> by extensive empirical testing using both a large realistic knowledge base (from the GALEN
> project) and randomly generated satisfiability problems.
Now we're into the proof of the claim (evaluation).
> These tests demonstrate that the optimisation techniques improve FaCT's performance by
> at least three orders of magnitude, and that as a result, FaCT provides acceptable performance
> when used with the GALEN knowledge base.
This is the nitty-gritty part of the claim. The paragraph tells you how the claim is substantiated.
Usefulness (the hard sell)
> {Paragraph 4} The work presented in this thesis should be of value to both users of Description
> Logics, to whom the FaCT system has been made available, and to implementors of Description
> Logic systems, who will be able to incorporate some or all of the optimisation techniques in their
> algorithms. The optimisation techniques may also be of interest to a wider audience of Automated
> Deduction and Artificial Intelligence researchers.
This paragraph says for whom this work is useful (very important for a PhD), including the wider audience. The paragraph also contains a hidden claim, namely that the method will be good for other DLs.
An idea of my own that I should mention here is that there are clearly two types of evaluation that you need to do:
This is an excellent abstract. Abstracts don't have to be like this, but it's a very good framework to follow!
Notice how, just as the thesis title set up expectations of the abstract, the abstract sets up expectations for the structure of the thesis. It tells you what chapters you can expect to find in the thesis, namely:
I think this was a very useful strategic-level exercise, but it lacked emphasis on the contributions of the thesis. Ian Horrocks hasn't explicitly stated that the contributions are x, y and z - you've got to dig them out of the abstract and the table of contents (I also read Chapter 1 and the last one in order to identify the contributions). Be very clear about listing your contributions, because that's all the examiner cares about at the end of the day! It makes the examiner's job harder, and makes them more likely to bounce the thesis, if they have to dig deep for the contributions.
First, we looked at just the chapter titles:
The table of contents should make clear the distinction between background material and your original work. In this case, the boundary is between Chapters 3 and 4.
Never call a chapter "Literature Review" - it's very boring! ;-)
It's naughty to use acronyms in the table of contents, but at least he says that ALCHR+ (sorry, no fancy fonts! ;-)) is a description logic! (Chapter 4 title).
You don't get a thesis through by making it longer. You get a thesis through by making it clear.
Nowadays, you can deposit stuff on the Web rather than putting it in appendices (Ian Horrocks's thesis has one appendix, "FaCT Reference Manual"). For my MPhil thesis, for example, I put my program code and other gubbins that wouldn't have physically fitted in my thesis, but which I wanted to include for completeness, on a website which I referred to in the thesis. I'm not sure if I can do that for my PhD if I'll be leaving, though.
We then looked at each Chapter in detail (only in the table of contents, not the chapters themselves!).
Chapter 1 must describe the area, state the problems to be solved, and give applications (for DLs, the problems are in their application). Bear in mind that Chapter 1 is crucial for extrinsic evaluation, i.e. evaluating your work in the context of a specific application.
The contents for Chapter 1 don't say what ALCHfR+ is - a table of contents should be understandable as a stand-alone document.
It's also not clear to me that the aims and objectives are in there - I assume they're in Section 1.5 (I would have one section for declaring the aims and objectives, and another to outline the following chapters in the thesis).
It's very important to clearly and correctly state your aims, objectives, and contributions to knowledge in Chapter 1, and to link back to them in the final chapter to discuss how well they have been achieved. Your claims must be strong enough to get a PhD (or MPhil) of course, but don't claim more than you have achieved or you will fail.
It's particularly important to plan Chapter 1 properly before you write it up, more so than the other chapters. Chapter 1 is where you lay down the philosophy of your thesis, and it's important to get the philosophy absolutely correct, with no contradictions (this is also crucial in the PhD viva, BTW, or they'll run rings around you).
Chapters 2 and 3 are background (literature review) chapters. Where do your ideas originally come from? What are your intellectual roots? It's important to recognise your roots in others' work and highlight them - it's a major part of deriving your contributions. It's crucial to set your work in relation to others'. A literature review must critique the state of the art, but must show how each reference is relevant to you, rather than just discussing a list of references for their own sake.
Ian Horrocks' thesis combines two ideas to improve performance, hence the two background chapters above. Such cross-fertilisations are great for deriving novel contributions, but you must explain both areas to people in the other area.
Use lots and lots of examples. Examples are terribly important to illustrate your work, and make it much easier to understand algorithms. You want to minimise the strain on your reader. Don't expect the reader to just read the algorithm and understand, expect them to use the algorithm to check the examples.
You can put the examples first and then generalise, or generalise first and then give examples. I think it's pretty much almost always better to put the examples first and then generalise (Ian Pratt is a great example of this), although it can be done the other way round, particularly for abstract concepts.
Put boring, tedious algorithms/proofs in appendices, and only put exciting algorithms/proofs that you are proud of in the main text.
FaCT is his implemented system. Chapters about your implemented system are very dangerous, because you know too much about your system for the good of the reader, and there's a tendency to want to give too much detail about the implementation. You should just give the essence, emphasising contribution over implementation. If you write too much detail, you may have to move it to appendices (I had to consign copious chunks of my MPhil thesis to appendices, because the main text was originally 240 pages long, which is ridiculous for an MPhil - I have a compulsion to `brain-dump' everything I know into a thesis, which is something I'll have to avoid in my PhD thesis).
The purpose of describing your implementation in the thesis is to help the reader, not to defend your program (if you are challenged to do so, you can refer to appendices or on-line code).
Choose appropriate test data - if possible, use data that other people have tested on, so that you can compare your results with theirs. Many domains have standard sets of test data.
Don't include all test cases in your thesis - select the important points.
The conclusion is not just a summary - you need much more than that for a PhD! Section 8.1 is only one page long (if you've written a summary of each chapter in that chapter, you can just refer back). Section 8.2 is the most important section of the thesis: the significance of your results. Future work is a must, too, and it's useful to point out the outstanding issues to help future researchers in the field.
Ian Horrocks' PhD thesis is an excellent example - everything unfolds naturally, and it has an elegant simplicity about it.
In the thesis, try not to refer forwards, only backwards - except in the overview of the thesis at the end of Chapter 1.
David Br�e says you don't need to go beyond the third level of subsections in the table of contents (e.g. 3.4.2), but I think every numbered subsection should be included.
Read your examiners' writing, if only to see what their style is - they are bound to accept it the way they do it.
John Bainbridge will give a presentation on how he won the Best Thesis prize last year. It will be the last teaching session, then the thesis presentations will begin on 14th March.
John Bainbridge of the AMULET Group won the departmental Best Thesis prize for 2000, and his thesis has been nominated for a Distinguished Dissertation. Today in CS710 he gave a talk on how he did it.
His thesis is about asynchronous design, and connecting modules together in particular. I understand that he invented a bus called MARBLE to do this.
He didn't expect to win Best Thesis, let alone be nominated for a Distinguished Dissertation. "You go in wanting a degree, and that's all you go in wanting!"
Know your tools and choose one! You don't want to change to a different one in the middle of writing your thesis, because converting what you have written so far would be very tedious! ;-)
Time:
Keep it short and concise!
Tell a coherent story. Keep the reader interested. Start with what the story is, and why you did it. David Br�e suggests thinking of your thesis as a detective story, with suspense to be resolved later. If you confront the reader with such tension, it's much more interesting to read than pure slog-work! :-)
Make sure your chapters relate to one another, so that the reader can see the big picture throughout the thesis (e.g. John Bainbridge adopted a layered model). Find a nice way of presenting and summarising your story. It's a good idea to include an actual diagram in Chapter 1 to show how the chapters stand in relation to each other.
Keep it structured, make the chapters fit together nicely. John Bainbridge structured his thesis as follows:
Have an introduction at the start of each chapter, situating it within the thesis, and a conclusion at the end of each chapter which links to the next chapter.
Literature review: Don't cover everything, just what you need, building up to why you did it your way.
Evaluation is hard:
Conclusion:
Don't be surprised if your final structure is dissimilar to your initial plan. Therefore, don't be too rigid initially; feel free to change.
It's a good idea to get others to proofread your thesis, but make sure you thoroughly proofread it yourself! You understand your own work better than anyone, so in one way you're in a better position to see the weaknesses, but on the other hand, you're the worst judge of how intelligible your thesis is to someone reading it `cold'. You should show each chapter to your supervisor as you write it. If you work with a peer, you should proofread each other's writing.
If you have time, it's helpful to build:
The CS710 presentations should begin next week, but if everyone refuses to go first, we'll either look at another thesis like we looked at Ian Horrocks's in Week 4, or we'll look at Ian Horrocks's Chapter 1 in detail.
Today, we looked in detail at Chapter 1 of Ian Horrocks's PhD thesis, having read this chapter before the seminar. You really need to have a copy to hand as you read these notes, which you can download here.
"It's by criticising other people's work that you learn to see how other people look at your work." (David Br�e)
In the seminar, we discussed:
BTW, it's a common convention to use capital letters for software systems, e.g. FaCT.
The first chapter of a thesis should contain the following:
It's time to get out your copy of Ian Horrocks's Chapter 1! :-)
The introductory text sets up the reader's expectations of what's going to be in the chapter.
> {Paragraph 1} Description Logics form a family of formalisms...
This paragraph sets up the problem to be solved. It starts by giving some background about DLs, and then says what the problem is.
> {Paragraph 2} This thesis investigates...
This paragraph states the major claim of the thesis. In fact, in my view it continues saying what the problem is from the previous paragraph, and then states the claim: "a suitably optimised algorithm can provide acceptable performance with a realistic knowledge base."
> {Paragraph 3} This claim has been strongly supported by...
This paragraph gives the support for the claim, and lists the contributions of the thesis up front. It mentions evaluation.
This section gives the background to DLs in some detail, defining terms, establishing preconditions for later sections.
Look at the last paragraph of each section for the `take-home' message.
The last paragraph of Section 1.1 (This thesis addresses...) is a statement of the thesis claim, but it doesn't really belong in Section 1.1! It's the penultimate paragraph (The expressiveness of the concept description language...) that contains the take-home message, and really should be the last paragraph itself! It gives the conclusion of the section (problems with existing systems) - the whole section should substantiate that claim.
We reverse-engineered the following plan from the text of Section 1.1:
Reverse-engineering a plan from the text is a very valuable skill to have, as it's much easier to appreciate the strategic level from a plan than from the text itself.
For example, we can see from the plan that Paragraphs 3 and 7 feel really out of place. What's Paragraph 3 doing here? It's just a list of DLs, with no comments. It should either be moved, expanded (e.g. Why all these different DLs? How do they differ?), or just deleted. Paragraph 3 disrupts the flow of Section 1.1; it doesn't fit in with what DLs are. A couple of them are mentioned later in the chapter, but the reader isn't likely to remember them from here!
You should read your own thesis like this, and other people's theses - extracting structure from the text. What does each paragraph say, why is it there, what are the connections between paragraphs? The last sentence should be a culmination.
This is actually the weakest section of the whole thesis. Section 1.2.0 is just a list, with no conclusions of any kind. It doesn't say which systems are toy systems and which are actually fielded. The whole Section 1.2 is very minimal, with no criticism at all. It's not bad enough to fail the thesis, but it could be improved! ;-)
You need to impose your authority on your area - show that you're the expert! This section fails to do that.
Anyway, it's important to establish your application context in Chapter 1 - it's a vital part of extrinsic evaluation.
The final paragraph is about the limitation of GRAIL - not of DL applications in general. There's no take-home message - in fact, the last paragraph of Section 1.1 would be much better at the end of Section 1.2! You have to sum up the state-of-the-art in the application area. There's a danger that you know more about local implementations than you do about the rest of the world!
It's also not obvious whether Ian Horrocks wrote GRAIL himself (he didn't), although the fact that the reference [GBS+94] is three years before he submitted his thesis suggests that he didn't. However, he did show GRAIL's subsumption reasoning to be incomplete [Hor95].
David Br�e just skipped over this section in class, saying it was excellent and preferring to focus on the weaker parts, but I have some comments of my own to make!
> {Paragraph 2} The advantage with these algorithms...
This paragraph discusses the limitations of previous approaches such that you can make a contribution.
> {Paragraph 3} An alternative approach is to transpose...
Discuss the alternative approaches. There will often be tradeoffs (in the case of DLs, there are tradeoffs between expressiveness, soundness, completeness, and tractability). A good PhD contribution can often be made by combining the best features/properties of these approaches. For example, Ian Horrocks's FaCT system combines an expressive DL with proven sound and complete subsumption testing, which is computationally tractable in practice (although there's always the theoretical possibility of combinatorial explosion because sound and complete subsumption testing for such an expressive DL is inherently an NP-complete problem).
You must compare your system to others, with respect to various capabilities/properties. It helps to summarise this as a table - I have derived the following table from Section 1.3 to illustrate the idea:
| Method | expressive? | sound? | complete? | tractable? |
| structural algorithms | yes | yes | no | yes |
| satisfiability | no | yes | yes | no |
| FaCT | yes | yes | yes | yes |
This is another weak and very minimalistic section - it says nothing about how he's going to do the evaluation! It merely says that the ALCHfR+ description logic is used as a test-bed for the subsumption-testing algorithm (intrinsic evaluation, I think).
It does mention the application context (GALEN) again, which is good (IMO).
Every Chapter 1 ends with a section outlining each of the following chapters, but merely listing the chapters, with a potted summary of each, is the most boring way to do it!
Try and tell a story out of it (fleshed out with references to the chapters). Include the plot, and the rationale behind the thesis structure.
You should include the interdependencies, especially if you're going for a Distinguished Dissertation! You could even literally draw a dependency graph of the chapters!
When I read Chapter 1 of Ian Horrocks's thesis, I tried to focus on what his contributions are, and looked for a one-to-one correspondence from the contributions to chapters (to see if he had done a contribution-oriented thesis structure). I identified four contributions:
There will be no CS710 seminar next week (21st March), because David Br�e is away at a conference. Thesis presentations will therefore begin on 28th March. I'm not going to embarrass students by writing up summaries of their thesis presentations! ;-) I will merely transfer any useful general points that come out of these sessions to my advice page or whatever.
Dr. Jacques Fleuriot, who won a Distinguished Dissertation in 2000 for his PhD thesis, A Combination of Geometry Theorem Proving and Nonstandard Analysis with Application to Newton's Principia, gave a departmental seminar on his research today, and David Br�e got him to give a talk to CS710 before that, about how he wrote his thesis.
His research is about arithmetic decision procedures, temporal logic, automated reasoning, mechanical theorem proving, and Newton's Principia. His contributions are mathematical theories, and some implementation of tools. His supervisor was Larry Paulson.
Writing a thesis is a very personal experience, so all Jacques Fleuriot could do was to share his experience with us.
It's important to keep making progress, but don't compare your progress to other students in your year, because everyone's different, and every research project is different.
You should gather as much material about your field as possible, to get as broad a perspective as possible. It's incredible what you can find on the Internet in a short time! Never stop reading until after your PhD viva. As your expertise grows, you can see links to more areas, you make new connections, and more literature can become relevant (even if you thought it was irrelevant earlier in your research).
Fleuriot's thesis is 130 pages long, plus a 5-page bibliography, with 7 chapters, 30 figures, and a short glossary of mathematical terms. It was typeset using LaTeX, and was printed double-sided, with a font size of 10pt - double-sided and 10pt are allowed by Cambridge University, but not Manchester!
You do have to shut yourself away while you're writing a thesis. It's hard to mix practical work with writing up, because implementation is an excuse to put off thesis writing. Don't rush the thesis. Don't take a job while you're writing the thesis, and don't write papers while you're writing your thesis.
Fleuriot's thesis is written in a `detective' style, from problem to solution.
The first chapter is a non-technical introduction, which sets the scene (history of the field, motivating examples). The first chapter should ease the reader into the thesis, not scare them off! Say what the challenges are, the objectives, how the goals will be achieved. Highlight your own contributions and main research components.
You should write a thesis message, as suggested in Aaron Sloman's Notes on Presenting Theses {8.1}, which should be reflected in the title, abstract, the introduction and conclusion chapters, and the overall structure of the thesis.
The introduction and conclusion chapters both summarise the thesis, but they are very different kinds of summaries!
Give a diagrammatic overview of the thesis if possible (which doesn't necessarily reflect the chapters, but I think it definitely should).
+-----+
| |
+-----+
|
+-----+
| |
+-----+
/ \
+-----+ +-----+ +-----+
| | | |-----| |
+-----+ +-----+ +-----+
\ / |
+-----+ |
| |----------------/
+-----+
Fleuriot's chapters:
Each chapter starts with some motivation, and a brief summary (not detailed contents with section numbers), to let the reader know what's ahead.
In the body of the chapter, keep things concise and clear! Explain things (especially equations) intuitively. Use diagrams and examples wherever possible. Have a smooth transition between sections to keep the flow.
Each chapter should have a conclusion at the end, in which you briefly review what's been achieved in that chapter, put the work in context, and highlight your contributions and any other important points. Is there anything you might have done differently?
Each chapter tells its own story.
This should be short (Fleuriot's is five pages), and needs to be written carefully.
You need to pull the contributions of the thesis together, draw general lessons, and outline your main achievements.
You need to criticise your whole thesis, taking a step back from your work. Bear in mind that your criticism here is likely to give the examiners questions for the viva! Make sure you anticipate these questions and know the answers. Know what the weaknesses of your work are, and how they could be improved.
You need to include a short section on further work - no need to describe it in detail, otherwise it would not be further work! (In my MPhil thesis, I actually described future work in detail in an appendix, with a short Future Work section in my conclusion chapter, with references to that appendix).
Fleuriot took a `dynamic approach' to literature review, using the literature as and when, rather than doing a literature review chapter. I agree with this approach - I think it's much better to do a distributed, contribution-oriented literature review, showing its relevance to your work, rather than keeping the literature separate from your work, which tends to make the literature review unfocused and the presentation of your own work too inward-looking. Use references to support the points you make.
Fleuriot did, however, discuss previous work beforehand in one chapter. Since his work was based on several existing methods, this warranted a historical and technical discussion of previous work. It makes it easier to justify your choices.
Quotations can also lend strong support to your arguments (especially if they're from someone famous! ;-)), but do not overuse them - you need to say things in your own words.
Consider whether you have any particular audience in mind for your thesis. A PhD is expected to make a contribution to a specific area, but it also has to be accessible to computer scientists in general, especially for a Distinguished Dissertation!
Prepare yourself before you start writing up - relevant papers, notes you have made, your thesis message.
Different people need to plan at different levels of detail before they are ready to actually write something up. At the minimum, you should plan the overall organisation of the thesis (what the chapters are).
Writing and rewriting should be constant activities.
Fleuriot's supervisor only read his thesis once, when it was almost completed, and he then incorporated his supervisor's comments and suggestions. I find this shocking - I think you need to at least show each chapter to your supervisor once it's written up.
In a typical day of thesis-writing, you should:
I have just added a section to my advice page, giving my detailed thoughts about the process of thesis-writing.