Semantic Web project

The Semantic Web project is a large and long practical exercise that consists in integrating all the pieces that have been seen during the first sessions into a consolidated Web application. To make sure you can advance sufficiently fast to cover everything, you are allowed to work by pair.

Main objectives

• Design a food delivery discovery service that follows the Linked Data principles: the data of the service should be available online and represented in a standard vocabulary that any application can process. We will describe different kinds of entities that are useful for the service: food products, that can be instances of schema:Product; offers for the food items, that be offers including a single item or combos; restaurants and businesses that offer the food items; delivery services that work with the restaurants and business to deliver their food items; customers with their user’s preferences.
• Develop an application that can provide, given a customer’s description, the place where to order food at the time of request.

Requirements

• The application must take the following preferences into account: location, time, price range and, optionally, type of food
• The application must be generic: it must be able to dynamically discover new businesses and include them in query results.
• The application must serialize and deserialize RDF, use SPARQL for querying and SHACL for validating data collected externally.
• The application must have a command-line interface to control how results are displayed and what URIs to look up.

Pedagogical objectives

• Do a little software development, using Semantic Web programming frameworks
• Setup and interact with an RDF database and LDP
• Exploit multiple sources of heterogeneous data
• Present information online with rich metadata

Timeline

The project starts full time on Friday 24^th November 2023 but some of the practical sessions already provided the building blocks for the project. You will be working on your project full time during the sessions of the 24^th of November afternoon, 8^th of December morning and afternoon and a last session on December 15^th morning.

You must deliver all of your working files before the 10^th of January 2024. All files must be sent strictly before the end of the day, in Central Europe Time. Every extra minute will be penalised. You must additionally provide a written report explaining your choices, the functionalities, etc. before the 15^th of January, 2024 end of the day, Central European Time. Everything that comes after this deadline will be rejected as if nothing was delivered.

Resources

You will make use of data sets, in RDF and non-RDF formats, as well as the Linked Data Platform used in Session 3.

CoopCycle services

CoopCycle is a federation of bike delivery coops, all over the world. Bike delivery coops are associations of cyclist who propose their service to restaurants and other businesses to deliver products to customers at home. From this page, you will have to find a JSON document that describes all the coops of this federation. Hint: use advanced capabilities of your browser.

CoopCycle business descriptions

From the JSON file found from the web page above, it is possible to find the URIs of each coop, usually associated with a city or agglomeration. From there, CoopCycle exposes information in JSON-LD about local businesses whose products are delivered by the coop. To collect that information, you will have to write an HTML parser that is able to navigate and/or to extract JSON-LD.

User preferences

User preferences with respect to location, time, price range and, optionally, type of food should be stored in the Linked Data Platform. An example of preferences is provided in the pref-charpenay resource.

Technical guidelines

Here are steps you can carry out to develop your application. You will not be evaluated on each of these steps but on the end result; you are free to plan development in a different way.

• Set up a triplestore (e.g. Fuseki) to later store data discovered on CoopCycle.
• Write a first program (collect) that collects information about local businesses from CoopCycle and stores that information in the triplestore. If your run your program several times, make sure that data is not duplicated in the triplestore.
• Write another program (query) that looks for restaurants that are open at a given date and time (based on the collected information). Use SPARQL as much as possible. Your program should only have a command-line interface, no graphical interface.
• Improve the previous program to also query restaurants in a particular zone or at a maximum distance from some location.
• Improve your program to also query restaurants accepting delivery below a certain price.
• Modify your program so that restaurants are either ranked by distance or by minimum delivery price depending on some optional input argument, e.g. --rank-by (distance|price).
• Modify your program so that time, location and/or price range arguments are fetched from an arbitrary URI, assumed to expose user preferences in RDF. Test with pref-charpenay. Results should also include restaurants that only partially match preferences (i.e. restaurants that match the time, location and/or price preferences but not all). Rank closest matches first.
• Try your program with different preferences sets. Expose each set of preferences on the Linked Data Platform.
• Rewrite your collect program so that it can collect information about any CoopCycle member (whose URI will be provided as argument). To ensure that collected data will be recognized by the query program, write SHACL shapes to validate any RDF graph before loading it to the triplestore.
• Write another program (describe) that helps users set their preferences with a series of questions/answers, such as where do you live? Provide an answer of the form [longitude,latitude]. Once the program has collected preferences, it should construct the corresponding RDF graph and publish it on the Linked Data Platform.
• (optional) Improve the query program by taking the type of food into account. Restaurants do not expose information (in RDF) about the type of food they serve. Improve the collect program as well so that it tries to extract a restaurant's menu from its textual description.