Difference between revisions of "About the group project"
|Line 48:||Line 48:|
Revision as of 16:14, 8 February 2019
Here is some more information about the final submission of your programming projects in May 24.
The programming project shall develop a semantic/linked data application. Development and run-time platform is free choice, as is programming language. It will be graded based on deliveries, process, originality, effort, code, interfaces and implication throughout the semester.
- Show that you can program with semantic technologies (at least RDF, preferred RDFS, SPARQL, you can try with JSON-LD which is an emerging alternative).
- Use existing data sets (open semantic resources)
- Use existing vocabularies (and perhaps extend them)
- Simple presentation interface / dashboard
- Make the program run
- Shortcuts can be ok (some manual steps, artificial data)
- Progress throughout semester
- Take at least one or two data sets (can be semantic or not)
- Read and/or lift them
- Use existing vocabularies
- Combine data sets
- Show and impliment some use cases that were impossible or harder or less flexible before
- Focus on maintainability, making it easy run over time
- make your own muncipalities
- map of party financing
- reasoning over toll roads
- social assessment network
- tracking IT infrastructure
- music concert assistant
- quiz generator
- live semantic flight data
- semantic security service
- recommender system based on knowledge graphs
- semantic crawlers and spiders
- presentation / visualisation of graphs
- community knowledge graph enrichment
- semantic query visualization
- content generation/enrichment using different data sets
The project will be carried by groups of 3 people. All group members have to be registered in the same lab group.
Some Data Sources
- open semantic data sets: http://lod-cloud.net
- vocabularies: http://lov.okfn.org/dataset/lov/
- statistics and overviews: http://lod2.stat.gov.rs/lod2statworkbench
You will have a meeting with Marc to discuss your project idea. Then there will be two oral project presentation in front of the class in the lab, where Marc wil participate and give feedback. The last presentation is on April 23-24 (week 17).
You can show your progress by using a PowerPoint and going over your idea, how the project has gone so far, explain what technologies and datasets you are using and perhaps show some working code.
The end result of the project should be submitted electronically as a ZIP archive through Inspera (eksamen.uib.no) before May 24, 14.00 (STRICT DEADLINE). The archive should contain your complete Eclipse project, but do not include large semantic data sets like DBpedia. You do not need to include standard libraries like Jena either. Instead, include a file README.TXT in the root of the project directory to let us know what is needed before your code can be run, and how to run it, if it needs something special.
In addition to your code, the ZIP archive should contain a two-page description of your project (see below). You can also include small example data sets to run the code on, if you want.
The file name of your archive should contain the exam numbers of everyone in the group (format: INFO216ProjectSpringYY_XXX_XXX.zip), for example INFO216ProjectSpring17_108_116.zip .
You should comment the code lightly in-line. This does not mean one comment line for each code line but, e.g., one brief comment for each logical group of code lines. We do not require full Javadoc.
Your ZIP archive should contain a short project description. Put this description in the root folder of your Eclipse project before you ZIP it. The project description file should be anonymous, and contain the exam numbers of all group members, BOTH on the first page and in the file name (e.g., INFO216ProjectDescription_108_116.pdf .) It must be in English (STRICT REQUIREMENT).
The length of the project description is max 2 A4 pages with 11pt font and 2.5 cm margins. This is a HARD limit. You can have appendices, though, and any figures or tables come in addition to the two pages. The quality of your code and idea is more important than the quality of the 2-page description.
You should briefly explain the purpose of your system. Why have you made this? Why is it a good idea to do this using semantic technologies? What can you do now that wasn't possible before?
You should probably list the technologies/tools/standards/vocabularies you have used and explain briefly why you chose each of them. Did you consider alternatives? Why were the ones you chose better?
If you are reading/converting/lifting data from multiple sources and/or using existing tools in addition to your own program, you should probably include a flow chart or architecture sketch (which is different from a class diagram).
You should probably include a class diagram of your system.
You should mention any particular problems you have had and/or things you want to do differently next time. You should describe the contributions each person in your group has made to the project.
If you want to briefly describe how to run the code you have submitted, you can do that separately in a README.TXT file.