Web Application Development

Requirements

The most important requirements are:

• The project consists of a (micro-)service-based Web application (i.e., a software system) developed by using existing social and semantic Web technologies.

• A project proposal could be chosen by maximum 4 teams. Each team must have 2 members.

  Consult the list of project submissions per teams.

• There are no restrictions regarding the project implementation: hardware and/or software platform(s), programming language(s)/paradigm(s), framework(s), libraries, public APIs, etc.

• Open source approaches are highly encouraged.

• For the final assessment, the team must provide the full functionality of the developed solution, according to the specific requirements stated in the project description and discussed in the first 7 weeks of the semester during practical works (WADe labs).

• The project should be developed and deployed according to the actual practices in Web engineering (e.g., documentation, test driven development, modularity, bug reporting, etc.) by using a modern approach regarding source-code management like Bitbucket, GitHub, or similar cloud-based solutions.

• All data managed by the developed Web application must be described in RDF – based on existing knowledge models (vocabularies, taxonomies, thesauri, ontologies,...). Various interrogations should be performed by using the SPARQL query language.

• Resource representations to be processed by the (Web/mobile) client will include a valid HTML5 code, plus schema.org and RDFa constructs.

• Each thing (resource) of interest will be exposed (and shared) by using a generated URL and/or QR code.

• The code-source and specific content (data) must be available under the terms of the open source licenses and Creative Commons – consult Software Licenses in Plain English and Social Coding and Open Software.

Additional factors taken into consideration for the project evaluation:

• A proper use of various "exotic" programming paradigms like functional, distributed, parallel, reactive, etc.

• Adopting a cloud-based solution – i.e. for the (RDF) data storage and/or the Web application deployment.

• Using specific design patterns regarding the Web application architecture and/or the knowledge modeling – for example, applying various ontology design patterns.

• Creativity and social impact of the proposed solution.

• Team work – a penalty of 2 points for each assessed component will be applied for a 1-person project effort. Each member of the team will specify the most important contributions to the developed solution.

• Implementation maturity – study Software Quality Checklist and Web Developer Checklist.

• Overall impression – e.g., the suitable use of discussed Web technologies, impact on the end users + usability, business aspects, performance, further directions of development – consider things users care about.

We also encourage positive critics and questions from students.

Deliverables & Calendar

Each student team must deliver the following resources, according to each project proposal. All deliverables are mandatory.

Midterm Deliverables—Design & Architecture: A (10%) – Week #9

• A general (service-oriented) architecture of the Web application to be developed + the overall design from the point of view of a software engineer (for example: main modules, software architecture diagrams, input/output data formats, data/task flows, etc.) and concerning the end users.

• An OpenAPI specification regarding the REST API – or, alternatively, a schema for the GraphQL API – provided by the project, including various usage examples and pragmatic case studies.

• A Scholarly HTML technical report (its digital content will be equivalent to a minimum of four A4 printed pages) consisting of preliminary considerations about the internal data structures/models to be used and the external data sources – e.g., public Web services and/or APIs – managed by the Web application to be developed. Also, explain how the solution conforms to the linked data principles.

• A public wiki associated to the WADe project repository should record the solution's progress. The content must be available in English language and minimally tagged with project, infoiasi, wade, and web.

Final Deliverables—Solution: S (80%) – Week #17

• A fully implemented and deployed – e.g. in the cloud – solution of the software project.

• An updated Scholarly HTML technical report (equivalent to minimum 10 printed A4 pages) describing the most significant details about:

  • project progress with respect to the initial goals, requirements, and projected outcome;

  • technical aspects concerning the implemented API(s) according to the proposed Web system architecture;

  • considerations regarding the designed/reused RDF-based knowledge model(s) – for example, the expressiveness and real usage of the proposed and/or reused vocabulary, taxonomy or ontology in the context of the developed system;

  • pragmatic use of external data/knowledge sources – e.g., using various knowledge bases like Wikidata and DBpedia, plus several non-trivial SPARQL queries of interest;

  • A user guide of the developed solution – also available as a Scholarly HTML document including screen-captures and explaining at least 3 case-studies –, plus a (U)HD-quality video demonstration (duration: 5—7 minutes).

  • These resources will be available on the same public blog, wiki and/or personal Web site presented at the midterm assessment.

💎 Bonuses

Each team could be awarded with an amount of maximum 3 points for:

• adopting SHACL to validate RDF data,

• using various deep/machine learning and/or blockchain-based techniques,

• discussing and adopting methods and/or paradigms regarding the user interaction/experience,

• specifying a set of proper statecharts – details of interest,

• considering significant aspects with respect to the interoperability, performance, and/or security of the implemented solution.

The presentation of the project has allocated maximum 20 minutes per team, including questions.

Project Reassessment

• Mandatory deliverables remain the same.

• Each failed component will be reevaluated with a 2 point penalty.