Student Opportunities

Motivation

Dear student,
personally, I am convinced that students should only receive tasks and topics, that make sense and provide real value to 

1. the supervisor;
2. an online open-source or research community;
3. the student him-/herself.

The reason is simple: There will be three stakeholders of your work, which will happily invest counselling time in your work:

1. the supervisor (normally me) will have an interest in providing you with good counselling as your results will be better;
2. the online community will provide feedback (e.g. on mailing lists), if it is interested in your work (if not you should rethink and rather ask, what you should do differently);
3. you will be motivated as you see that (a) what you do is valuable; (b) you are getting proficient in state-of-the-art technologies (and possibly unix shell scripting); (c) if you are successful, you probably have earned some “badges”, that can go on your laundry list of achievements, which can be any of:

• a public Git Hub account showing your code (see this page and search for github );
• participation in a well-known, high impact, international, open-source projects such as DBpedia, NLP2RDF or DL-Learner;
• scientific publications;
• other publications such as blog entries, tutorial, online documentation;
• almost everything we do is open-source and you will have good and verifiable online references and visibility;

Overall, doing your internship, Bachelor / Master thesis with me should give you the opportunity to meet my requirements for new Ph D students (see below).

Types

Opportunities, I offer, generally include :

• internships (Praktikum und Seminar) for the modules Semantic Web, Software aus Komponenten, Softwaretechnikpraktikum
• Bachelor / Master Theses
• Ph D Theses (Note that I can only help you acquire funding, not supervise it as I do not have tenure, see below)
• other

The point other is especially important. If you have any ideas, please contact me. I will also supervise projects of students outside of University of Leipzig as well as projects outside of academia. So if you are interested in implementing something without writing a thesis, please contact me.
Note that, I will not supervise projects, that are not within my interest.
Regarding the topic and handling I distinguish between these three types of projects:

• Engineering: Focus is on proper process, i.e. good requirements engineering, good design, right choice of technology, working software. This type is suited well for bachelor theses.
• Research: At the core of this is a relevant scientific problem and probably an experimental evaluation you will need to conduct. So, yes there might be an implementation involved, but the code and or engineering does not matter. The most important thing is the correctness, the good design of the experiment and the results. The main output here is basically: tables (either statistical or comparing related work (see page 10 ), graphs and diagrams and hard facts. Classically this is a master thesis or a Seminararbeit (homework paper)
• Explorative: The topic is quite new, not clearly defined and presumably there is not a lot of previous work. You will need to look around, analyse what is there and then find the gap yourself. Normally, you will have to work with a lot of bleeding edge software frameworks (which sometimes won't even compile). Ideally, this is a task for an internship (Praktikum), because there is a certain risk of failure (i.e. previous work covers the topic already, problem is not easily solvable with current techniques, etc... ). For the internship, I will let you pass, if you tried hard enough (at least you learnt something, that is what internships are for :) .

Of course you can often not plan anything really. So sometimes you will start an engineering work and end up doing something explorative as you suddenly encounter a hard problem.

For any larger project, I require that you write a very rough Exposé or synopsis, which will:

• show me, that you understood the problem and know what you have to do;
• (for German students) show me, that you are able to write in English (if you choose English as your language)
• list related work (e.g. link list and one to two sentences per approach), showing that you have done some research
• contain a plan on how to proceed (e.g. initial idea of experiment or list of requirements)
• contain a rough time schedule with milestones (this is for your own time management and self-control)

The exposé (Wikipedia, synopsis) should be a Google Doc / Etherpad and does not have any formatting requirements (pertinence over layout).

Process

During the course of your project(s), you will receive feedback from me, in the form of audits. Audits should be minimum of 30 minutes up to a maximum of 90 minutes. You should suggest dates for the audit and also make an agenda, what part of your work (e.g. code, outline, releases, chapter, design, benchmark results) we will review during the meeting.
Some simple rules:

• please provide a new agenda and audit date 48 hours after we had the last audit. Nach dem Spiel ist vor dem Spiel.
• Each audit agenda should have concrete deliverables from you side.
• If you do not succeed to finish all of your deliverables, there are two options: 1. we still conduct the audit and analyse where the problems are (maybe shorten the time a little), 2. we reschedule the audit

Ph D Students

Note that I can only help you acquire funding for your Ph D time, not supervise it as I do not have tenure, yet. Dr. Sören Auer or Prof. Fähnrich will be your supervisors.
We are always looking for new Ph D students (Doktoranden), so please feel free to send applications. If we think you are suitable, we will help you to apply for funding, e.g. DAAD PhD scholarships or overview .

Besides sending the usual CV with your picture per email, please include your bachelor and master thesis, a link to any open-source projects (including any mailing lists you have been active on), a list of publications (either scientific or otherwise, e.g. documentation, blog posts) and your favourite unix one line command (ideally related to RDF).

Publishing Guidelines

Here is a collection of rules and guidelines, how we publish at AKSW:

• Virtually all projects are done using Latex and SVN
• Latex guideline is: one line per sentence to resolve merging conflicts faster
• Everything you submit should be read *once more* before submission to correct spelling mistakes and improve grammar and style
• Images and table should be placed [tb] (top, bottom), this saves space (about 3–6 lines in LNCS )
• References should be shortened to ideally take up only two lines. Use abbreviations heavily.
• All images and screenshots should be cropped to make the content larger. They should be really dense with information, i.e. no uneccessary, wasted white space.
• *Never* add the .aux .log .blg .bbl .pdf files to svn

List of Topics