The MP3Importer is (supposed to) be a minor tool, that fills the users database with Song and Artist items from his MP3 music collection. Since this is not the core topic of the diploma thesis, it is not possible to spend much time on metadata checking.

Working principle

It is assumed that all mp3s are annotated correctly before there are imported.

For each mp3 file do:

1. Check if this file has been imported already
   To speed things up, common indexing techniques like in filesharing applications are used. For each file, its complete and canonical path and name is stored along with its date of last modification. At first, I wanted to store these information along with other information about the mp3 file using the skipmedia ontology, but there are some problems:
   • privacy concerns - the path to the file would be shared among all contacts, which might be a problem to some people
   • storage space - the file path and last modification date are to no use of other people than me, so this would increase the transfered data without use
   • computation problems - the path and last modification date are stored as normal RDF properties for simplicity reasons, but when mixed up with the data of other users, extra checking has to be done to ignore files from other users.

Conclusion: Indexing information is stored in an extra namespace (​http://localhost/skipforward/skipmedia#). That way, it won't be shared by the synching mechanism of SkipForward, but can reside in the same database. The absolute path to the file is normalized to UTF-8 and then used as URI for itself.

2. If the file has to be (re)imported, calculate md5sum and extract all other information like artist, title, bitrate, etc.
3. Lookup the song in the database. If import can be done straight forward (because there is no matching Item or exactly one for song and artist), it is passed directly to the actual import process (Step 5). Otherwise, the a reminder is put into a list of files to review manually (Step 4).
4. If there was doubt on how to import the file, user interaction is required. A GUI is presented where the user has to choose existing items and is able to define the name for each item. These entered information is stored in a special data structure and passed to the import method (Step 5).
5. There are three types of Items to be imported:
   • the song Item itself with title
   • the media Item that is a representation of the song
   • the artist Items for the main artist and possible contributing artists with their name

In step 3, each of this possible items was searched in the database by title with many possible outcomes: No match found, one match found and multiple matches found. The search ignores the namespace of the items, so the import process needs to distinguish between own and foreign items.
I propose to store the information in Maps<String, Item> where for each entry the key of type String is the itemName of the Item to import. Three cases can occur and are handled as follows:

• The Item value is null
  A new Item is created with the key String as itemName.
• The Item value is an Item of the own namespace
  If the Item already has a matching ItemName with an applicability greater than 0, it is used. Otherwise, a new ItemName feature is created with the key String as itemName.
• The Item value is an Item of a foreign namespace A new Item is created with the key String as itemName and defined identical to the foreign one. (The regular copy-method can't be used because it copies the itemName, too.) Note: If a foreign Item is given, it has to be checked if there is an identical own Item to prevent duplicates.