Тема №5 Методи відео стиснення.
Найбільш популярним виглядом такого стиснення є Motion JPEG (MJPEG). При стисненні цим методом кожний кадр компресується відомим алгоритмом JPEG, що дозволяє досягнути мір стиснення 7:1 без помітних спотворень картинки. Такі рекомендації викликані тим, що сильне стиснення і "рекурсивні" алгоритми вносять у відеофрагмент дуже велику кількість "прихованих" артефактів, які відразу стануть помітними при проведенні фільтрації або рекомпресії, що проводиться після нелінійного відеомонтаж.
Color format (метод кодування кольору) - це стандарт уявлення колірної інформації про один піксель зображення в цифровому вигляді. Найбільш відомими стандартами є: палітровий метод (вказується індекс кольору в масиві стандартної палітри), RGB уявлення (вказується інтенсивність аддитивий компонент кольору), CMYK (вказується інтенсивність субтрактивних компонент кольору), HUE (вказуються більш зрозумілі людині тон, насиченість і чистота кольору).
Досить часто також використовують метод, при якому інформація про піксель ділиться на дві честі - яскравість (luminance, Y) і кольорвість (chrominance, U/V). По-перше, такий метод кодування кольору дозволяє отримати чорно-білу картинку простим відкиданням кольоровості. По-друге, відомо, що людське око сприймає зміни кольору гірше, чим зміни яскравості. Тому кольорвість можна зберігати з гіршим дозволом, ніж яскравість, зберігаючи видиму якість картинки незмінним. Такий прийом використовується в аналоговому телебачені і композитному відеосигналі, а також в більшості методів стиснення (наприклад, MJPEG, MPEG, Intel Indeo). У зарубіжній літературі цей прийом отримав назву Chroma Subsampling.
Потрібно мати на увазі, що кольорвість досить часто називають кольоровоюразністю. У принципі, це трохи неправильно, оскільки кольоровоюразністями називають компоненти кольорвості (усього їх дві - U і V). Таку назву вони отримали через те, що якщо вони рівні нулю, то піксель буде безбарвним – сірим.
MPEG - це абревіатура від Moving Picture Experts Group. Ця експертна група працює під спільним керівництвом двох організацій - ISO (Організація по міжнародних стандартах) і IEC (Міжнародна електротехнічна комісія). Офіційна назва групи - ISO/IEC JTC1 SC29 WG11. Її задача - розробка єдиних норм кодування аудіо- і відеосигналів. Стандарти MPEG використовуються в технологіях CD-i і CD-Video, є частиною стандарту DVD, активно застосовуються в цифровому радіомовленні, в кабельному і супутниковому ТВ, Інтернет-радіо, мультимедійних комп'ютерних продуктах, в комунікаціях по каналах ISDN і багатьох інших електронних інформаційних системах. Часто абревіатуру MPEG використовують для посилання на стандарти, розроблені цією групою. На сьогоднішній день відомі наступні:
MPEG-1 призначений для запису синхронізованих відеозображення (звичайно в форматі SIF, 288 х 358) і звукового супроводу на CD-ROM з урахуванням максимальної швидкості прочитання біля 1,5 Мбіт/с. Якісні параметри відеоданних, оброблених MPEG-1, багато в чому аналогічні звичайному VHS-відео, тому цей формат застосовується насамперед там, де незручно або непрактично використати стандартні аналогові відеоносії.
MPEG-2 призначений для обробки відеозображення сумірного за якістю з телевізійним при пропускній спроможності системи передачі даних в межах від 3 до 15 Мбіт/с, професіонали використовують і великі потоки. В апаратурі використовуються потоки до 50 Мбіт/с. На технології, засновані на MPEG-2, переходять багато які телеканали, сигнал стислий відповідно до цього стандарту транслюється через телевізійні супутники, використовується для архівації великих об'ємів відеоматеріалу.
MPEG-3 - призначався для використання в системах телебачення високої чіткості (high-defenition television, HDTV) з швидкістю потоку даних 20-40 Мбіт/с, але пізніше став частиною стандарту MPEG-2 і окремо тепер не згадується. До речі, формат MP3, який іноді плутають з MPEG-3, призначений тільки для стиснення аудіоінформації і повна назва MP3 звучить як MPEG Audio Layer III
MPEG-4 - задає принципи роботи з цифровим представленням медіа-даних для трьох областей: інтерактивного мультимедіа (включаючи продукти, поширювані на оптичних дисках і через Мережу), графічних додатків і цифрового телебачення.
Як відбувається стиснення? Базовим об'єктом кодування в стандарті MPEG є кадр телевізійного зображення. Оскільки в більшості фрагментів фон зображення залишається досить стабільним, а дія відбувається тільки на передньому плані, стиснення починається з створення початкового кадру. Початкові (Intra) кадри кодуються тільки із застосуванням внутрішньокадрового стиснення по алгоритмах, аналогічним JPEG. Кадр розбивається на блоки 8х8 пікселів. Над кожним блоком проводиться дискретно-косинусне перетворення (ДКП), з подальшим квантуванням отриманих коефіцієнтів. DCT (Discrete Cosine Transform, дискретное косинус-преобразование), DPCM (Differential Pulse Code Modulation, разностная импульсно-кодовая модуляция), а также фрактальные методы. Алгоритмы реализуются аппаратно - в виде специальных микросхем, или “firmware” - записанной в ПЗУ программы, либо чисто программно. Внаслідок високої просторової корелляції яскравості між сусідніми пікселями зображення, ДКП приводить до концентрації сигналу в низькочастотній частині спектра, який після квантування ефективно стискується з використанням кодування змінної довжини. Обробка передбачуваних (Predicted) кадрів проводиться з використанням прогнозу уперед по попередніх початкових або передбачуваних кадрах. Кадр розбивається на макроблоки 16х16 пікселів, кожному макроблоку ставиться у відповідність найбільш схожа дільниця зображення з опорного кадру, здвинута на вектор переміщення. Ця процедура називається аналізом і компенсацією рушення. Допустима міра стиснення для передбачуваних кадрів перевищує можливу для вихідних в 3 рази. У залежності від характеру відеозображення, кадри двунаправленної інтерполяції (Bi-directional Interpolated ) кодуються одним з чотирьох способів: прогноз уперед; зворотний прогноз з компенсацією рушення - використовується коли в кадрі, що кодується з'являються нові об'єкти зображення; двунаправленне прогноз з компенсацією рушення; внутрішньокадровий прогноз - при різкій зміні сюжету або при високій швидкості переміщення злементів зображення. З двунапрямленними кадрами пов'язане найбільш глибоке стиснення відеоданих, але, оскільки висока міра стиснення знижує точність відновлення початкового зображення, двунаправленні кадри не використовуються як опорні. Якби коефіцієнти ДКП передавалися точно, відновлене зображення повністю співпадало б з вихідним. Однак помилки відновлення коефіцієнтів ДКП, пов’язані з квантуванням, приводять до спотворень зображення. Чим грубіше проводиться квнтування, тим менший об'єм займають коефіцієнти і тим сильніше стиснення сигналу, але і тим більше візуальних спотворень.
ТЕКСТ. У керівництві Microsoft приділена особлива увага засобам введення і обробки великих масивів тексту. Рекомендуються різні методи і програми перетворення текстових документів між різними форматами зберігання, з урахуванням структури документів, керуючих кодів текстових процесорів або набірних машин, посилань, змісту, гіперзв’язків і т.ін., властивих початковому документу. Можлива робота і зі сканованими текстами, передбачене використання засобів оптичного розпізнання символів.
До складу пакету розробника Multimedia Development Kit (MDK) входять інструментальні засоби (програми) для підготовки даних мультимедіа BitEdit, PalEdit, WaveEdit, FileWalk, а також MSDK - бібліотеки мови для роботи зі структурами даних і пристроями мультимедіа, розширення Windows 3.0 SDK.
Серед авторських засобів, що рекомендуються для МОС - ТoolBook, Guide і Authorware Professional.
Архітектура Multimedia Windows передбачає незалежність від пристроїв і можливості розширення. Верхній системний рівень трансляції, представлений модулем ММsystem, ізолює програми (прикладний рівень) користувача від драйверів конкретних пристроїв. У склад MMsystem входять кошти Media Control Interface (MCI), які управляють відеомагнітофонами, відеодисками, звуковими компакт-дисками, забезпечують роботу зі сканерами, дигітайзерами і іншими пристроями. Для цього вони звертаються до драйверів MCI, що забезпечують верхній рівень управління. Драйвери MCI, обробивши запит, звертаються до пристроїв, а також до MEDIAMAN (Media Element Manager). MEDIAMAN управляє обробниками введення-виведення для растрових файлів і звукових WAVE-файлів. MMsystem включає також програми нижнього рівня - Low-Level Functions, керуючі драйверами звукових WAVE-пристоїв, MIDI, джойстиків. Необхідні драйвери підключаються на етапі виконання. Звернення до драйверів засноване на принципах посилки повідомлень, що спрощує і уніфікує їх написання і роботу з ними. Для представлення даних мультимедіа розроблена структура файлів RIFF (Resourse Interchange File Format), яка повинна забезпечити єдині правила запису і відтворення даних мультимедіа, обмін даними між додатками, а в перспективі - і між різними платформами.
Тема №6 Моделі гіпермедіа
Останнім часом з'являється безліч дешевих мультимедіа-продуктів, які містять структури подібні до «макаронів», з проблемами в їх підтримці і повторному використанні. Найчастіше це написані програмістами сторінки, які при побудові структури не використовували відповідні методики складної організації. Гіпертекст - це мережа записів, які пов'язані через встановлені посилання (зв'язку). Мультимедіа звичайно являє собою щось середнє між звичайним анімаційним відеосюжетом і зміною картинки, у зв'язку з діями оператора. При об'єднання в гіпермедіа кожен документ в мережі гіпертекста містить анімований мультимедіа об'єкт (презентацію). Використання принципів побудови гіпермедіа систем дозволяє покращити сприйняття документа, покращує його читабельність. Читабельність в даному випадку розраховується як кількість часу витрачена на освоєння одиниці інформації. При використанні якісного гіпермедіа документа користувач уникає втоми внаслідок надмірної службової інформації, яка існує для сприйняття суті документа. Кількість інформації в цьому випадку зручно коригується за моделями сприйняття, ступеня підготовки читача. Моделі в даному випадку є якоюсь оцінку кожного наступного вузла і посилань, найбільш заслуговують подальшого включення для отримання шуканого змісту документа. На жаль документи подаються в гіпремедіа системах досить складні, що призводить до значного збільшення простору параметрів по яких оцінюється подальше розкриття документа. Для пошуку маршруту гіпермедіа документ наповнюють елементами управління, такі як історія перегляду, карта документа, мітки і т.інш. Елементи управління повинні бути зручні та зрозумілі користувачеві. Структура документа може бути представлена в лінійному, матричному, ієрархічному або мережевому вигляді або представлених комбінаціях. Структура диктована природою інформації і підготовкою (рівнем) користувача. Структура гіпермедіа документа припускає наявність не тільки посилань і записів, а й наявність якогось контексту (стиснутої характеристики документа). Всі вище перелічені властивості приймає Тьюрінгова Машина, яка підтримує 8 пізнавальних принципів при створення гіпермедіа документа 1.Таблиця зв'язків повинна показувати співвідношення між двома записами. 2.Еквівалентності повинні бути визначені, читач повинен розуміти, що інформація асоціювання з декількох документів розділена в деяких вікнах. 3. Зміст записів має бути збережений. Це має бути показано дійсними записами, разом із суміжними записами. 4. Інформаційна одиниця з високим порядком повинна використовувати об'єднання інформації в складові компоненти і структуру документа. 5. Структура документа повинна показувати порядок надходження і визначати взаємозв'язок між об'єктами (предметами). 6. Подання має демонструвати сигнали, що визначають позицію читача в структурі. 7. Подання має надавати відповідні зручності для сфери(напряму), щоб читач міг рухатися вперед або назад. Якщо структура документа складна і сформована в складових записах, два додаткові типи руху повинні бути додані: вгору і вниз, відповідні верхньому і нижньому шару подання. 8. Подання повинно мати незмінне вікно шару.
На малюнку (Рис. 19) представлені 3 типових рівня розробки моделей мультимедіа. У процесі комплексної розробки всі три рівні можуть існувати незалежно. Так для незалежності рівня уявлень і даних необхідно, щоб логічний опис даних, не залежав від напряму їх представлення користувачу. Цей можливість, наприклад, змінювати формат подання або формат уявлень без звернень до бази даних та використання існуючих схем баз даних для переміщення додатків на Веб-сторінку. Така незалежність дає можливість мати різні уявлення інформації, згідно з вимогами профілю користувача. Незалежність між додатком і поданням дозволяє генерувати програми на різних програмних платформах, покращує портативність додатків. Зазвичай такі програми будуються за трьохрівневою схемою, як представлено на малюнку вище. Логічний рівень існує для пересилання даних до бази даних або файлу і доступу до даних користувача. Часто розглядають моделі представлення і моделі створення. Модель представлення служить для моделювання механізму низхідній структури документа в порядку взаємодії.
Гіпертекстова структурна модель НАМ. Одним з перших підходів до створення загальної моделі реалізації гіпертексту з'явився проект НАМ (Нурегtext Аbstract Масhine) - "багатокористувацький, заснований на транзакціях сервер загального призначення для зберігання гіпертекстової системи" [10]. Особливе значення при розробці надавалося створенню моделі пам'яті. Гіпертекстова система, побудована на базі НАМ, має чотири рівні (рис. 1).
Інтерфейс користувача - це багатовіконне інтерактивне оточення, що забезпечує користувачеві доступ до додатків. Додаток - конкретна прикладна задача, яка може бути реалізована і не на серверній машині. Нурегtext Аbstract Масhine - засіб управління всіма компонентами гіпертексту. Система пам'яті - сховище графів гіпертекстів та / або баз даних. Модель пам'яті НАМ містить п'ять основних об'єктів: графи (мережі вузлів та зв'язків з множинними контекстами), контексти (фрагменти даних з графів), вузли, зв'язку між вузлами та семантичні атрибути. Є можливість фіксації історії цих об'єктів, використання механізмів фільтрації даних і обмеження доступу. Граф є вищим рівнем ієрархії об'єктів (типовий гіпердокумент представляється у вигляді одного графа) і може містити декілька контекстів. Контексти дозволяють об'єднати вузли графа і використовуються для організації конфігурацій, орієнтованих на ті чи інші робочі місця користувачів, для представлення версій підграфів (наприклад версій проектних рішень) при груповій роботі. Вузли можуть містити дані будь-якого типу (текстові, графічні і т.інш.) і класифікуються як ті, що архівуються та ті, що неархівуються і доповнюються. Ппід час оновлення архівуємого вузла створюється версія з новим змістом, а попередня версія залишається доступною для пошуку. Для неархівуємих вузлів операція оновлення призводить до заміни старого змісту новим. У доповнюваних вузлах при оновленні новий зміст об'єднується зі старим. Зміст може бути об'єктом пошуку по запиту користувача, причому пошуковий механізм досліджує всі версії вузлів. Зв'язки описують відносини між вузлами і забезпечують переміщення (навігацію) по графу. Перехресні зв'язку дозволяють переміщатися між контекстами. Точки прив'язки, якоря в сенсі НТМL (Нурег Text Machine Language), в моделі НАМ відсутні. Атрибути можуть присвоюватися контекстами, вузлів і зв'язків. Вони представляються у вигляді послідовностей символів, цілих і дійсних чисел або мають тип, заданий користувачем. Пари (атрибут, значення) виражають семантику об'єктів НАМ. Атрибути описують властивості, суттєві для конкретного додатку або потенційно властиві даному об'єкту, а також використовуються в предикатах при відборі даних. Архітектура НАМ забезпечує контроль версій, фільтрацію і захист даних. Слід зазначити, що механізм фіксації версій (до речі кажучи, відсутний у багатьох більш сучасних моделях) істотно полегшує роботу в багатокористувацькому режимі, оскільки дозволяє проводити пошук інформації, що відноситься до певного моменту часу, тим самим виключаючи можливість конфліктів між повідомленнями, що надходять. Модель пам'яті НАМ була успішно використана у відомих гіпертекстових системах для роботи з електронними документами NoteCards [11] і Intermedia [12,13]. У гіпертекстової системи для CAD-додатків Neptune, заснованій на моделі НАМ, в якості мови користувацького рівня була прийнята графічна мова GraphLog.
Абстрактна модель гіпертексту Trellis. Модель Trellis, заснована на мережах Петрі, була запропонована Річардом Фурутой (Richard Furuta) і Девідом Стоттсом (David Stotts) в 1988 р.. Вона була реалізована в однойменній гіпертекстовій системі, а пізніше (в 1990 р.) перероблена в метамодель, названу г-модель (повна назва - Trellis hypertext reference model). Структура гіпертексту може бути вибрана довільно. Система Трелліс, за Стотсом і Фурутою, використовує структуру мережі Петрі, яка забезпечує автомат семантики, в якості мережі представлення.
Проект Trellis досліджує структуру і семантику просторово описаної взаємодії. Гіперпрограмма пов'язує змінювану користувачем інформацію (гіпертекст) з направленою користувачем поведінкою виконання (процесом). Отже, можна говорити, що гіперпрограмма, об'єднує завдання з інформацією. Таким чином, порядок виконання гіперпрограмми може бути визначений колективними діями групи користувачів. Структурні особливості гіпердокумента дозволяють реалізувати специфікацію паралельного протоколу, а також координувати перевірку цього протоколу. Такі динамічні особливості гіперпрограмми, дозволяють створювати прототипи і розгортати необхідні специфікації. Модель Trellis формально визначена застосуванням мережі Петрі. Отже, гіпертексти, визначені в Trellis, описують традиційну колекцію гіпермедіа об'єктів даних і відносин серед об'єктів, а також визначають процеси, якими користуються об'єкти. Поняття Trellis-гіпертексту, охоплює всі форми комп'ютерного середовища. На додаток, ця специфікація дозволяє використовувати активний зміст, такий як відео і аудіо, а також процедурний зміст, такий як обчислення і вкладені гіпертексти. Реалізація Trellis часто використовує розподілену архітектуру клієнт-сервер. Таким чином, здійснюється безпосередній обмін між зверненням "користувача" і "клієнта", який може бути реалізований множинним підключенням процесів клієнтів, класи користувачів можуть групуватися і бути представлені єдиним клієнтом мережі Trellis. Клієнти можуть спілкуватися з комп'ютерними процесами, а не з конкретними кінцевими користувачами. Таким чином, документ Trellis визначає середовище, в якому складові об'єкти можуть бути динамічними і в якому простір документа також змінюється динамічно. Простір документа може бути пов'язаний з діями, розпочатими користувачем або простором користувачів. Багато розроблювачів помітили цікавий ефект, що, оскільки інформаційні інтерфейси подання стають більш «розумними», вони приймають характеристики специфікації інтерфейсу. Наприклад, структуровані системи підготовки / подання до документа використовуються, щоб визначити і реалізувати спільні інтерфейси (тобто, активні документи). Створення інтерфейсу в такому просторі, якщо і пристосоване, то може звертатися тільки оригінальними запитами. Зокрема специфікація користувальницьких інтерфейсів, використання активних систем документа, - є завданням розробників таких програм. Досвід, методи, і навички розробників можуть бути використані, для організації та написання традиційних документів і організації нової прикладної області. Формальна основа, якою є мережа Петрі, дозволяє розробникам поводити автоматичну сертифікацію інструментів. Так як Trellis є динамічною, то специфікації можуть використовуватися безпосередньо в прототипуванні запитів. Клієнт-серверна архітектура виконання завдань дозволяє розподілене виконання протоколу і представляє можливість розробникам спеціалізованих, налаштованих інтерфейсів приймати одночасно підказки орієнтовані на налагодження інтерфейсу від розробників. Гібридна виконавча ситема зберігає особливості і здібності батьківського середовища. Отже гіпертекстова основа дозволяє природне об'єднання документації системи в місцях реалізації. Особливий інтерес представляє природа протоколу та специфікацій до вимог прикладної області. Технічні протоколи програмного забезпечення включають формальні та напівформальні елементи. Відносини серед цих елементів і процедур, які супроводжуються їх маніпуляціями, у свою чергу визначені більш високим рівнем - протоколами.
Гіпертекстові структури не обмежується мережою; описи, які обмежені також можуть бути використані. Елементи структури в графі не повинні бути в повній мірі зв’язаними. Ця структура забезпечує тільки власників місця, які будуть пов'язані зі змістом гіпертексту і вона описує відносини, які існують між цими власниками.
Модель включає п'ять рівнів. На відміну від НАМ і деяких інших відомих моделей, рівні t-моделі - це рівні абстракції, а не компоненти гіпертекстової системи. Ці рівні можна розбити на три категорії: абстрактні, конкретні і видимі (visible).
Рівень абстрактних компонентів. На даному рівні компоненти майбутнього гіпертексту.Цей рівень вміщував абстрактні представлення незалежних компонентів, які будуть поєднані разом у майбутньому представленні. Зв'язки відсутні. Структура (у вигляді орієнтованого графа) відділена від змісту (сутностей) і кнопок, що керують навігацією по гіпертексту. Структура t -моделі може представлятися мережею Петрі, деревами, гратами, незв'язними графами. На даному рівні структура тільки "резервує місце" для змісту гіпертекста. На малюнку зв’язки між компонентами вказують, що концепція на більш низькому рівні, залежить від концепції на більш високому рівні абстракції. Компоненти реальної гіпертекстової системи повинні бути встановлені в моделі Trellis (г-модель), щоб застосувати цю модель в якості еталонної. Загалом ускладнення виникають через наявність різних компонентів може бути охарактеризована тільки на певних рівнях моделі.
Абстрактна сутність в загальному вигляді це текст, графіка, анімація, відео і звук. Сутності, ще не взаємопов'язані, але можуть містити маркери, що визначають місця потенційних зв'язків. Абстрактні сутності описуються незалежно від їх майбутнього візуального наповнення.
Абстрактна кнопка є прототипом майбутнього відображення зв'язків між компонентами гіпертексту. У описі абстрактної кнопки вказується її зміст і спосіб візуализації (виділення шрифтом, кольором і т. ін.).
Абстрактний контейнер містить опис того, як частини гіпертексту будуть скомбіновані для представлення користувачеві.
Рівень абстрактного гіпертексту. На даному рівні встановлюються відображення (асоціації) між компонентами гіпертексту.
Відображення суть-структура: одна і та ж суть може відображатися в декілька вузлів структури і, навпаки, в один вузол можуть відображатися декілька сутностей. Розділення змісту і структури на абстрактному рівні має ту перевагу, що наповнення змісту ніяк не впливає на зміну структури. Відображення кнопка-структура встановлює відповідність між абстрактними кнопками і дугами орієнтованого графа. В мережах Петрі кнопки фактично відповідають перебігам, тобто взаємно однозначної відповідності між кнопками і дугами не існує. Відображення контейнер-структура дозволяє групувати елементи структури у відповідності до їх наступного візуального відображення. Можна передбачити, як послідовне відтворення, так і накладання елементів.
Рівень конкретного контексту. На даному рівні відбувається поєднання змісту гіпертексту і зв’язків між його компонентами. Конкретний контекст є описом гіпертексту, безпосередньо орієнтований на фізичну реалізацію. В цьому описі гіпертекту повинно бути відображене наступне:
Як має бути відформатований абстрактний зміст для того, щоб відповідати області відображення (екрану, вікну і т.інш.)?
Як мають відтворюватися кнопки? Чи повинний змінюватися образ кнопки в залежності від контекста?
Чи вказує зв'язок на сутність в цілому або на елемент сутності? Який взаємний вплив чинять відображувані сутності?
Рівень конкретного гіпертексту. На данному рівні формується «віконне» представлення конкретного контексту. Розв’язується питання про відображення взаємопов’язаних сутностей. Наприклад, чи закривати раніш активізовані вікна при відкритті нових, модифікувати їх або виводити вікна з перекриттям? На данному рівні лишається, однак відкритим питання прив’язки вікон до конкретних інтерфейсів.
Рівень видимого гіпертексту. Це рівень кінцевої деталізації зовнішнього представлення гіпертексту. Слід підкреслити, що такі «дрібниці», як розмір та позиціонування вікону в межах R-моделі не розглядаються. Видимий сегмент гіпертексту пов'язаний з конкретним інтерфейсом і представлений у вигляді одного або декількох вікон з конкретним вмістом. Питання інтерактивної взаємодії також не розглядаються в R-моделі.
Розробники данної моделі утрималися від обмежань таких аспектів моделі, як семантика перегляду, характеристики змісту, характеристика рівня реалізації та користувацькі інтерфейси. Таким чином, модель Trellis варто б було віднести до неповністю визначених або взагалі до набору рекомендацій для розробки гіпертекстової структури, який дозволяє вільно обирати інструменти реалізації і зміст.
Множина моделей DEXTER. Розробка моделі Dexter (повна назва – Dexter Hypertext Reference Model) стала частиною проекта DeVise у відділенні обчислювальної техніки міста Орхус (Aarhus University) в Данії. Завдання Dexter було узагальнити найкращі проектні рішення групи гіпертекстових систем єдиної моделі даних і процесів. Метою розробки є створення систематизованої основи для порівняльного аналіза і встановлення стандартів для їх взаємодії.
На основі моделі Dexter розроблено об’єктно-орієнтовану інтегровану гіпермедіа систему. Діючий прототип системи отримав назву Dexter Vise Hypermedia (DHM), яка використовується на платформах Macintosh та Unix. Розроблена також інструментальна оболонка – Scandinavian Mjoliner Beta System (MBS). У DHM реалізовані поняття атомарних і складних компонентів (composites) та багатоцільових (multihead) зв’язків. На відміну від «класичної» моделі Dexter, в DHM існують як помічені, так і непомічені якоря(anchors), а також «незакріплені» (dangling) зв’язки (зв’язки без кінцевих вершин).
Метою Dexter Hypertext Reference Model є визначення будь абстракції певний серед існуючих або майбутніх гіпертекстових систем у порядку порівняння функціональності та підвищення сумісності.
Модель складається з трьох шарів. Шар зберігання описує мережі вузлів і зв'язків. Шар виконання описує механізми підтримки взаємодії користувача з гіпермедіа. Шар компонентів стосується змісту і структури гіпермедіа вузлів. Між цима трьма шарами існують два інтерфейси механізми: якірний механізм, який діє як інтерфейс між шаром зберігання і шаром компонент, і механізм специфікації презентацій, який виступає в ролі інтерфейсу між шаром зберігання і шаром виконання. Модель в даний час є найбільш потужною, ніж будь-яка існуюча система гіпермедіа. Множинні посилання і складні компоненти призначені для конструювання розміщення майбутніх систем гіпермедіа. Ні існуюча система включає в себе множинні посилання і складні компоненти. В повному об’ємі модель ще не досліджена для порівняння з існуючими конструкціями гіпертекстових систем. Необхідним кроком є розробка декількох систем гіпертекстових використанням конструкцій з моделі Dexter. Ці гіпертекстові системи повинні бути обрані для представлення широкого спектру конструкцій, доменних додатків, впровадження платформ.
Шар виконання. Цей шар має справу з поданням гіпертексту і динамікою взаємодії з користувачем. В моделі Dexter (Декстер) цей шар не вдається в подробиці механізму презентації. Однак, механізми презентації можуть бути визначені і містити інформацію про те, як компоненти/мережі будуть представлені користувачеві. Ці презентації характеристики забезпечують інтерфейс між шаром виконання і шар зберігання.
Шар зберігання. Цьому шарові приділяється основна увага в моделі Dexter.
На рівні пам’яті зібрані об’єкти, постійно зберігаються (persistent). Основний компонент данного ровня - це компонент, який включає опис змісту, набір атрибутів загального призначення, опис відтворення та набір якорів.
Це моделі бази даних, яка складається з ієрархії даних, що містять компоненти, з'єднання реляційних зв'язків. Компоненти мають унікальні ідентифікатори і посилання можуть бути визначені з двох або більше ідентифікаторів компонентів. Компоненти відповідають загальному поняттю вузлів і можуть містити текст, графіку, зображення, аудіо, відео та ін компоненти розглядаються як загальні контейнери даних і модель не передбачає жодної структури в контейнерах. Таким чином, шар зберігання не робить різниці між компонентами текстовими і графічними компонентами. Він орієнтований в основному на механізм, за допомогою якого компоненти і посилання пов'язані разом, для формування гіпертекстової мережі.
Шар компонентів. Цей рівень відповідає за зміст і структуру компонентів гіпертекстової мережі. Оскільки діапазон можливого змісту / структури, які можуть бути включені в компонент відкритого складу, модель Dexter розглядає цей шар як такий що виходить за межі. Передбачається, що структура документа буде використовуватися у поєднанні з цією моделлю для відображення змісту / структури. Тим не менш, критичний інтерфейс між шаром зберігання і шаром компонентів, званий якорем обумовлює механізм розташування місць або предметів зі змістом окремих компонентів. Якорі можуть ідентифікуватися унікальним ідентифікатором якоря.
Атомарний компонент - абстракція вузла гіпертексту. Складний компонент забезпечує механізм ієрархічної структуризації. Зміст компонента зв'язку (або просто - зв'язки) - це набір точних покажчиків, що включають опис представлення компонента, його ідентифікатор і ідентифікатор якора. Зв'язки характеризуються парами ідентифікаторів (початковий вузол, кінцевий вузол). У вузли можуть вміщуватися компоненти різних типів: текст, графіка, відео, аудіо і т.д.
На рівні виконання (run-time layer) здійснюється управління зв'язками, якорами і компонентами. Об'єктами даного рівня є сеанси (sessions), керуючі взаємодією користувача з гіпермедіа, і примірники, або процедури породження примірників (instantiation), що керують взаємодією з окремими компонентами.
Виконуюча система відповідальна за зовнішнє представлення гіпермедіа і організацію динамічного діалогу. Взаємодія інтерфейсу даного рівня з пам'яттю здійснюється за допомогою набору описів зовнішнього представлення компонентів, опис розмірів і розташування вікон, способи їх заміщення і/або накладення.
Рівень змісту (within-component layer) відповідає конкретним додаткам. На даному рівні описується внутрішній зміст компонентів. Інтерфейс між пам'яттю і рівнем змісту має механізм "якірної прив'язки" компонентів і їх внутрішніх елементів. Якір складається з ідентифікатора, на який можуть спиратися зв'язки, і значення, за яким вибирається "причеплений" до якора фрагмент гіпермедіа.
В Dexter можуть використовуватися такі кошти структурування документів, як SGML або його підмножина, що розширюється XML (Extensible Markup Language) і інш.
Зв'язкі, якора і структур моделі Dexter. Зв'язки. В Dexter є багатоцільові зв'язки. Більш того зв'язки, будучи компонентами гіпермедіа, самі можуть бути кінцевими точками (цілями) інших зв'язків. Зв'язки можуть бути як статичними, так і що обчислюються (процедурними).
Висячі зв'язки резервують місця для потенційних цілей і відсікання фрагментів незадіянного тексту в конкретному сеансі. Основні причини появи висячих зв'язків: 1) кінцева (цільова) точка зв'язку була видалена; 2) об'єкт, на який вказує зв'язок, недоступний; 3) неправильне значення якора.
Орієнтація зв'язків визначається однією з чотирьох констант: FROM ("звідки", "з", "від"), ТО ( "куди", "в", "к"), ВIDERЕСТ (двонапрямлена), NONE (ніяка). Причому покажчик ТО повинен бути привласнений будь-якому зв'язку.
Основні типи орієнтації зв'язків:
1. Семантична орієнтація. Семантично орієнтовані зв'язки звичайно є або керівниками, або виражаються функціями, що визначаються екстенційно, тобто своїми парами (аргумент, значення).
2. Породжуюча орієнтація. До класу породжуючих зв'язків можна, наприклад, віднести всі загальновживані конструктори типів чи як функції, що визначаються за допомогою опису способу обчислення.
3. Направляюча орієнтація. Направляючі (traversal) зв'язки можуть пройти тільки в одному напрямі: від джерела (reference) до приймача (referent).
Тут потрібно вважати недоліком примусову прив'язку функціональної орієнтації зв'язку до її фізичних точок відправлення і прибуття.
Якорі. Якори в Dexter визначаються як точки "склеювання" мережевих структур з одержимим окремих компонентів, забезпечують доступ всередину компонентів. Кожний якір визначається всередині компонента, що містить його. Покажчик зв'язку містить ідентифікатори як компонента, так і якоря.
У DHM розрізнюються якори трьох типів:
Об'єкт поміченого якора маркер зв'язку (link marker), представляється у вигляді піктограм, шрифтових виділень і т.ін.
непомічені якори не мають маркерів зв'язку. Їх місцеположення всередині компонента повинно обчислюватися. У текстових компонентах DHM існують спеціальні непомічені якори, звані ключовими словами. Значеннями якорів є копії фрагментів тексту: слова, словосполучення, фрази і т.д.
Компонентний якір відповідає вирожденому випадку зв'язку, кінцева точка якої не має ніякої якірної прив'язки всередині змісту компонента.
Структури. У Dexter складний компонент - це звичайний вузол мережі, по-іншому, - сховище структури, в якій можуть бути як інші атомарні і/або складові компоненти, так і зв'язки як повноправні компоненти.
Як подальше дослідження "структурних проблем" в DHM пропонується наступне.
Для Dexter властиві:
1)віртуальні і компоненти, що зберігаються. Кожному віртуальному компонентові може бути присвоєний прапор. Такі компоненти існують в БД тільки остільки, оскільки на них посилаються інші компоненти, і створюються, як правило, за запитами на час одного сеансу, а потім, якщо за вказівкою користувача не отримують статусу "збережених", знищуються в процесі "збирання сміття ".
2)статичні компоненти і ті, що обчислюються(змінюються). Обчислення також відбувається за запитам користувачів, або в результаті відстеження інтесионально визначених визначених породжуюючих зв'язків. Зміст обчислюваних компонентів змінюється. Наприклад, набір елементів для перегляду може змінюватися в результаті попередньої обробки фрагменту мережі.
3) зміст компонентів може бути досить складно структурований чи містити посилання на інші компоненти. Браузери зв'язків, наприклад, організовуються як віртуальні обчислювані компоненти, зміст яких утворюють посилання на компоненти зв'язків. Ніяких видимих технічних труднощів за такої організації змінних компонентів не виникає.
Інтеграція і зміст компонентів моделі Dexter. Останнім часом дослідники і розробники роблять спроби використовувати гіпермедіа для вирішення проблем інтеграції локальних завдань. Прикладами можуть служити системи PROXHY і IRIS. Пропонується, зокрема, замість побудови однієї, в певному сенсі глобальної, гіпермедійної системи зайнятися розробкою моделі систем гіпермедіа, споконвічно орієнтованої на інтеграцію і спільну (кооперативну) роботу. У модель Dexter закладено хороші передумови для цього. На рівні архітектури Dexter розрізняє віртуальні і збережені об'єкти гіпермедіа, а також об'єкти рівня вмісту компонентів, що належать до додатків. Взагалі кажучи, ці додатки можуть знаходитися поза гіпермедійного простору даної системи. При цьому залишається відкритим питання про те, хто відповідає за зміст цих компонентів і керує ними. Існує також проблема якірної прив'язки до змісту цих компонентів.
В якості прикладу наведемо два способи представлення атомарних об'єктів. Перший полягає у включенні програми з усіма його об'єктами безпосередньо в гіпермедійне середовище. При другому способі об'єкти зберігаються окремо (наприклад у файлах Word або Exel) і пов'язані з вмістом компонента посиланнями. Найчастіше до такого способу зв'язку доводиться вдаватися при наявності в додатках файлів великих об'ємів (наприклад відеофайлів або файлів анімації), які неможливо помістити безпосередньо ООБД гіпермедійної системи. У "класичної" моделі Dexter складовий компонент інкапсулює свої об'єкти даних. Це досить вузьке розуміння суті складових компонентів, хоча і дозволяє моделювати такі, наприклад, структури, як графічне полотно (canvas). У більш складних додатках може виникнути необхідність у посиланнях на інші компоненти або зовнішні об'єкти даних