VIRE Technical Report!

1. Project description

Build a (micro-)service Web system able to "intelligently" recommend – by exposing a SPARQL endpoint – vinyl music records according to various criteria: user preferences (specified via controlled natural language constructs such as "I always like/love/prefer classical music, especially opera music by Rossini or Verdi and performed by Angela Gheorghiu or Juan Diego Flórez; I sometimes like progressive rock and post-rock; I like only metal albums released before 2000; I always dislike/hate rap and hip-hop; I dislike songs produced by Flood in the last 25 years"), past song purchases on various music stores, playlists – available online via music streaming services: Last.fm and alternative solutions – and/or locally – for instance, by uploading a JSPF/XSPF document. The playlists could be created by the user or shared by her/his virtual "friends" (consider at least one social network). The system will use several music-related knowledge models (e.g., Music Ontology or MusicRecording concept from schema.org) and available public resources: Discogs, MusicBrainz, Musicmoz Music Styles.

2. Architecture of the Web application

High Level Arhitecture from first draft to final version

Database arhitecture

database 
                    

                      Table vire.users {
                        id int [pk, increment]
                        first_name varchar
                        last_name varchar
                        country_code int
                        email varchar
                        password varchar
                        created_at timestamp
                        modified_at timestamp
                      }

                      Table vire.playlists {
                        id int [pk, increment]
                        owner_id int [ref: > vire.users.id]
                        name varchar
                        created_at timestamp
                        modified_at timestamp
                      }

                      Table vire.playlists_users {
                        playlist_id int [ref: > vire.playlists.id]
                        user_id int [ref: > vire.users.id]
                      }

                      Table vire.songs {
                        id int [pk, increment]
                        singer varchar
                        release_date timestamp
                        genre varchar
                      }

                      Table vire.playlists_songs {
                        playlist_id int [ref: > vire.playlists.id]
                        song_id int [ref: > vire.songs.id]
                      }

                      Table vire.discogToken {
                        id int [pk, increment]
                        email varchar
                        password varchar
                      }

                      Table vire.lastFMToken {
                        id int [pk, increment]
                        email varchar
                        password varchar
                      }

Main Backend Modules

Vinyls Module (GraphQL endpoint)

This service will exponse only one endpoint. This endpoint will receive as an input a query and based on that will return a list of possible recommandation obtained by querying DBPedia

The output for this endpoint will be the vinyl data resource.

The arhitecture of the service is the following:

graphQL

Schema: 

                      
                        type Vinyl {
                          artist: String
                          genre: Author
                        }

                        type Query {
                          vinyls: [Vinyl]
                        }

Recommandation Module

Overview

This service will be the one responsable for providing a number of vinyl recommandation, obtained based on different criterias

We will expose 3 endpoints for this service, the input format will differ, but it will be adapted so all of them will in the end get data from dbPedia by calling the Vinyls GraphQL endpoint.

This endpoint will act as an intermediary between the application frontend and the Vinyls Service that will return the actual recommandation. So this endpoint will transform the received input in something that can be easily interpreted by the Vinyls GraphQL endpoint

The arhitecture of the service is the following:

userService

Recommandation based on user input

Using the endpoint for this recommandation type the user will receive recommandation based on an input submited by him

The input needs to be valid in the controlled natural language defined by us

  • Controlled Natural Language

    Definition:

    Controlled natural languages (CNLs) are subsets of natural languages that are obtained by restricting the grammar and vocabulary in order to reduce or eliminate ambiguity and complexity

    Why do we need this?

    We will need this in order to restrict the user input to a small subset of words. He should be able to express his music taste using only a few main words. If he will not respect the phrase structure or the set of accepted words we will not process his request.

    How our controlled natural language will look:

    In order to obtain the express what he likes and what he doesn't the user will need:

    • A predicate to express his feelings towards something

      Examples:

      • like
      • love
      • dislike
      • hate
      • enjoy
    • The frequecy of an action

      Examples:

      • always
      • never
      • sometimes
    • Music Genres
    • Music Artists

Recommandation based on past purchases

Using the endpoint for this recommandation type the user will receive recommandation based on past purchases done on Discogs

In order to be able to receive the output for this endpoint the user will need to associate the account on our application with his account onDiscogs

  • Communication with external service: Discogs

In order to be able to use this recommandation option the user will need to associate the account in our application with his account on Discogs

In UI we will have a dedicated page for this. Once the client choose to connect his Discogs account with our application we will save his connection data in our database and everytime we requests data from this endpoint we will get the authentification token from Discogs and use it in order to obtain his past purchases

The response from the Discogs API will be converted in a format that will be accepted by the Vinyls GraphQL endpoint.

The Discogs API v2.0 is a RESTful interface to Discogs data. You can access JSON-formatted information about Database objects such as Artists, Releases, and Labels. Your application can also manage User Collections and Wantlists, create Marketplace Listings, and more.

Recommandation based on playlist

Using the endpoint for this recommandation type the user will receive recommandation based on playlists. The playlists can be either from Last.fm or from a file imported in pur application

  1. Last.fm: In order to be able to receive the output for this endpoint the user will need to either associate the account on our application with his account onLast.fm
  2. Imported playlist: In order to be able to receive the output for this endpoint the user will need to have an account in our application and to upload one or more playlists in it.
  • Communication with external service: Last.fm

    • In order to be able to use this recommandation option the user will need to associate the account in our application with his account on Last.fm

    In UI we will have a dedicated page for this. Once the client choose to connect his Discogs account with our application we will save his connection data in our database and everytime we requests data from this endpoint we will get the authentification token from Discogs and use it in order to obtain his playlists

    The response from the Last.fm API will be converted in a format that will be accepted by the Vinyls GraphQL endpoint.

    Use the playlist.fetch method call to fetch XSPF playlists. XSPF is a web standard for sharable playlists, and XSPF libraries are available in several languages. playlist.fetch takes a `lastfm' protocol URL as an argument; this identifies the playlist you're requesting. The following protocol url schema will be used: User Playlists lastfm://playlist/playlist_id

  • Communication with playlist service

    We will get the playlists for the current user by using the Playlist API.

    The response from the Playlist API will be converted in a format that will be accepted by the Vinyls GraphQL endpoint.

Open API:

Here

User Module

This module role is to maintain the functionality needed for users like login, register etc.

The arhitecture of the service is the following:

userService

Open API: Here

Playlist Module

This module role is to maintain the functionality needed for playlists like create, edit etc.

The arhitecture of the service is the following:

playlistService

Open API: Here

3. Frontend Design

UI Mockup

4. Final Users

User Description

An end user is a person who uses a product or service. This individual isn't necessarily the one who purchases a product but the one who ultimately uses it. For our application we have two main end users:

  1. A person that shows interest in music and wants to discover more and more music similar to his taste
  2. Developer that wants to integrate a music recommandation component in his application

Use Case Diagram

How the user will interact with the application:

Use case diagram

5. External Data Sources

We'll be using some external APIs in order to make vinyl recommendation to the user.

We should be able to reccomend the user some vinyls based on the past song purchases on various music stores. In order to achieve this we plan on using the Discogs API.

Also, we will suggest some vinyls to the user based on the playlists he owns on different platforms We chose to get this information from the music streaming service Last.fm Playlists.

6. Ontology and Vocabularies

We'll make use of the following ontology and vocabularies in order to model our business case. Some of them are needed for the Music Ontology that we use.

  • PREFIX schema: https://schema.org/
  • PREFIX rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns#
  • PREFIX rdfs: http://www.w3.org/2000/01/rdf-schema#
  • PREFIX xsd: http://www.w3.org/2001/XMLSchema#
  • PREFIX mo: http://purl.org/ontology/mo/
  • PREFIX dc: http://purl.org/dc/elements/1.1/
  • PREFIX tl: http://purl.org/NET/c4dm/timeline.owl#
  • PREFIX event: http://purl.org/NET/c4dm/event.owl#
  • PREFIX foaf: http://xmlns.com/foaf/0.1/

Vinyl Resource graph

  • rdfs: subClassOf defines a subclass of the class MusicRecording from schema.org
  • schema: byArtist represent the artist that performed this album or recording
  • mo:Genre an expressive style of music represented by any text or a reference to a DBPedia genre (such as http://dbpedia.org/resource/Baroque_music), allowing semantic web clients to access easily really detailed structured information about the genre you are refering to.
  • schema: member Represents a member of the MusicGroup.
  • schema: givenName Represetns the first name of a Person, more accurate of the artist
Vinyl Graph

7. Linked Data Principles

Linked Data refers to a set of recommended practices for publishing structured data on the Web. In order to contribute to an environment where information is easily accessible, data should first be made available in a standard format that can be reached and processed by Semantic Web tools. This is achieved by respecting the four principles of Linked Data:

  • Use Uniform Resource Identifiers (URIs) as names for things
  • Use HTTP URIs so that people can look up those names
  • Provide information using Semantic Web technologies such as RDF, OWL, SPARQL etc.
  • Include links to other URIs to make other data discoverable

Vire will make use of a few of these principles in the following manners:

  • URIs will be properly used to name the pages which facilitates the search for named data
  • The data used for our resources has been modeled using the Music Ontology and Schema.org vocabulary.
  • Entries on the songs, vinyls and artists will be linked and will redirect the user to other sources of information so he can discover more about that resource.

8. Bibliography

  1. The SPARQL 1.1 Protocol
  2. RDF (Resource Description Framework) standard model
  3. The schema.org vocabulary
  4. Music Ontology
  5. Discogs
  6. LastFM
  7. XSPF