Skip to main content
LibreTexts - Ukrayinska

9.2: Структурування описів

  1. Last updated
  2. Save as PDF
  • Page ID
    53763

    • \( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \) \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)\(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\) \(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\)

    Вибір способу структурування описів ресурсів - це питання прийняття принципових і цілеспрямованих проектних рішень, щоб вирішити конкретні проблеми, служити конкретним цілям або привнести в описи якусь бажану властивість. Більшість з цих рішень є специфічними для певної області: конкретний контекст застосування для розроблюваної організаційної системи та види взаємодії з ресурсами, які вона дозволить. Прийняття такого роду контекстно-специфічних рішень призводить до створення моделі цієї області. (Див. «Абстракція в описі ресурсу».)

    Згодом багато людей побудували подібні види описів. Вони мали схожі цілі, бажані схожі властивості, і стикалися з подібними проблемами. Не дивно, що вони зійшлися на деяких однакових рішеннях. Коли можна визначити загальні набори проектних рішень, які не є специфічними для якоїсь однієї області, вони часто систематизуються в підручниках і в практиках проектування, і в кінцевому підсумку можуть бути розроблені в стандартні формати і архітектури для створення організаційних систем. Ці формально визнані набори дизайнерських рішень відомі як абстрактні моделі або метамоделі. Метамоделі описують структури, які зазвичай зустрічаються в описах ресурсів та інших інформаційних ресурсах, незалежно від конкретної області. Хоча будь-який дизайнер організаційної системи зазвичай створює модель свого конкретного домену, вона, як правило, не створює абсолютно нову метамодель, а замість цього зробить вибір серед метамоделей, які були офіційно визнані та включені в існуючі стандарти. Отриману модель іноді називають «мовою, специфічною для домену». » Повторне використання стандартних метамоделей може принести великі економічні переваги, оскільки розробники можуть повторно використовувати інструменти, призначені для та знання про ці метамоделі, а не починати з нуля.

    У наступних розділах ми розглянемо деякі поширені види структур, які використовуються в якості основи для метамоделей. Але спочатку розглянемо конкретний приклад того, як структура описів ресурсів підтримує або гальмує ті чи інші види використання. Як ми пояснили в «Основах організації систем», концепція ресурсу підкреслює відмінності між фізичними та цифровими речами на користь зосередження уваги на тому, як речі, загалом, використовуються для підтримки цілеспрямованої діяльності. Різні види книг можуть розглядатися як інформаційні ресурси незалежно від конкретного поєднання матеріальних і нематеріальних властивостей, які вони можуть мати. Оскільки описи ресурсів також є інформаційними ресурсами, ми можемо аналогічно розглянути, як їх структури підтримують конкретне використання, незалежно від того, чи є вони фізичними, цифровими чи сумішшю обох.

    Картка обрешітки

    Приклад перфокарти.

    Приклад перфокарти, яка використовується Баттеном для опису конкретного патенту в патентній колекції. Кожна карта представляла собою індивідуальний термін опису, і кожна позиція удару на картці представляла собою певний патент.

    Під час Другої світової війни британський хімік на ім'я У.Е. Баттен розробив систему організації патентів. [1] Система складалася з мови для опису продукту, процесу, використання та апарату патенту, а також способу використання перфокарток для запису цих описів. Batten використовували карти, надруковані матрицями на 800 позицій (див. Рис.: A Batten Card.). Кожна карта представляла собою певне значення з лексики мови опису, і кожна позиція відповідала певному патенту. Щоб описати патент № 256 як покриття екструзії поліетилену для виготовлення кабельних покриттів, спочатку слід вибрати картки для значень поліетилену, екструзії та кабельних покриттів, а також потім пробийте кожну карту на 256-й позиції. Опис патенту № 256 таким чином поширюватиметься на ці три карти.

    Перевага цієї структури полягає в тому, що для пошуку патентів, що охоплюють екструзію поліетилену (для будь-яких цілей), потрібно лише вибрати дві карти, що відповідають цим значенням, покласти одну на іншу і тримати їх до світла. Світло буде просвічувати скрізь, де є положення, відповідне патенту, описаному з використанням цих значень. Патенти, що відповідають певному опису, легко знайти завдяки структурі карток, призначених для опису патентів.

    Звичайно, ця система також має явні недоліки. Пошук понять, пов'язаних з певним патентом, є нудним, тому що кожна картка повинна бути перевірена. Додавання нового патенту відносно легко, якщо існує індекс, який дозволяє швидко знаходити картки для конкретних понять. Однак, як тільки на картах не вистачає місця для пробивання отворів, весь набір карт повинен бути продубльований, щоб розмістити більше патентів: дуже дорога операція. Додавання нових концепцій потенційно легко: просто додайте нову картку. Але якщо ми хочемо мати можливість знайти існуючі патенти, використовуючи нову концепцію, всі існуючі патенти доведеться переглянути, щоб визначити, чи слід пробивати їх позиції на новій картці: також дорога операція.

    Структура карт Баттена підтримувала швидкий відбір ресурсів з урахуванням часткового опису. Види структур, які ми розглянемо в наступних розділах, не настільки складні, як карти Баттена. Але як і карти, кожен вид конструкції підтримує більш ефективне механічне виконання тих чи інших операцій, за рахунок менш ефективного виконання інших.

    види конструкцій

    Набори, списки, словники, дерева та графіки - це види структур, які можуть бути використані для формування описів ресурсів. Як ми побачимо, кожен з цих видів насправді є сімейством споріднених структур. Ці структури є абстракціями: вони описують формальні структурні властивості в загальному вигляді, а не вказують точну фізичну або текстову форму. Абстракції корисні тим, що вони допомагають нам бачити загальні властивості, що поділяються різними конкретними способами організації інформації. Зосереджуючись на цих загальних властивостях, ми можемо легше міркувати про операції, які підтримують різні форми, та доступності, які вони надають, не відволікаючись на менш релевантні деталі.

    краплі

    Найпростіший вид споруди - це взагалі ніякої конструкції. Розглянемо наступний опис книги: роман Себальда використовує пішохідну екскурсію в Східній Англії, щоб медитувати на зв'язки між минулим і сьогоденням, Сходом і Заходом. [2] Цей опис є неструктурованим текстовим виразом без чітко визначених внутрішніх частин, і ми можемо вважати його краплею. Або, точніше, він має структуру, але ця структура є основою граматичної структури англійської мови, і жодна з цієї граматичної структури явно не представлена в поверхневій структурі, коли речення виражено. Як читачі англійської мови ми можемо інтерпретувати пропозицію як опис предмета книги, але зробити це механічно складно. [3] З іншого боку, такий письмовий опис відносно легко створити, оскільки описник може просто використовувати природну мову.

    Крапля не повинна бути краплиною тексту. Це може бути фотографія ресурсу або запис розмовного опису ресурсу. Як і краплі тексту, краплі пікселів або звуку мають основну структуру, яку може легко зрозуміти будь-яка людина з нормальним зором або слухом. [4] Але ми можемо розглядати ці краплі як неструктуровані, оскільки жодна з базових структур у зоровому чи слуховому вході не є явною, і ми стурбовані тим, як структури описів ресурсів підтримують або гальмують механічні чи обчислювальні операції. [5]

    Набори

    Найпростіший спосіб структурувати опис - дати йому частини і розглядати їх як набір. Наприклад, опис роману Себальда можна переформулювати як сукупність термінів: Себальд, роман, Східна Англія, ходьба, історія. Роблячи це втратило значну частину сенсу, але щось знайшло: тепер ми можемо легко відрізнити Себальда і ходьбу як окремі пункти в описі. [6] Це полегшує пошук, наприклад, всіх описів, які включають термін ходьба. (Зауважте, що це відрізняється від простого пошуку через текстові описи слова ходьба. При розгляді як набір, опис Фіджі, пожежна ходьба, мемуари не включають термін ходьба, хоча він включає термін вогнева ходьба.)

    Набори дозволяють легко знаходити перехрестя серед описів. Набори також легко створювати. У розділі «Класифікація проти тегів» ми розглянули «фольксономії», організовуючи системи, в яких непрофесійні користувачі створюють описи ресурсів. У цих системах описи структуровані як набори «тегів». » Щоб знайти ресурси, користувачі можуть вказати набір тегів для отримання ресурсів, які мають описи, які перетинаються на цих тегах. Це є більш цінним, якщо теги походять з керованого словника, що робить перетину більш імовірними. Але забезпечення контролю словникового запасу додає складності процесу опису, тому необхідно дотримуватися балансу між максимізацією потенційних перетинів і зробити опис таким простим, як практичним. [7]

    Безліч - це тип або клас структури. Ми можемо уточнити визначення різних видів множин шляхом введення обмежень. Наприклад, ми можемо ввести обмеження, що даний набір має максимальну кількість елементів. Або ми можемо обмежити набір, щоб завжди мати однакову кількість елементів, даючи нам набір фіксованого розміру. Ми також можемо зняти обмеження. Набори не містять дублікатів елементів (подумайте про систему тегів, в якій не має сенсу призначати один і той же ресурс один і той же тег більше одного разу). Якщо ми видалимо це обмеження унікальності, ми матимемо іншу структуру, відому як «мішок» або «мультимножина». »

    Списки

    Обмеження - це те, що відрізняє списки від множин. Список, як і набір, являє собою сукупність предметів з додатковим обмеженням: їх елементи впорядковуються. Якби ми розробляли систему тегів, в якій було важливо підтримувати порядок тегів, ми хотіли б використовувати списки, а не набори. На відміну від множин, списки можуть містити повторювані елементи. У списку два пункти, які в іншому випадку однакові, можна розрізнити за своїм положенням в замовленні, але в наборі це неможливо. Наприклад, ми можемо впорядкувати теги, присвоєні ресурсу, перерахувавши спочатку найбільш використовуваний тег, найменш часто використовуваний останній, а решта відповідно до частоти їх використання.

    Знову ж таки, ми можемо ввести обмеження для уточнення визначення різних видів списків, таких як списки фіксованої довжини. Якщо ми обмежимо список, щоб містити тільки елементи, які самі є списками, і далі вказуємо, що ці містяться списки самі по собі не містять списки, то у нас є таблиця (список списків елементів). Електронна таблиця - це список списків.

    Словники

    Одним з основних обмежень списків і наборів є те, що, хоча елементи можуть бути розглянуті окремо, немає ніякого способу розрізнити елементи, крім порівняння їх значень (або, в списку, їх позиції в замовленні). Наприклад, у наборі таких термінів, як Себальд, роман, Східна Англія, ходьба, історія, не можна легко сказати, що Себальд посилається на автора книги, тоді як Східна Англія і ходьба посилаються на те, що це таке про. Одним із способів вирішення цієї проблеми є розбиття кожного елемента множини на дві частини: властивість і значення. Так, наприклад, нашим простим набором тегів може стати автор: Sebald, тип: роман, тема: Східна Англія, тема: ходьба, тема: історія. Тепер можна сказати, що автор, тип і тема - це властивості, а вихідні елементи в наборі - це значення.

    автор

    Себальд

    тип

    роман

    предмет 1

    Східна Англія

    суб'єкт 2

    ходьба

    тема 3

    історія

    Такий вид структури називається словником, картою або асоціативним масивом. Словник являє собою набір пар властивості-значення або записів. Це набір записів, а не список записів, тому що пари не впорядковані і тому, що кожен запис повинен мати унікальний ключ. [8] Зауважте, що це спеціалізоване значення словника відрізняється від більш поширеного значення «словник» як алфавітний список термінів, що супроводжуються реченнями, які їх визначають. Однак ці два значення пов'язані між собою. Як і «справжній» словник, словникова структура дозволяє нам легко знайти значення (наприклад, визначення), пов'язане з певною властивістю або ключем (наприклад, словом). Але на відміну від реального словника, який упорядковує свої ключі в алфавітному порядку, словникова структура не вказує порядок його ключів. [9]

    Словники всюдисущі в описах ресурсів. Структуровані описи, введені за допомогою форми, легко представляються у вигляді словників, де мітки елементів форми є властивостями, а введені дані - це значення. Табличні дані з «рядком заголовка» можна розглядати як набір словників, де заголовки стовпців є властивостями для кожного словника, а кожен рядок - набір відповідних значень. Словники також є основним типом структури даних, що зустрічається майже у всіх мовах програмування (іменованих асоціативними масивами).

    Знову ж таки, ми можемо ввести або видалити обмеження для визначення спеціалізованих типів словників. Сортований словник додає порядок над записами; іншими словами, це список записів, а не набір. Мультимапа — це словник, у якому декілька записів можуть мати однаковий ключ.

    Дерева

    У словниках, як їх прийнято розуміти, властивості - це терміни, а значення - відповідні їм визначення. Терміни та значення - це, як правило, слова, фрази або інші вирази, які можна впорядкувати за алфавітом. Але якщо узагальнити поняття словника як абстрактних наборів пар властивості-значення, то значення можуть бути взагалі будь-якими. Зокрема, значення можуть самі бути словниками. Коли словникова структура має значення, які самі по собі є словниками, ми говоримо, що словники вкладені. Вкладеність дуже корисна для описів ресурсів, які потребують більшої структури, ніж те, що може надати (не вкладений) словник.

    На малюнку: Чотири вкладених словника. представлений приклад вкладених словників. На верхньому рівні є один словник з єдиним записом, що має властивість a. Значення, пов'язане з a, є словником, що складається з двох записів, перша має властивість b, а друга має властивість c. Значення, пов'язані з b і c, також є словниками.

    Чотири вкладені словники

    Графічне представлення вкладених словників.

    Якщо ми вкладаємо словники так, а наш «верхній» словник (той, який містить всі інші) має тільки один запис, то у нас є своєрідна деревоподібна структура. Малюнок: Дерево властивостей і значень. показує ті самі властивості та значення, що і на рис.: Чотири вкладені словники., цього разу організовано так, щоб структура дерева була більш видимою. Дерева складаються з вузлів (букв і цифр на рис.: Дерево властивостей і значень), з'єднаних краями (стрілками). Кожен вузол в дереві з кругом навколо нього є властивістю, а значення кожної властивості складається з вузлів, розташованих нижче (праворуч) його в дереві. Вузол називається батьківською частиною вузлів, розташованих під ним, які, в свою чергу, називаються дочірніми вузлами цього вузла. Ребра показують ці «батьківські» відносини між вузлами. Вузол без батька називається коренем дерева. Вузли без дітей називаються листовими вузлами.

    Дерево властивостей і значень

    Графічне представлення вкладених словників у вигляді дерева.

    Альтернативним представленням вкладених словників є дерево. Найнижчий рівень або вершини дерева містять значення властивостей.

    Як і в інших розглянутих нами типах конструкцій, ми можемо визначити різні види дерев, вводячи різні типи обмежень. Наприклад, переважна метамодель для XML Information Set або Infoset. [10]

    XML Information Set визначає певний вид деревоподібної структури шляхом додавання дуже специфічних обмежень, включаючи впорядкування дочірніх вузлів, до основного визначення дерева. Додавання обмеження впорядкування відрізняє Figure: A Tree of Properties і Values. зображує різновид дерева з різним набором обмежень: всі нелистяні вузли є властивостями, а всі листки - значення. Ми також могли б визначити дерево, в якому кожен вузол має як властивість, так і значення. Дерева існують у великій різноманітності смаків, але всі вони мають спільну топологію: ребра між вузлами спрямовані (один вузол є батьківським, а інший - дочірнім), і кожен вузол, крім кореня, має рівно одного батька.

    Дерева надають можливість групувати заяви, що описують різні, але пов'язані ресурси. Наприклад, розглянемо опис, структурований у вигляді словника тут:

    Опис Структурований як словник

    імена автора → Вінфрід Георг прізвище
    автора → Себальд
    title →
    Сторінки Рінґе де Сатурна     → 371

    Словник групує чотири пари властивості-значення, що описують певну книгу. (Стрілки - це просто схематичний спосіб вказати відносини властивості-значення. Пізніше в розділі ми розглянемо способи «написання» цих відносин за допомогою якогось специфічного синтаксису.)

    Але насправді перші два записи не описують книгу, вони описують автора книги. Отже, було б краще якось згрупувати ці два твердження. Ми можемо зробити це, вклавши записи, що описують автора в опис книги, створивши деревоподібну структуру:

    Вкладання опису автора в описі книги

    автор →
    дані імена → Вінфрід Георг
    прізвище →
    Назва Себальда     →
    Сторінки Рінґе де Сатурна     → 371

    Використання дерева в цьому випадку добре працює, тому що ми можемо розглядати книгу як основний ресурс, який описується, зробивши її коренем нашого дерева, і додаючи опис автора як «гілку». »

    Ми також могли б зробити автора основним ресурсом, надавши нам дерево, подібне до того, що у прикладі: Вкладення описів книг у описі автора.

    Вкладання описів книг у описі автора

    дані імена → Вінфрід Георг
    прізвище → Себальд
    книги автора →
    1. назва →     Die Ringe des Saturn
    сторінки → 371
    2. назва → Аустерліц
    сторінки → 416

    Зауважте, що в цьому словнику значенням властивості books authored є список словників. Створення автора основним або кореневим ресурсом дозволяє нам включати кілька описів книг у дерево (але ускладнює опис книг, що мають декількох авторів). Дерево є хорошим вибором для структурування описів до тих пір, поки ми можемо чітко визначити основний ресурс. Однак у деяких випадках ми хочемо з'єднати описи пов'язаних ресурсів без необхідності призначати їх як первинні. У цих випадках нам потрібна більш гнучка структура даних.

    Графіки

    Припустимо, ми описували дві книги, де автор однієї книги є предметом іншої, як у прикладі: Два пов'язаних опису:

    Два пов'язаних опису

    1. автор → Марк Річард Маккаллох
    назва → Розуміння В.Г. Себальда
    предмет → Вінфрід Георг Себальд
    2. автор → Вінфрід Георг Себальд
    title → Кільце Сатурна

    Дивлячись на ці описи, ми можемо вгадати зв'язок між двома книгами, але цей зв'язок явно не представлений у структурі: ми просто маємо два окремих словника і зробили висновок про зв'язок шляхом зіставлення значень властивостей. Цілком можливо, що цей висновок може бути неправильним: можуть бути дві людини на ім'я Вінфрід Георг Себальд. Як ми можемо структурувати ці описи, щоб явно представляти той факт, що Вінфрід Георг Себальд, який є предметом першої книги, - це той самий Вінфрід Георг Себальд, який є автором другої?

    Однією з можливостей було б зробити Вінфріда Георга Себальда коренем дерева, подібно до підходу, взятого в Приклад: Вкладення описів книг в описі автора, додавання книги про властивість поряд з книгами, які були написані один. Це рішення працювало б добре, якби люди були нашими основними ресурсами, і, таким чином, було б сенс структурувати наші описи навколо них. Але припустимо, що ми вирішили, що наші описи повинні бути структуровані навколо книг, і що ми використовували словниковий запас, який прийняв цю перспективу (з такими властивостями, як автор і предмет, а не книги автором і книги про). Ми не повинні дозволяти певній структурі обмежувати організаційну перспективу, яку ми можемо взяти, як це робили картки Баттена. Натомість ми повинні свідомо вибирати структури, які відповідають нашій організаційній перспективі. Як ми можемо це зробити?

    Якщо ми розглядаємо наші два описи книг як дерева, ми можемо об'єднати дві гілки (суб'єкт і автор), які поділяють цінність. Коли ми це робимо, у нас більше немає дерева, тому що тепер у нас є вузол з більш ніж одним батьківським (Рис.: Описи, пов'язані в графіку.) . Структура на малюнку: Описи, пов'язані в графік. являє собою графік. Як і дерево, графік складається з набору вузлів, з'єднаних ребрами. Ці ребра можуть мати або не мати напрямок («Спрямованість»). Якщо вони це роблять, граф називається «орієнтованим графом». » Якщо граф спрямований, можливо, можна почати з вузла і слідувати за краями на шляху, який веде назад до початкового вузла. Такий шлях називається «циклом». Якщо орієнтований граф не має циклів, його називають «ациклічним графом. »

    Дерево - це просто більш обмежений вид графіка. Дерева є спрямованими графами, оскільки «батьківський» зв'язок між вузлами асиметричний: ребра - це стрілки, які вказують у певному напрямку. (Див. «Симетрія».) Крім того, дерева - це ациклічні графіки, тому що якщо ви будете слідувати за спрямованими краями від одного вузла до іншого, ви ніколи не зможете зіткнутися з одним і тим же вузлом двічі. Нарешті, дерева мають обмеження, що кожен вузол (крім кореня) повинен мати рівно одного батька. [11]

    На малюнку: Описи, пов'язані з графіком. ми порушили це обмеження, приєднавшись до наших двох книжкових дерев. Графік, який призводить, все ще спрямований і ациклічний, але оскільки вузол Вінфріда Джорджа Себальда тепер має двох батьків, це вже не дерево.

    Зупиніться і подумайте: властивості соціальної мережі

    Порівняйте поняття «друг» у Facebook з поняттям «послідовник» у Twitter, з точки зору семантичних властивостей, обговорюваних у «Властивостях семантичних відносин», та властивостей графіка, розглянутих у цьому розділі.

    Графіки є дуже загальними і гнучкими структурами. Багато видів систем можна розглядати як вузли, з'єднані ребрами: станції, з'єднані лініями метро, люди, пов'язані дружбою, рішення, пов'язані залежностями тощо. Відносини можна моделювати різними способами, використовуючи різні типи графів. Наприклад, якщо ми припустимо, що дружба симетрична (див. «Симетрія»), ми використаємо неорієнтований граф для моделювання відносин. Однак в веб-соціальних мережах дружба часто буває асиметричною (можна «дружити» того, хто не відповідає взаємністю), тому орієнтований граф більш доречний.

    Описи, пов'язані з графіком

    Графічне представлення описів ресурсів, пов'язаних у граф.

    Описи можуть бути пов'язані для формування графіка, коли значення, призначене двом різним властивостям, однакове.

    Часто корисно розглядати графік як сукупність пар вузлів, де кожна пара може бути або не бути безпосередньо з'єднана ребром. Багато підходів до характеристики структурних взаємозв'язків між ресурсами (див. «Структурні відносини між ресурсами») базуються на моделюванні пов'язаних ресурсів як сукупності пар вузлів, а потім аналізі закономірностей зв'язності між ними. Як ми побачимо, можливість розбити графік на пари також корисна, коли ми структуруємо описи ресурсів як граф s.

    У «Світі обробки документів» ми будемо використовувати Рисунок: Описи, пов'язані з графіком. використовуючи «посилання», щоб з'єднати книгу з її назвою, авторами та темою. Це дозволить нам розробити складні графіки знань в рамках одного екземпляра XML-документа. (Див. також бічну панель, Включення та посилання) [12]

    Порівняння метамоделей: JSON, XML та RDF

    Тепер, коли ми знайомі з різними видами метамоделей, які використовуються для структурування описів ресурсів, ми можемо детальніше розглянути деякі конкретні метамоделі. Детальне порівняння доступності різних метамоделей виходить за рамки цієї глави. Тут ми просто коротко розглянемо три популярні метамоделі - JSON, XML та RDF - щоб побачити, як вони додатково визначають та обмежують більш загальні види метамоделей, представлених вище.

    JSON

    Позначення об'єктів JavaScript (JSON)

    JavaScript Object Notation (JSON) - текстовий формат для обміну даними, який запозичує свою метамодель з мови програмування JavaScript. Зокрема, метамодель JSON складається з двох видів структур, знайдених у JavaScript: списки (звані «масивами» в JavaScript) та словників (які називаються «об'єктами» у JavaScript). Списки та словники містять значення, які можуть бути рядками тексту, чисел, логічними значеннями (true або false) або нульовим (порожнім) значенням. Знову ж таки, ці типи значень беруться безпосередньо з JavaScript. Списки та словники також можуть бути значеннями, тобто списки та словники можуть бути вкладені один в одного, щоб створити більш складні структури, такі як таблиці та дерева.

    Списки, словники та базовий набір типів значень складають «Системи написання» далі в цьому розділі.) Крім того, багато сучасних мов програмування надають структури даних та типи значень, еквівалентні тим, що надаються JavaScript. Таким чином, дані, представлені як JSON, легко працювати з багатьма мовами програмування, а не тільки JavaScript.

    XML Інформаційний набір

    Метамодель XML Information Set походить від структур даних, що використовуються для розмітки документа. (Див. «Метадані».) Ці структури розмітки — елементи та атрибути — добре підходять для програмних маніпуляцій зі структурою документів та даних разом. [13]

    Інформаційний набір XML

    Інфосет XML - це деревоподібна структура, де кожен вузол дерева визначається як «інформаційний елемент» певного типу. Кожен інформаційний елемент має набір специфічних для типу властивостей, пов'язаних з ним. У корені дерева знаходиться «елемент документа», який має рівно один «елемент елемента» як його дочірній. Елемент має набір елементів атрибутів та список дочірніх вершин. Ці дочірні вузли можуть включати інші елементи елементів або вони можуть бути символьними елементами. (Див. «Види структур» нижче, щоб дізнатися більше про символи.) Елементи атрибутів можуть містити елементи символів або містити набрані дані, такі як маркери імен, ідентифікатори та посилання. Ідентифікатори елементів та посилання (ID/IDREF) можуть використовуватися для з'єднання вузлів, перетворюючи дерево на граф. (Див. бічну панель, Включення та посилання.) [14]

    Рисунок: Структура опису. Це графічне зображення того, як XML-документ може бути використаний для структурування частини опису автора та його робіт. Цей приклад демонструє, як ми можемо використовувати елементи елементів для моделювання домену опису, надаючи їм імена, такі як автор та назва. Елементи символів, які є дочірніми елементами цих елементів, містять зміст опису: імена авторів, назви книг тощо. Елементи атрибутів використовуються для зберігання допоміжних відомостей про цей вміст, наприклад його мову.

    A Структура опису

    Графічне представлення XML-документа у вигляді дерева, що містить елемент, атрибут і символьні вузли.

    XML-документ можна описати як дерево, в якому елементи є вузлами, які можуть містити вміст символів безпосередньо або атрибути, що містять вміст символів.

    Цей приклад також демонструє, як інформаційний набір XML підтримує змішаний вміст, дозволяючи елементам та елементам символів бути «братами та сестрами» одного батьківського елемента. У цьому випадку структура Infoset дозволяє вказати, що опис книги може відображатися у вигляді рядка тексту, що складається з оригінального заголовка і перекладеного заголовка в дужках. Елементи та атрибути використовуються для позначення того, що цей рядок тексту складається з двох назв, написаних різними мовами, а не з одного заголовка, що містить дужки.

    Якби не змішаний вміст, ми не могли б написати розповідний текст із гіпертекстовими посиланнями, вбудованими в середині речення. Це дає нам можливість ідентифікувати підкомпоненти речення, щоб ми могли розрізнити терміни «Себальд», «ходьба» та «Східна Англія» як автора та двох суб'єктів.

    Використання схем для визначення форматів представлення даних є гарною практикою, яка полегшує спільне розуміння та сприяє довгостроковій ремонтопридатності в інституційному або діловому контексті. Схема XML являє собою договір між сторонами, які підписалися на його визначення, тоді як JSON залежить від позасмугового спілкування між програмістами. Поняття про те, що «код - це документація», може бути модним серед програмістів, але модельєри вважають за краще проектувати на більш високому рівні абстракції, а потім реалізовувати.

    Інфосет XML представляє сильний контраст з JSON і не завжди відображає в простий спосіб структури даних, що використовуються в популярних мовах веб-сценаріїв. У той час як структури JSON полегшують об'єктно-орієнтованим програмістам легко обмінюватися даними, їм не вистачає будь-якої формальної мови схеми і не можуть легко обробляти змішаний вміст.

    RDF

    На малюнку: Описи, пов'язані з графом., ми структурували опис нашого ресурсу як графік, розглядаючи ресурси, властивості та значення як вузли, а ребра відображають їх комбінацію в описові твердження. Однак більш поширеним підходом є розглядання ресурсів і значень як вузлів, а властивості - як ребер, які їх з'єднують. Рис.: Обробка властивостей як ребер, а не вузлів. показує той самий опис, що і на рис.: Описи, пов'язані з графіком., цього разу властивості обробляються як ребра. Це приблизно відповідає конкретному виду метамоделі графіка, визначеному RDF. («Опис ресурсів Framework (RDF)»)

    Лікування властивостей як ребер, а не вузлів

    Графічне зображення взаємозв'язку між ресурсами, властивостями і цінностями.

    Ми можемо розглядати кожен компонент опису як пару вузлів (ресурс і значення) з ребром (властивістю), що пов'язує їх. Тут у нас є два книжкові ресурси, які пов'язані з чотирма значеннями через п'ять властивостей. Єдиний вузол значення, «Вінфрід Джордж Себальд» є предметом однієї книги, будучи автором другої книги. Книги зображуються у вигляді квадратів, краї - у вигляді стрілок з мітками, а значення — текстовими рядками.

    Ми зазначили, що ми можемо розглядати графік як набір пар вузлів, де кожна пара може бути з'єднана ребром. Аналогічно ми можемо розглядати кожен компонент опису на рис.: Обробка властивостей як ребер, а не вузлів. як пара вузлів (ресурс і значення) з ребром (властивістю), що пов'язує їх. У метамоделі RDF пара вузлів і її край називається трійкою, тому що вона складається з трьох частин (двох вузлів і одного ребра). Метамодель RDF - це орієнтований граф, тому вона ідентифікує один вузол (той, з якого спрямований край) як предмет трійки, а інший вузол (той, на який вказує ребро) як свій об'єкт. Край називається присудок або (як ми вже говорили) властивість трійки.

    Лістинг трійки індивідуально

    Графічне зображення взаємозв'язку між ресурсами, властивостями і цінностями.

    Перераховує кожну з трійок окремо. Тут кожне твердження пов'язує один ресурс до одного значення через ребро. Таким чином, ми маємо два різних вузли значення «Вінфрід Джордж Себальд». Книги зображуються у вигляді квадратів, краї - у вигляді стрілок з мітками, а значення — текстовими рядками.

    Малюнок: Перерахування трійок індивідуально. перераховує окремо всі трійки на малюнку: Обробка властивостей як ребер, а не вузлів. Однак чогось не вистачає на малюнку: Перерахування трійок індивідуально.. Малюнок: Лікування властивостей як країв, а не вузли. чітко вказує на те, що Вінфрід Джордж Себальд, який є предметом книги 1, - це той самий Вінфрід Джордж Себальд, який є автором книги 2. На малюнку: Перерахування трійок індивідуально. ці відносини не зрозумілі. Як ми можемо сказати, чи Вінфрід Джордж Себальд з третьої трійки такий же, як Вінфрід Джордж Себальд з потрійної заяви? З цього приводу, як ми можемо визначити, чи всі перші три трійки включають одну і ту ж книгу 1? Це легко показати на схемі всього графіка опису, де ми можемо мати кілька ребер, прикріплених до вузла. Але коли ми розбиваємо цей графік на трійки, нам потрібен якийсь спосіб однозначно посилаючись на вузли. Нам потрібні ідентифікатори («Вибір хороших імен та ідентифікаторів»). Коли дві трійки мають вузли з однаковим ідентифікатором, ми можемо знати, що це один і той же вузол. RDF досягає цього шляхом асоціації URI з вузлами. (Див. розділ «Опис ресурсів Framework (RDF)»)

    Необхідність ідентифікації вузлів, коли ми розбиваємо графік RDF на трійки, стає важливою, коли ми хочемо «написати» графіки RDF - створювати текстові уявлення про них замість того, щоб їх можна було обмінюватися як дані. Деревовидні структури не обов'язково мають цю проблему, оскільки можна текстуально представляти деревоподібну структуру, не згадуючи жодного вузла більше одного разу. Таким чином, однією ціною, заплаченою за загальність і гнучкість графічних структур, є додаткова складність запису, представлення або написання цих структур.

    Вибір ваших обмежень

    Цей компроміс між гнучкістю та складністю ілюструє більш загальний момент щодо обмежень. У контексті управління та взаємодії з описами ресурсів обмеження є хорошою справою. Як обговорювалося вище, дерево - це графік з дуже специфічними обмеженнями. Ці обмеження дозволяють робити речі з деревами, які неможливі з графіками загалом, наприклад, представлення їх у текстовому вигляді, не повторюючись, або однозначно ідентифікувати вузли шляхом від кореня дерева до цього вузла. Це може зробити управління описами та ресурсами, які вони описують, простіше та ефективніше - якщо деревоподібна структура добре відповідає вимогам організаційної системи. Наприклад, упорядкована деревоподібна структура добре підходить для ієрархічної структури вмісту книги або книжкового документа, такого як керівництво по обслуговуванню літаків або подання SEC. З іншого боку, мережа відносин між людьми та організаціями, які співпрацювали над створенням книги, може бути краще представлена за допомогою графічної структури. XML найчастіше використовується для представлення ієрархій, але також здатний представляти мережеві структури.

    Моделювання в межах обмежень

    Метамодель накладає певні обмеження на структуру описів наших ресурсів. Але в організаційних системах нам зазвичай потрібно додатково вказати зміст і склад описів конкретних видів організовуваних ресурсів. Наприклад, при проектуванні системи організації книг недостатньо сказати, що опис книги структуровано за допомогою «Абстракції в описі ресурсу».)

    При проектуванні організаційної системи ми можемо вибрати повторне використання стандартної моделі. Наприклад, [22]

    Якщо такого стандарту не існує або існуючі стандарти не відповідають нашим потребам, ми можемо створити нову модель для нашої конкретної області. Але ми зазвичай не будемо створювати нову метамодель: натомість ми зробимо вибір з числа метамоделей, таких як [23]

    Визначення словників та схем

    Створення моделі опису ресурсів у певній області передбачає визначення загальних елементів цих описів та надання цим елементам стандартних назв. (Див. «Процес опису ресурсів») Модель може також вказати, як ці елементи розташовані у більші структури, наприклад, як вони впорядковані у списки, вкладені в дерева. Метамоделі відрізняються інструментами, які вони надають для визначення структури та складу конкретних доменних моделей, а також зрілості та надійності методів їх проектування. [24] RDF та XML надають різні інструменти, специфічні для метамоделі, для визначення моделі для певної області. Але не кожна метамодель надає такі інструменти.

    У схемах. Схема XML, що визначає модель домену, надає словниковий запас термінів, які можуть бути використані як імена елементів і атрибутів у XML-документах, які дотримуються цієї моделі. Наприклад, схема Onix for Books визначає, що автора книги слід називати учасником, а кількість сторінок має називатися Extent. Схема XML також визначає правила того, як ці елементи, атрибути та їх вміст можуть бути організовані у структури вищого рівня. Наприклад, Onix for Books вказує, що опис книги повинен містити список елементів автора, що цей список повинен містити принаймні один елемент і що кожен елемент учасника повинен мати дочірній елемент ContributorRole. елемент.

    Якщо [25] Пов'язування схеми з перевіркою: автоматична перевірка правильності використання словникових термінів. [26]

    Якщо два опису мають однаковий опис зв'язків і структур.)

    Деревовидні структури можуть значно відрізнятися, при цьому вони все ще відповідають метамоделі інфонабору XML. Користувачі XML часто вказують правила перевірки того, чи відображаються певні шаблони в XML-документі (перевірка на рівні документа). Це рідше робиться з RDF, оскільки графіки, які відповідають метамоделі RDF, мають однакову структуру: всі вони є множинами трійок. Ця спільна структура дозволяє легко поєднувати різні описи RDF, не турбуючись про перевірку структури на рівні документа. Однак іноді бажано перевіряти описи на рівні документа, як коли потрібна частина опису. Як і у випадку з XML, якщо споживачі цих описів хочуть стверджувати, що вони очікують, що ці описи матимуть певну структуру (наприклад, необхідну властивість), вони повинні перевірити їх на рівні документа.

    Тому що семантична павутина. (Також див. «Семантичний Web і пов'язані дані», а також далі в цьому розділі.) [27]

    Наприклад, стандарт опису ресурсів та доступу (RDA) для каталогізації бібліотечних ресурсів містить набір словників RDF, що визначають предикати, які можна використовувати в описі каталогізації. Одним з таких присудків є:

            <http://rdvocab.info/Elements/extentOfText>

    який визначається як «кількість і тип одиниць та/або підодиниць, що складають ресурс, що складається з тексту, з супровідними ілюстраціями або без них. » Словниковий запас додатково вказує, що цей присудок є уточненням більш загального присудка:

            <http://rdvocab.info/Elements/extent>

    який може бути використаний для позначення «кількості та типу одиниць та/або субодиниць, що складають ресурс» незалежно від того, є він текстовим чи ні.

    JSON не вистачає будь-якого стандартизованого способу визначення, які терміни можуть бути використані. Це не означає, що при створенні описів за допомогою JSON не можна використовувати стандартний словник, лише те, що не існує узгодженого способу використання JSON для повідомлення про те, який словник використовується, і немає можливості автоматично перевірити, чи правильно він використовується.

    Контроль значень

    Поки що ми зосередилися на тому, як моделі визначають словники термінів і як ці терміни можна використовувати в описах. Але моделі також можуть обмежувати значення або зміст описів. Іноді одна модель визначає як терміни, які можна використовувати для імен властивостей, так і терміни, які можуть бути використані для значень властивостей. Наприклад, [28]

    Однак часто існують окремі спеціалізовані словники термінів, призначені для використання як значень властивостей в описах ресурсів. Зазвичай ці словники надають значення для використання в операторах, які описують, що таке ресурс. Приклади таких предметних словників включають тематичні заголовки Бібліотеки Конгресу (LOC-SH) та заголовки медичних предметів (MESH). [29] Інші словники можуть надавати авторитетні імена людей, корпорацій чи місць. Схеми класифікації - це ще один вид словникового запасу, надаючи назви категорій для використання в якості значень у описових твердженнях, які класифікують ресурси.

    Оскільки різні метамоделі використовують різні підходи до визначення словників, зазвичай існують різні версії цих словників для використання з різними метамоделями. Наприклад, LCSH доступні як у форматі XML, що відповідає стандарту опису органу метаданих (MADS), так і у вигляді RDF за допомогою системи організації простих знань (SKOS). словниковий запас.

    Визначення словника - це лише один із способів, яким моделі можуть керувати тим, які значення можуть бути присвоєні властивостям. Інша стратегія полягає в тому, щоб вказати, які типи значень можуть бути присвоєні. Наприклад, модель опису книг може вказувати, що значення властивості pages має бути натуральним цілим числом. Або це може бути більш конкретним; каталог курсу може дати кожному курсу ідентифікатор, який містить дволітерний код відділу, а потім 1-3 цифри номер курсу. Визначення такого типу даних за допомогою регулярного виразу звужує набір можливих значень для властивості без необхідності перераховувати всі можливі значення. (Див. Бічну панель.)

    На додаток до або замість вказівки типу, модель може вказувати схему кодування значень. Схема кодування - це спеціалізована система запису або синтаксис для певних типів значень. Наприклад, модель типу Atom для опису синдикованого веб-вмісту вимагає дати публікації. Але існує безліч різних способів написання дат: 9/2/76, 2 вересня 1976 року, 2 вересня 1976 і т.д. також Atom вказує схему кодування значень дат. Схема кодування - RFC3339, стандарт для запису дат. При використанні RFC3339 завжди записується дата, використовуючи ту саму форму: 1976-09-02. [30]

    Схеми кодування часто визначаються спільно зі стандартизованими ідентифікаторами. (Див. «Зробити імена інформативними».) Наприклад, International Standard Book Numbers (ISBN) - це не просто послідовності арабських цифр: це значення, записані за схемою кодування ISBN. У цій схемі вказано, як розділити послідовність числівників на частини, і як слід трактувати кожну з цих частин. ISBN 978-3-8218-4448-0 складається з п'яти частин, перші три з яких вказують на те, що ресурс з цим ідентифікатором є 1) продуктом книговидавничої галузі, 2) опублікованим в німецькомовній країні, і 3) опублікованим видавництвом Ейхборн.

    Схеми кодування можна розглядати як дуже спеціалізовані моделі певних видів інформації, таких як дати або ідентифікатори книг. Але оскільки в них вказується не тільки структура цієї інформації, але і те, як вона повинна бути написана, ми також можемо розглядати їх як спеціалізовані системи письма. Тобто схеми кодування вказують, як текстово представляти інформацію.

    У другій половині цього розділу ми зупинимося на питаннях, пов'язаних з текстовим представленням описів ресурсів — їх написання. Графіки, дерева, словники, списки та множини - це загальні типи структур, що зустрічаються в різних метамоделах. Думаючи про ці широкі типи та те, як вони підходять або не відповідають тим, як ми хочемо моделювати описи наших ресурсів, може допомогти нам вибрати конкретну метамодель. Конкретні метамоделі, такі як ресурси та колекції в нашій конкретній області. Але оскільки метамоделі абстрактні і існують лише на концептуальному рівні, вони можуть лише взяти нас до цих пір. Якщо ми хочемо створювати, зберігати та обмінюватися окремими описами ресурсів, нам потрібно зробити структури, визначені нашими абстрактними метамоделями, конкретними. Нам потрібно їх написати.

    1. Це обговорення карт Баттена засноване на (Ланкастер 1968, стор. 28-32). Власне пояснення Баттена знаходиться в (Баттен 1951).

      ←

    2. (Сільман 1998). (Себальд 1995).

      ←

    3. Техніка складання діаграм речень була винайдена в середині 19 століття Стівеном У. Кларком, нью-йоркським шкільним майстром; (Clark2010) є точним передруком майже 100-річного видання його книги «Практична граматика». Недавня данина Кларку є (Florey 2012).

      БІРЮЧІ


    4. Легко недооцінити неймовірну силу людини сприйняття та когнітивної систем застосовувати нейронні обчислення та знання, щоб дозволити зору та слуху здаватися автоматичними. Комп'ютери стають кращими у витягуванні функцій із зорових та слухових сигналів для ідентифікації та класифікації входів, але наша думка полягає в тому, що жодна з цих функцій явно не представлена у вхідному «краплинці» або «потоці». »

      ←

    5. Як ми коментували раніше, усний опис ресурсу може бути не особливо корисним в організаційній системі, оскільки комп'ютери не можуть легко зрозуміти його. З іншого боку, існує багато контекстів, в яких усний опис був би особливо корисним, наприклад, під час екскурсії по музею, де відвідувачі можуть використовувати аудіогарнітури.

      ←

    6. Те, що було втрачено, - це раніше невидима структура, надана граматикою, яка змусила нас розподіляти ролі кожному з цих термінів, щоб створити смислове тлумачення.

      ←

    7. Рідко практично робити речі максимально простими. За словами Ейнштейна, ми повинні прагнути «зробити все максимально простим, але не простіше. »

      ←

    8. Ця структурна метамодель дозволяє лише одне значення для кожної властивості, що означає, що вона не працюватиме для книг з кількома авторами або для обговорення декількох предметів.

      ←

    9. Однак йти в інший бік не так просто: так само, як справжні словники не підтримують пошук слова з визначенням, а також словникові структури не підтримують пошук ключа, заданого значенням.

      БІРЮЧІ


    10. Інформаційний набір XML (Cowan2004)

      Document Design Matters, (Wilde and Glushko 2008b) зазначають, що «Якщо дизайнер формату обміну використовує концептуальну метамодель, що не є XML, оскільки вона, здається, краще підходить для моделі даних, XML використовується лише як фізичний рівень для моделі обміну. Логічний шар в цьому випадку визначає відображення між концептуальною моделлю, що не є XML, і будь-яка реконструкція даних моделі обміну вимагає від споживача повної обізнаності про це відображення. У такому випадку хороша практика, щоб користувачі API знали про те, що він використовує метамодель, що не є XML. В іншому випадку вони можуть спокуситися базувати свою реалізацію на занадто малому наборі прикладів, створюючи реалізації, які є крихкими і в якийсь момент часу зазнають невдачі. »

      ←

    11. Технічно те, що описано тут, математики називають «вкоріненим деревом», які визначають дерева загалом. Оскільки дерева, що використовуються як структури даних, завжди вкорінені дерева, ми не робимо відмінності тут.

      ←

    12. Ця функція спирається на існування схеми XML. Схема XML може оголошувати, що певні атрибути мають тип ID, IDREF або IDREFS. Будь XML DTD або один з багатьох мов схеми, які були розроблені під егідою W3C або ISO.

      БІРЮЧІ


    13. http://www.w3.org/TR/xml-infoset/.

      БІРЮЧІ


    14. Інфосет XML є однією з багатьох метамоделей для XML, включаючи DOM і XPath. Як правило, XML Infoset створюється як побічний продукт розбору добре сформованого екземпляра XML-документа. Документ XML також може бути поінформований його DTD або схемою з інформацією про типи значень атрибутів та їх значень за замовчуванням. Атрибути типу ID, IDREF та IDREF забезпечують механізм внутрішньодокументного гіпертекстового зв'язування та включення. Екземпляр документа XML може містити визначення сутностей та посилання, які розгортаються під час аналізу документа, тим самим пропонуючи іншу форму включення.

      ←

    15. Добре сформований екземпляр XML-документа при обробці дасть інформаційний набір XML, як описано тут. Інформаційні набори також можуть бути побудовані іншими способами, такими як перетворення з іншого інформаційного набору. Докладніше див. У розділі Синтетичні інфонабори http://www.w3.org/TR/xml-infoset/#intro.synthetic.

      ←

    16. Infoset містить знання про те, чи всі пов'язані оголошення були прочитані та оброблені, базовий URI екземпляра документа, інформацію про типи атрибутів, коментарі, інструкції з обробки, неаналізовані сутності та позначення тощо.

      Добре сформований екземпляр XML-документа, для якого є пов'язані схеми, такі як DTD, може внести інформацію до Infoset. Примітно, що схеми можуть пов'язувати типи даних з елементами інформації про елементи та атрибути, а також вказувати стандартні або фіксовані значення для атрибутів. DTD може визначати сутності, на які посилаються в екземплярі документа і розгортаються на місці під час обробки. Ці внески можуть вплинути на істинну цінність документа.

      ←

    17. У стандарті SGML прямо зазначено, що документація, що описує або пояснює DTD, є частиною визначення типу документа. Мається на увазі, що схема не тільки про визначення синтаксису, але і семантики. Більше того, оскільки DTD не дають можливості описати всі можливі обмеження, такі як обмеження спільного виникнення, документація може служити керівництвом щодо споживання людиною для реалізаторів, а також творців та споживачів контенту.

      ←

    18. Типи атрибутів можуть бути оголошені в XML DTD або схемі. Атрибути, типом яких є ID, повинні мати дійсне значення імені XML, яке є унікальним у цьому XML-документі; атрибут типу IDREF, значення якого відповідає унікальному ідентифікатору, має властивість «references», значенням якої є вузол елемента, який відповідає елементу з таким ідентифікатором. . Атрибут типу IDREFS, значення якого відповідає списку унікальних ідентифікаторів, має властивість «references», значенням якого є список вузлів елементів, що відповідають елементу (ам) з відповідними ідентифікаторами.

      ←

    19. Включення XML (XInclude) є (Болото, Сад, і Вейяр 2006).

      БІРЮЧІ


    20. XML зв'язування мови (XLink) є (DeRose, Малер, Орчард, і Уолш 2010).

      БІРЮЧІ


    21. У межах DTD документа просто оголошує сутність та відповідне значення, яке може бути чим завгодно від усього документа до фрази, а потім на нього можна посилатися на місці в екземплярі XML-документа. Посилання на сутність замінюється значенням сутності в інформаційному наборі XML. Сутності, як іменовані обгортки, ефективно зникають на своєму шляху в XML Infoset.

      ←

    22. Online Information Exchange (ONIX) є міжнародним стандартом представлення та передачі інформації про продукцію книжкової індустрії в електронному вигляді: http://www.editeur.org/11/Books/.

      ←

    23. Не беріть на себе завдання створення нового (Bray 2005) за порадою про те, як зменшити ризик оформлення словникового запасу, якщо ви не можете знайти існуючий, який задовольняє вашим вимогам.

      ←

    24. Див. (Глушко та МакГрат 2005) для синтезу найкращих практик створення доменних мов у контекстах технічного видавництва та обміну документами від бізнесу до бізнесу. Вам потрібні найкращі практики для великих проблем, тоді як малі можуть бути атаковані спеціальними методами.

      ←

    25. Якщо не є просторами назв. Наприклад, якщо елемент з назвою «title» означає «назва книги» в одній схемі та «почесне, пов'язане з особою» в іншій, екземпляри можуть мати елементи з префіксами простору імен, наприклад <book:title>Дисципліна організації</book:title> та <hon :Назва>Професор</hon:title>. Простіри імен є загальним джерелом розчарування в XML, оскільки вони здаються надмірно складним рішенням простої проблеми. Але крім уникнення зіткнень з іменами, вони важливі в складі схеми та організації.

      ←

    26. Що означає «правильно», залежить від мови схеми, яка використовується для кодування концептуальної моделі типу документа. Сімейство стандартів XML включає кілька мов схем, які відрізняються тим, наскільки повністю вони можуть кодувати концептуальну модель типу документа. Визначення типу документа (DTD) бере свій початок у публікації та добре застосовує структурні обмеження; він виражає сильне введення даних через пов'язані ресурси документації. XML Schema Definition Language (XSD) краще для представлення типів транзакційних документів, але його додана виразна сила, як правило, робить його більш складним.

      ←


    27. Наприклад, див. Пов'язані відкриті словники за адресою lov.okfn.org/dataset/lov/index.html.

      ←

    28. Значення атрибутів можуть бути обмежені в схемі, вказавши тип даних, значення за замовчуванням і список потенційних значень. Типи даних дозволяють нам вказати, чи має значення бути ім'я, число, дата, маркер або рядок тексту. Встановивши тип даних, ми можемо додатково обмежити значення атрибута, вказавши діапазон значень, наприклад, для числа або дати. Ми також можемо використовувати шаблони регулярних виразів для опису типу даних, таких як поштовий індекс, номер телефону або номер ISBN. Задання значень за замовчуванням і списків правових значень для атрибутів спрощує процес створення контенту та забезпечення якості. У Schematron, мова схеми XML на основі правил для створення тестових тверджень про XML-документи, ми можемо виразити обмеження між елементами та атрибутами таким чином, що інші мови XML-схеми не можуть. Наприклад, ми можемо висловити обмеження, що якщо <title>передбачено два елементи, то кожен повинен містити унікальне строкове значення і різні значення мовних атрибутів.

      ←

    29. Дивіться LOC-SH як http://id.loc.gov/authorities/subjects.html; MESH на http://www.nlm.nih.gov/mesh/.

      ←

    30. Протокол публікації атома IETF RFC 5023, (tools.ietf.org/html/rfc5023); гарне введення є (Сайре 2005). ІЕФ РФК є http://www.ietf.org/rfc/rfc3339.txt.

      ←

    31. Немає єдиного авторитету з приводу регулярних виразів або їх синтаксису. Хорошою відправною точкою є стаття Вікіпедії на цю тему: http://en.Wikipedia.org/wiki/Regular_expression.

      ←
    1. Back to top
    • Was this article helpful?

    Recommended articles

    1. Article type
      Section or Page
    2. Tags
      1. authorname:rjglushko
      2. source[translate]-human-73621