Chapter 5: Realizing a Metadata Framework 183 metadata or ontologies, MdE converts data into standard relational model that fi ts into any standard SQL-compliant database. This is the fi rst phase in converting from our own model into that of SQLite. At the second phase, our SQLite interfacing component takes the stan- dard SQL and converts it to SQLite specifi c library calls. The reasoning here is that we can also change the persistent storage and the query language in two different places. On the lowest level we can easily change the SQLite into some other SQL database engine. It would require only changes in one component that performs all SQLite spe- cifi c operations. More thorough changes will be required if the whole relational model needs to be replaced and, consequently, a query language other than SQL is taken into use. This would require modifying the MdE component that converts our internal model into the relational model. Switching from one relational database engine to another would require some re-writing beyond simple modifi cations. However, even in this case the API would remain intact. Figure 5-8 shows the main tables in our relation database and our approach to modelling both metadata objects and ontology using rela- tions. The fi gure is oversimplifi ed and not used exactly as such in our implementation. Nevertheless, it illustrates the rationale in designing how to convert our internal data model into a relational data model. 5.7.4 Harvester Manager When new content, whether music, videos, games, or whatever, arrives in a mobile computer, metadata harvesters attack the content to see if they can extract any metadata out of the new content and then transform it to fi t into Metadata Engine. Once the new metadata is in the engine, it is available for all applications in the same manner, regardless of its origin or format. Almost all content objects have embedded metadata inside their binaries. MP3 fi les usually have ID3 tags embedded by the ripping application, images may have EXIF or IPTC tags created by the camera or image processing application, and there are countless other meta- data formats in use. Some harvesters are more advanced than those able to read one format only, and convert it into our internal format. They may look into the content binary itself and understand what features there are in the binary content. For example, some harvesters look into images and try to detect if there are people in them, or even to recognize who a person in the picture is. The content also has many avenues into the mobile device. It may arrive, for example, in an inserted memory card, via USB, Bluetooth,