190 Personal Content Experience: Managing Digital Life in the Mobile Age One of the most basic choices in computer programming is choos- ing the balance between memory and speed. Simplifi ed, this stems from the fact that storage memory is cheap, slow, and usually there is plenty of it, while execution memory, RAM, is expensive, fast, and a limited resource. Therefore, the programmer may choose either to consume more RAM to increase the execution speed, or decide that conserving it is more critical and design data structures that are mostly stored in the storage memory and read into RAM only when needed. Of course, reading data frequently from slow storage memory to RAM slows down the execution time signifi cantly. 5.8.1 Memory Consumption Our Metadata Framework reads the whole schema into the applica- tion’s memory space upon connecting to the MdE server. It means that some RAM is consumed whenever a new client connects to the engine. We decided that providing runtime integrity checks and enforcing that metadata is always used as intended is so important that the usage is justifi ed. This is especially since the schemas usually have a small memory footprint. One object defi nition usually takes only hundreds of bytes of memory, and the whole ontology takes a couple of kilo- bytes. With current devices equipped with megabytes of RAM, this is acceptable. Runtime memory consumption of metadata objects is another issue to consider. In the worst case, creating a huge metadata object with thousands of properties can consume all available memory. In most cases, where applications do not intentionally try to trash the memory, the use of memory is not an issue. However, there are a couple of exceptions, such a Digital TV case described below. The amount of metadata for basic content types such as images, songs, and other documents, is a few properties per items, usually no more than a couple of dozen. The amount of required memory may be as high as a few kilobytes, but usually metadata resides in the data- base and is used only in small chunks at a time. Digital TV content produces some challenges. The DVB standard used in Europe and elsewhere usually have program guide information for a week. The total amount of EPG data can grow to hundreds of megabytes. Of course, all of it is not needed at one time, but it still needs to be stored in the database and also harvested on arrival. DVB EPG is not yet widely used in mobile devices, but we need to proactively design how to process, store, and use megabytes of data in the framework. The current system is not yet optimized for such a usage.