Changes between Version 2 and Version 3 of MP3Importer

Timestamp:

07/27/08 15:53:35 (16 years ago)

Author:

fmittag

Comment:

--

MP3Importer

@@ -12 +12 @@
   * 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.
- This leads me to the conclusion that an extra database for the importer is the best way to do it. The only piece of information that might be worth sharing between both databases is the md5sum of the mp3, so that a possible "play in audioplayer" command will succeed.
- 2. If the file has to (re)imported, calculate md5sum and extract all other information like artist, title, bitrate, etc.
+ 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.[[BR]]
+ 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'''[[BR]]
+    A new Item is created with the key String as itemName.
+  * The Item value is an Item of the '''own namespace'''[[BR]]
+    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.