KML (Knowledge Markup Language). В данном документе приведено описание языка разметки и публикации формализованных знаний KML — Knowledge Markup Language. KML предназначен для формирования Базы Знаний, состоящей из структурированных и связанных элементов. Язык KML создан на базе XML - расширяемого языка разметки, подробное описание которого можно найти на http://www.w3.org/ или http://www.xml.com/axml/testaxml.htm.
Язык KML включает в себя языки HTML (Hyper Text Markup Language), XLink (eXtended Links) и содержит дополнительные возможности для смыслового структурирования и связывания элементов знаний.
KML — это новый подход к формализации и способу публикации человеческих знаний в Internet. KML относится к классу языков разметки, однако, данные рекоммендации выходят за рамки описания синтаксиса языка. KML — не только язык, это среда для обмена знаниями между людьми в фомализованном виде.
KML предназначен для всех, кто хочет открыто публиковать новые знания. Это научные работники, преподаватели, ученые и экперты всех областей. Будем называть их разработчиками знаний. А также для тех, кто хочет получать новые знания в простой форме, для тех, кто хочет быстро искать интересующую его информацию и не читать лишнего, быть в курсе всех новых событий в мире знаний. Это студенты и школьники, ученые и эксперты, работающие в смежных областях — пользователи знаний.
Предыстория у данного формата практически отсутствует. Идея создания специального формата для хранения каких-либо ресурсов, в принципе, не нова, но ее реализация для случая, когда в качестве ресурсов выступают человеческие Знания еще нигде не появлялась. Точнее, существует множество моделей представления человеческих знаний (фреймовая теория, семантические сети, продукционные правила...), более того, существуют соответствующие языки, которые позволяют реализовывать эти модели. Однако, все они либо очень специфичны, а следовательно, не обладают достаточной для человека экспрессивностью, либо чересчур абстрактны, что осложняет их понимание как человеком так и машиной.
Но в последнее время деятельность в направлении поиска некого универсального языка резко активизировалась, что связано с ростом образовательных сайтов и широким распространением идеи дистанционного обучения посредством Интернет. Т.е. создание так называемых Интернет-стандартов. И сегодня разработаны специальные форматы для записи математических (MathML), химических формул (CML), диаграмм (SVG) и других объектов мира науки вместе с приложениями, которые позволяют как конструировать соответствующие объекты, так и предоставлять репрезентацию этих объектов. Ранее, например, когда общепринятые форматы отсутсвовали, такие объекты для передачи между людьми хранились только в виде своих репрезентаций (видимого изображения), т.е. важная информация о структуре самого объекта терялась.
Постепенно эти форматы становятся стандартами, используемые для передачи такого рода информации между людьми и компьютерами. Таким образом, можно сказать, что у данного языка разметки богатая предистория, и начинается она с момента, когда на компьютере был набран первый научный документ.
Назначение данного формата — обеспечить разработчиков и пользователей знаний стандартом со следующими свойствами:
Стандарт — это общий для всех формат ( или способ, стиль) хранения знаний в электронном виде. Он позволит объединить существующие в Internet ресурсы и эффективно дополнять их новыми.
Язык разметки KML разработан посредством Расширяемого Языка Разметки - XML. Описание Расширяемого Языка Разметки XML 1.0 можно найти на сайтах www.w3.org, www.xml.com, или www.xml.org.
Язык KML ориентирован на структурирование содержания и создание связей различного характера между элементами, а также на графическое представление структур и поддержку версионности.
Структурирование. Это значит, что разработчикам нужно будет маркапировать логическую структуру создаваемого ими учебного/научного материала и не заботиться об его отображении. Надлежащим образом маркапированный, то есть грамотно оформленный KML документ, впоследствии может быть использован для получения визуальной версии хранящегося в нем материала, например HTML или PostScript версии, оформленной произвольным стилем.
Связывание элементов. Снабжение каждого элемента знаний богатым набором связей - очень важный момент. Дело в том, что в гигантских базах данных, содержащих многотиповую информацию, существенную роль начинают играть связи. Можно сказать, что существенная и очень важная часть информации приходится на информацию о связях элементов. Поэтому в язык KML включены гибкие и разнообразные средства связывания - XResource и XLink - стандарт, который в данный момент находится в стадии разработки группой W3.org. Следует сразу же отметить важнейшие свойства связей - они могут быть многозначными, разнонаправленными и недетерминированными.
KML позволяет вести эффективный поиск необходимой информации и делать сложные запросы, результатом которых является связанный ответ реферативного характера.
Графическое представление. Язык KML уже содержит в себе поддержку графического представления знаний в виде графов и алгоритмов.
Кроме того KML
Обмен знаниями происходит не сам по себе, а по специальным сценариям. Эти сценарии называются процессами. Выделяются три процесса: Процесс Публикации, Процесс Обработки Запроса и Процесс Представления. Процесс Публикации происходит, когда разработчик выкладывает материал, подготовленный им в виде набора Юнитов, для общего доступа в Базу Знаний. Процесс Обработки Запроса — когда пользователь пытается найти интересующую его информацию в Базе Знаний. Процесс Представления информации — это преобразование материала в формате KML в любую отображаемую или печатную форму.
Все процессы каким-либо образом влияют на формат представления, каждый процесс имеет свои особенности, связанные с форматом. Эти особенности далее в тексте мы будем отражать в специальных абзацах: Публикация:, Запрос: и Представление: — для процессов Публикации, Запроса и Представления информаци соответственно.
Под Знанием здесь понимается методический материал самого различного рода (учебные курсы, задачники, лекции), серьезные научные работы (академические здания, статьи, доклады, дипломы), и, в принципе, произвольный материал, относящийся к образованию, науке или истории науки. Знания разделены на Области SCOPES, возможно перекрывающиеся, единым иерархическим классификатором.
База Знаний — XML база данных, в которой хранятся документы в формате KML. База Знаний организована в виде следующей иерархической структуры:
| PROJECTS | Проекты |
| <ID> | Имя проекта |
| TITLE | Языковые реализации названия проекта |
| <Язык> | |
| DESCRIPTION | Языковые реализации описания проекта |
| <Язык> | |
| AUTHORS | Список Авторов проекта |
| SCOPES | Список Областей знаний проекта |
| UNITS | |
| <ID> | Идентификатор Юнита |
| UTYPE | Тип Юнита |
| CONTENTTYPE | (Mime)-тип содержимого Юнита |
| VERSIONS | |
| <ID> | Номер версии |
| BASE | номер базовой версии |
| AUTHORS | Авторы версии и языковой реализации |
| SCOPES | Области знаний версии Юнита |
| TITLE | Языковые реализации названия Юнита |
| <Язык> | |
| KEYWORDS | ключевые слова |
| <Язык> | языковые реализации списка ключевых слов |
| CONTENT | Языковые реализации содержимого (Тела) Юнита |
| <Язык> | |
| LINKS | Описание связей |
| <ID> | Идентификатор связи |
| CLASS | Имя класса связи |
| ROLE | Имя роли - отношения конца связи к началу |
| FROM | Идентификатор Юнита - начала связи |
| TO | Идентификатор Юнита - конца связи |
| CONTEXT | Идентификатор текущего Юнита (контекста связи) |
| TITLE | Языковые реализации заголовка связи |
| <Язык> | |
| CONTENT | Языковые реализации содержимого связи |
| <Язык> | |
| SCOPES | Общий классификатор областей знаний |
| <ID> | Идентификатор области знаний |
| TITLE | Переводы классификатора на различные языки |
| <Язык> | Перевод |
| AUTHORS | Список авторов и информация о них |
| <ID> | Уникальное имя автора |
| TITLE | Языковые реализации Имени Автора |
| <Язык> | |
| CONTACT | контактная информация |
Следует обратить внимание на важную особенность. Список Областей Знаний (SCOPES) для Юнита не зависит от его языковой реализации, а только от версии Юнита. Связи Юнита также являются свойством версии Юнита и могут иметь различные языковые реализации.
Юнит (Unit) - единица данных в Базе Знаний (элементарный объект), имеющая ряд атрибутов и связанная с другими единицами. Примером Юнита может служить абзац текста, высказывание, или даже просто предложение, а также, изображение, формула, график, таблица — все это примеры Юнитов. Т.е. Юнит в общем случае — это некая неделимая единица информации, на которую мжно сослаться в контексте Базы Знаний.
Юнит может иметь различные Версии, а каждая Версия, в свою очередь, -- набор Языковых реализаций Названия Содержимого Юнита.
Содержимое (Тело) Юнита может представлять собой один параграф, один абзац, просто текст, содержащий законченную мысль или идею. В Тело Юнита включаются различные другие элементы - картинки, формулы, расширенные ссылки (KLINK) и др. Тело Юнита структурируется посредством Языка Разметки Тела - Unit Body Markup Languadge.
В Заголовке Юнита также описываются Связи между Юнитами. Любая пара Юнитов, в том числе такая, которая не содержит текущий Юнит, может быть связана посредством ссылки (Следует различать понятия связи и ссылки. Связь, по отношению к ссылке обладает более богатой семантикой, в то время как ссылка — является просто указателем на какой-либо Юнит.). Все связи группируются в элементы LNGROUP с заданными атрибутами class Существуют несколько классов связей:
Все эти ссылки описываются посредством элементов XLINK и LNGROUP. Они позволяют создавать многозначные и недетерминированные ссылки, указывать тип связи, а также придавать связи семантическое значение. Это многофункциональные и гибкие средства для связывания объектов.
Запрос:
Ссылки классов bg и seq используются при формировании разультатов запросов. Юниты, связанные ссылками данных классов сортируются топологически по этим ссылкам таким образом, чтобы не нарушалась последовательность изложения (seq), и обязательный для изучения матерал для какого-либо Юнита шел перед этим Юнитом (bg).
Проект (PROJECT) - набор Юнитов, содержательно связанных, и объединенных одной темой. Это может быть законченный курс лекций, подробное рассмотрение некоторого вопроса, или обзор истории научной мысли, связанной с какой-либо проблемой. На то, что именно содержит данный Проект (или его часть) указывает атрибут utype (unit type) - тип содержания. Проект может быть связан с различными областями знаний (SCOPES), иметь список авторов AUTHORS, указание базовой сложности COMPLEXITY, а также иметь ссылку на корневой Юнит.
Запрос:
Результатом процесса запроса могут быть как Юниты, так и Проекты, а также и те, и другие одновременно. Публикация:
Прежде чем опубликовать Юниты, необходимо опубликовать проект, их содержащий.
Перейдем к подробному рассмотрению KML элементов.
Элемент AUTHOR обозначает Автора или ссылку на него.
<!ELEMENT AUTHOR (TITLE* CONTACT?)>
<!ATTLIST AUTHOR
id ID #IMPLIED
idref IDREF #IMPLIED>
<!ELEMENT TITLE (#PCDATA)>
<!ATTLIST TITLE
lang CDATA #IMPLIED>
<!ELEMENT CONTACT (#PCDATA)>
В обычных коммуникационных процессах используется только ссылка на Автора и указывается только атрибут idref, а сам элемент остается пустым. Если требуется запросить или опубликовать информацию об Авторе, то указывается атрибут id и дополнительно - подэлементы TITLE и CONTACT.
SCOPE - это ссылка или описание научной дисциплины или области знаний.
<!ELEMENT SCOPE (TITLE* DESCRIPTION*)>
<!ATTLIST SCOPE
id ID #IMPLIED
idref IDREF #IMPLIED>
<!ELEMENT DESCRIPTION (#PCDATA)>
<!ATTLIST TITLE
lang CDATA #IMPLIED>
<SCOPE id="mathematics/probability_theory">
<TITLE lang="ru">Математика/Теория вероятностей</TITLE>
</SCOPE>
<SCOPE id="physics/electricity_and_magnetism">
<TITLE labg="ru">Физика/Электричество и магнетизм</TITLE>
</SCOPE>
<SCOPE id="mathematics/differential_geometry">
<TITLE lang="ru">Математика/Дифференциальная геометрия</TITLE>
</SCOPE>
<SCOPE id="comp/crypto">
<TITLE>Computer Sience/Криптография</TITLE>
</SCOPE>
Идентификатор SCOPE состоит из нескольких частей, разделенных стандартным разделитетем '/' и представляет собой указатель на место в иерархическом классификаторе областей знений.
Элемент COMPLEXITY должен характеризовать сложность материала. На настоящий момент строгого определения содержимого этого элемента нет. Это просто произвольный текст.
<!ELEMENT COMPLEXITY (#PCDATA)>
<!ATTLIST COMPLEXITY
ctype PCDATA #IMPLIED>
Для того чтобы данный элемент активно использовался при обработке запросов, необходимо, чтобы он имел четкий формат. Мы можем предложить несколько классификаций по сложности:
Сложность текста - относительный параметр, и невозможно однозначно линейно упорядочить все знания и весь существующий материал по сложности. Под относительностью здесь можно понимать, во первых, зависимость от конкретного человека, объема его знаний и специализации. А во-вторых, от даты создания материала. Поэтому объективнее всего в параметре сложность указывать название института, имя преподавателя, курс, факультет и дату, когда данный курс читался, или указывать знания необходимые для понимания данного ЮНИТА. Но вся эта информация фактически уже содержится в ЮНИТЕ. Предлагается ввести несколько перекрестных классификаций, отражаемых в атрибуте ctype.
Элемент Проекта является родительским элементом, включающим в себя языковые реализации названия и описания Проекта, дополнительные атрибуты и список Юнитов Проекта.
<!ELEMENT PROJECT (TITLE* DESCRIPTION* AUTHOR* SCOPE* COMPLEXITY? UNIT*)>
<!ATTLIST PROJECT
id ID #REQUIRED
action (set|none|delete) #FIXED "none">
Элементы TITLE и DESCIPRION — это языковые реализации названия и описания Проекта соотвественно.
Элементы AUTHOR и SCOPE используются в качестве ссылок на существующих Авторов и Области Знаний.
Публикация
Атрибут action имеет смысл только в процессе Публикации, его значение определят, что нужно делать с текщим Проектом, опубликовать (set), удалить (delete) или пропустить (none).
Основным элементом Базы Знаний является минимальная, логически законченная единица текста UNIT. Она состоит из списка версий. Также, каждый UNIT имеет обязательный идентификатор id, уникальный в рамках Проекта, которому принадлежит данный Юнит. А также содержательный тип Юнита utype, и тип медиа-данных Юнита content-type.
<!ELEMENT UNIT (VERSION*)>
<!ATTLIST UNIT
id ID #REQUIRED
utype CDATA #IMPLIED
content-type CDATA #IMPLIED>
Атрибут utype указывает на тип содержания ЮНИТА. Обычно ЮНИТЫ одного проекта имеют один и от же тип, но это не обязательно. Также не обязательно, чтобы проект относился к одной области знаний (SCOPE). В настоящий момент выделены четыре основных типа: это
Публикация
Во время Публикации, если Юнит с заданным атрибутом id в текущем Проекте уже опубликован, то атрибуты utype и сontent-type игнорируются, поскольку являются особенностями Юнита как части Проекта и не могут менятся от версии к версии или в зависимости от языка (последняя зависимость может иметь место для атрибута сontent-type, но это — предмет для обсуждения).
Запрос
Сослаться на Юнит можно только используя имя Проекта project, идентификатор id и, возможно, номер версии version. Язык Юнита будет выбран автоматически, в зависимости от предпочтений пользователя, исходя из существующих языковых реализаций Юнита. В результате запроса, возвращаются элементы UNIT, полностью содеражщие весь набор атрибутов и весь набор SCOPE, вне зависимости от того, первым ли был опубликован данный Юнит или нет.
В элементе VERSION содержится информация о Заголовке Юнита и его Авторах, Связях и Ключевых словах Таким образом, VERSION состоит из следующих элементов:
<!ELEMENT VERSION (TITLE* KEYWORD* AUTHOR* SCOPE* COMPLEXITY? CONTENT* LINKS?)>
<!ATTLIST VERSION
id ID #REQUIRED
base IDREF #IMPLIED
<!ELEMENT KEYWORD (#PCDATA)>
<!ATTLIST KEYWORD
lang CDATA #IMPLIED>
<!ELEMENT CONTENT ANY+>
<!ATTLIST CONTENT
lang CDATA #IMPLIED>
Версия Юнита идентифицируется номером в атрибуте id. Необязятельный атрибут base указывает на номер базовой версии, на основе которой построено содержимое текущей версии.
Элементы TITLE, KEYWORD, CONTENT — соотвтетсвенно языковые реализации Названия Юнита, Ключевых слов и Содержимого Юнита.
<SCOPE id="mathematics/analytic_geometry">
<TITLE lang="ru">Математика/Аналитическая Геометрия</TITLE>
</SCOPE>
<AUTHOR id="vichehlov">
<TITLE>Чехлов Валерий Иванович</TITLE>
</AUTHOR>
<PROJECT id="analytic_geometry_cource">
<TITLE lang="ru">Курс Лекций по Аналитической Геометрии</TITLE>
<AUTHOR idref="vichehlov"/>
<UNIT id="vector_examples" utype="theory"
content-type="text/tex">
<VERSION id="1.0">
<SCOPE idref="mathematics/analytic_geometry"/>
<TITLE lang="ru">Примеры векторных пространств<TITLE>
<COMPLEXITY ctype="ed">1st course </COMPLEXITY>
<CONTENT lang="ru">
...
</CONTENT>
</VERSION>
</UNIT>
</PROJECT>
<SCOPE id="physics/thermodynamics">
<TITLE lang="ru">Физика/Термодинамика</TITLE>
</SCOPE>
<AUTHOR id="iiivanov">
<TITLE lang="ru">Иванов Иван Иванович</TITLE>
</AUTHOR>
<PROJECT id="problems_on_thermodynamics">
<TITLE lang="ru">Термодинамика в задачах</PROJECT>
<SCOPE idref="physics/thermodynamics"/>
<AUTHOR idref="iiivanov"/>
<UNIT id="vdv-related-problems" utype="problem">
<VERSION id="1.0">
<TITLE lang="ru">Задачи на тему Газ Ван дер Ваальса</TITLE>
<COMPLEXITY ctype="ed">2nd course </COMPLEXITY>
</VERSION>
</UNIT>
</PROJECT>
<AUTHOR id="vvprasolov">
<TITLE lang="ru">Прасолов В.В.</TITLE>
</AUTHOR>
<SCOPE id="mathematics/algebra">
<TITLE lang="ru">Математика/Алгебра</TITLE>
<SCOPE>
<PROJECT id="...">
...
<UNIT id="chebyshev-polynome" utype="story">
<VERSION id="0.1">
<TITLE lang="ru">Полиномы Чебышева</TITLE>
<SCOPE idref="mathematics/algebra"/>
<AUTHOR idref="vvprasolov"/>
<COMPLEXITY>common</COMPLEXITY>
</VERSION>
</UNIT>
</PROJECT>
KML содержит достаточно выразительные средства для связывания Юнитов.
В элементе VERSION был упомянут некоторый элемент LINKS, определение которого мы сейчас раскроем.
<!ELEMENT LINKS (XLINK|LNGROUP)+>
Этот элемент не имеет атрибутов, он только лишь является группирующим для элементов XLINK и LNGROUP.
Контекст связи
Мы уже говорили о том, что Связь между двумя юнитами Может быть установлена вне этих Юнитов — в третьем Юните. Юнит, который устанавливает связь между Юнитами назвается Контекстом связи
Sequence Links (Связи последовательности изложения) — обычные связи следующего и предыдущего Юнитов.
Это самые простые связи, с помощью которых фиксируется оптимальная последовательность изложения внутри Проекта. Впрочем, можно устанавливать и межпроектную линию изложения. Одинаковость области знаний также не обязательна. Связи последовательности изложения предназначены для выстраивания цепочек Юнитов, но в принципе, можно создавать деревья, циклы и любые другие графы. Это не приветствуется, так как, в конечном итоге, процесс поглощения информации линеен, то есть однопоточен, и лишние разветвления могут внести путаницу.
Конечно, книжки необязательно читать, от начала до конца, не пропуская ни одной странички, а иногда даже вредно. Более того, полезно иметь под рукой несколько книжек, чтобы можно было выбирать подходящий уровень и стиль изложения. Средства для осуществления такого гибкого выбора предоставляет элемент LNGROUP.
<!ELEMENT LNGROUP (LNGROUP|XLINK)+>
<!ATTLIST LNGROUP
label CDATA #IMPLIED
method (any | all) "any" #REQUIRED
class (rel | seq | alt | bg) "rel" #REQUIRED
role CDATA #IMPLIED>
<!ELEMENT XLINK (TITLE* CONTENT*)>
<!ATTLIST XLINK
label NMTOKEN #IMPLIED
unitref CDATA #IMPLIED
from CDATA #IMPLIED
role CDATA #IMPLIED
query CDATA #IMPLIED
alt CDATA #IMPLIED />
Атрибут label используется в качестве идентификатора связи для ссылки на нее из Тела Юнита.
В атрибуте method элемента LNGROUP указывается тип объединения ссылок. Значение "any" указывает на то, что можно выбрать один из предлагаемых вариантов - достаточно активизировать одну из ссылок, "all" - советуется рассмотреть все варианты. Это удобно, в случае когда один и тот же материал излагается с точки зрения разных подходов или просто дублируется на разных серверах.
Дополнительно, элемент XLINK Может содержать в себе языковые реализации описания связи (в элементах TITLE и CONTENT).
Связи последовательности изложения в KML документе могут выглядеть, например, так:
<LNGROUP class="seq" role="next" method="any">
<XLINK label="fw" unitref="book1.9">
<TITLE lang="ru">Обратная матрица</TITLE>
</XLINK>
<XLINK label="fw_advanced"
unitref="book1.9a">
<TITLE lang="ru">Дополнение: Кососимметричные формы
</XLINK>
</LNGROUP>
<LNGROUP class="seq" role="back">
<XLINK label="back"
unitref="book1.7">
<TITLE labg="ru">Детерминант Матрицы</TITLE>
</XLINK>
</LNGROUP>
С помощью LNGROUP можно строить сложенные вложенные конструкции из состоящие из других элементов LNGROUP и XLINK.
ХLINK и LNGROUP обладают дополнительным атрибутом label. Это уникальный идентификатор связи, который позволяет коротко в тексте ссылаться на нее - аналог элемента библиографии.
В атрибуте role элементов LNGROUP и XLINK заложена информация о роли связи. Это функциональное или семантическое значение данного элементарного ресурса. Он может принимать значения такого сорта: ``является обобщением'', ``является продолжением идеи'', ``является словарем для'', ``содержит подробные доказательства'' и др.
Вообще, для различныx классов связей существует различный набор возможных ролей role. Для связей класса seq, аттрибут role может принимать значения: next, prev, parent, child.
В случае, когда href опущен, обязательно должен присутствовать атрибут query, который содержит информацию для запроса поисковой системы. Значение этого параметра также должно быть зафиксированным. Синтаксис запроса должен позволять выделять в строке запроса категорию, расширенную строку поиска, требуемую точность соответствия и различные ограничения на результат поиска. Разбор этого вопроса оставлен на следующие версии KML.
Таким образом, посредством элементов XLINK LNGROUP и KLINK (последние будут встречаться в ТЕЛЕ ЮНИТА) могут быть реализованы многозначные и недетерминированные связи.
Related & BackGround Links предназначены для связывания Юнита с другими, содержательно связанными с ним знаниями.
В KML документе Related Links могут быть оформлены следующим образом.
<LNGROUP class="rel">
<XLINK label="prasolov" role="additional"
href="http:/www.xxx.xx/XXX/index.xml">
<TITLE lang="ru">Рассказы о Многочленах Прасолова В.В.</TITLE>
</XLINK>
<XLINK label="cardano"
query="(корни кубического уравнения) or (Кардано)">
<TITLE lang="ru">Информация о решении кубических уравнений</TITLE>
</XLINK>
<XLINK label="nikolsky">
<TITLE lang="ru">Комплексные числа в курсе Никольского</TITLE>
</XLINK>
</LNGROUP>
Рассмотрим как будет выглядеть ссылка на описанный выше ресурс внутри ТЕЛА ЮНИТА
... Решая <KLINK idref="3eq">кубическое уравнение</KLINK> получаем что давление в баллоне равно 3P/4 ...
Описание этой связи должно находиться в списке связей текущей версии Юнита в элементе XLINK или LNGROUP с атрибутом label равным 3eq. Оно представляет собой некоторый набор связей с указанием их роли и, возможно, значением связи. Если точной ссылки нет (атрибут href опущен ), то необходимо указать некоторое символьное выражение в атрибуте query, которое будет интерпретироваться как запрос на поиск в Базе Знаний. Конечно, при отработке этой ссылки может использоваться не только указанное в query регулярное выражение, но и другая информация указанная в элементе XLINK, а возможно, и весь ЮНИТ. Это зависит от приложения, использующего Базу Знаний.
Следующие элементарные средства для связывания ЮНИТОВ - элементы типа LOOKFOR и FINDME.
Элемент LOOKFOR, по сути, является KLINK с неопределенным атрибутом href и атрибутом query равным заключенному внутрь этого элемента текста. Это позволит избежать поворений. FINDME - элемент, который указывает поисковым системам, что следует индексировать в данном тексте. Синоним FINDME - это элемент KEYWORD. Только последний вырван из текста, и должен помещаться вначале элемента BODY. Слова, выделенные как FINDME, попадают в индекс документа.
<!ELEMENT FINDME ANY+> <!ELEMENT LOOKFOR ANY+> <!ELEMENT KEYWORD ANY+>
Разработка BodyML - особенно важный этап. Он определяет средства описания ЗНАНИЙ, то есть информационного содержания ЮНИТА. Здесь нужно определиться, какие структуры являются наиболее стандартными, общеупотребительными, полезными, и достаточно универсальными. Кроме того, необходимо реализовать расширяемость формата. И здесь мы делаем первый важный шаг - включаем в BodyML язык HTML. Все средства, доступные в HTML, считаются доступными внутри BodyML, конечно с некоторыми оговорками. Дальнейшее изложение поделено на две части - ``Средства структурирования Проекта'' и ``Расширяемость BodyML''.
Большинство текстов относящихся к научно-учебной литературе состоят из следующих частей:
При этом в текст внутри каждой части могут содержаться следующие типичные конструкции:
В перспективе язык разметки KML будет содержать средства для выделения данных структурных элементов а также связывания их между собой.
В KML документ можно вставлять элемент произвольного формата - в частности элементы MathML, TEX/LATEXдокументы, документы PostScript, PDF и др. Бывает два типа вставок : вложенные - inline и внешние - external. Для того, чтобы XML документ оставался синтаксически корректным, все inline вставки должны представлять собой объекты, написанный на XML-языках, таких как CML, SVG и MathML.
Copyright © 1993, 1994, 1995, 1996, Nikos Drakos, Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999, Ross Moore, Mathematics Department, Macquarie University, Sydney.
The command line arguments were: latex2html kml.tex
© AIKernel 2003-2010
24.12.2008 - 21.10.2010
1/3