суббота, 28 февраля 2009 г.

Аннотирование семантических данных

перевод фрагмента статьи Semantic annotation for knowledge management: Requirements and a survey of the state of the art

Требования

Разработка модели Управления Знаниями ориентированная на документы, потребовала от нас формулировки требований к системам аннотации семантических данных. Они совпадают в какой-то степени с требованиями изложенных Handschuh и др.. [15], но существуют также различия. Например, мы не касались таких проблем, как эффективность и правильные ссылки, хотя мы и признаем, что это важно. Вместо этого, мы рассмотрели задачу с четырех точек зрения: онтологий, документов, аннотаций, которые связывают онтологии и документы, а также пользователей системы. Все эти точки зрения предполагают одно или несколько требований, каждое из которых, как правило, объединяет несколько связанных потребностей. Например, с точки зрения онтологий появляется требование поддержки инструментами множества меняющихся онтологий, а с точки зрения документов мы видим необходимость поддержки повторного использования и контроля версий документов.

[Ниже перечислены семь требований к инструментам анотации - прим.пер.]

1. Использование стандартных форматов

Использование стандартных форматов предпочтительнее, где это возможно, поскольку затраты на маркировку ресурсов значительны - стандартизация создаст прочную основу для будущего, так-так новые инструменты, услуги и т.д., которые не были предусмотрены при первоначальной семантической аннотации, смогут легко использовать такие ресурсы. Соответствие стандартам, также освобождает компании от ограничений связанных с использованием лицензионных форматов при выборе программного обеспечения по управлению знаниями Эти преимущества могут быть отнесены к системам в целом.
В системах аннотации, в частности, стандартные форматы могут стать тем связующим механизмом, который позволит обеспечить совместный доступ к распределенным ресурсам, а так же объединит усилия пользователей и организации в предоставлении доступа к аннотациям. Активность W3C в развитии и поощрении международных стандартов в области Семантического Веба, убеждает нас в том, что в области управления знаниями стоит следовать этим путем. Два вида стандартов являются обязательными, стандарты для описания онтологий,
такие как OWL и стандарты аннотации такие как W3C схема аннотации RDF .

2. Ориентированный на пользователя / совместную работу дизайн

Аннотирование может стать узким местом, если оно выполняется специально-обученными людьми и занимает много их времени. Хорошей практикой будет иметь единый интерфейс ввода данных, например когда инструмент позволяющий пользователю аннотировать документы интегрирован с инструментами для их чтения, создания, редактирования, и распространения.
Дизайн системы, так же, нуждается в облегчении взаимодействия между пользователями, что является ключевым аспектом обработки знаний экспертами в различных областях, способствуя повторному использования "умных" документов. Мы уже определили стандартные форматы, как предпосылку для обмена аннотациями.
Другие вопросы сотрудничества включают реализацию системы контроля над тем, что разделять и с кем. Например, в медицинском контексте, врачи могли бы обмениваться всей информацией о пациентах между собой, но предоставлять только общую, обезличенную информацию в отдел планирования. Это подводит нас к вопросам, связанным с доверием, источниками данных и правами доступа к ним. Внутренние сети обеспечивают более контролируемую среду для отслеживания источников аннотаций, чем дикий Веб, но и в этом случае политика доступа к данным является важным вопросом для организаций, которые неизбежно касаются вопросов конфиденциальности данных клиентов и сотрудников.

3. Поддержка онтологий (множества онтологий и их развития)

В дополнение к поддержке соответствующих форматов онтологий, средства аннотации должны быть в состоянии поддерживать большое количество онтологий. Например, в медицинском контексте, это может быть одна онтология для общих метаданные о пациенте и несколько других технических онтологиях, связанных с диагностикой и лечением. Либо онтологии должны быть объединены либо аннотации должны четко декларировать, на какие онтологии они ссылаются.
Кроме того, система должна уметь обрабатывать изменения, внесенные в онтологии с течением времени, как, например, включение новых классов или изменение существующих. В этом случае, проблема заключается в обеспечении соответствия между онтологиями и аннотациями в плане изменения онтологий.
Один из важных аспектов проектирования среды аннотации, определить, как изменения должны быть отражены в базе знаний аннотированных документов, и не появляется ли в измененных онтологиях конфликтов с существующими аннотациями.

4. Поддержка разнообразных форматов документов

Стандарты Семантического Веб для аннотаций, как правило, предполагают, что аннотируемые документы представлены в наиболее часто используемых форматах веб-документов, таких как HTML или XML. Например, Annotea для определения местоположения аннотации в документе использует XPointers. Такой подход имеет ограниченную полезность для управления знаниями.
Документы могут иметь самые разные форматы, включая файлы текстовых процессоров, электронные таблицы, графические файлы и сложные смеси различных форматов. И хотя это рождает техническую проблему, требующую большого количества исследований, возможность использования разнообразных форматов документов является необходимым условием для массового использования аннотаций на практике.

5. Отселживание изменений в документ ( связь документа и аннотации )

Случается онтологии меняются, но документы меняются гораздо чаще. Примером могут служить спецификации консорциума W3, которые проходят через множество ревизий. Требование 3 сосредотачивается на проблеме сохранения связанности онтологий и аннотаций. Данное требование, касается поддержания связи аннотации с текстом документа, т.е. обслуживания указателей из аннотации на информацию в тексте.
Вопрос - "Что должно происходит с аннотацией документа, когда он изменяется?", имеет как технические стороны, так и стороны касающиеся логики самого приложения. Если якорь к аннотации в общедоступном документе удаляется кем-то, при редактировании, надо ли информировать автора этого документа, чтобы он мог повторно поставить якорь, а быть может и удалить соответствующую аннотацию, или документ не может быть изменен ни кем кроме автора? Надо ли, в общем случае, приводить аннотации в соответствие с новым вариантом документа, или же версии аннотации необходимо поддерживать параллельно с версиями документа? Например, если договор изменяется под нового клиента, аннотации указывающие на правовые онтологии должны быть сохранены, но аннотации, в которых говорится о предыдущих клиентах, надо удалить. Как может быть достигнуто такое выборочное изменение аннотаций?
Инструмент аннотации должен уметь помогать пользователю грамотно изменять необходимые аннотации при изменении документа.

6. Хранение аннотаций

Модель Семантического Веб-а предполагает, что аннотации будут храниться отдельно от первоначального документа, в то время как модель "текстового процессора" предполагает, что комментарии, хранятся в качестве неотъемлемой часть документа, и могут быть показаны или скрыты в зависимости от предпочтений пользователя. Модель Семантического Веб-а, в которой содержание отделено от семантики, особенно хорошо работает в Веб, где авторы аннотаций не обязательно имеют контроль над документами, которые они аннотировали. Этот аспект следует учитывать при работе с документами некоторых форматов, которые могут уже содержать в себе аннотации.

7. Автоматизация

Другим аспектом облегчения работы с инструментами аннотации является создание условий для автоматической разметки наборов документов, в целях облегчения аннотации больших собраний документов. Чтобы добиться этого, большое значение имеет интеграция технологий добычи знаний в среду аннотации. Это позволяет автоматически идентифицировать сущности, которые являются экземплярами классов и отношения между классами. Надо отметит, что автоматические инструменты могут помочь эффективно справится с аннотированием даже неподготовленному пользователю, для этого могут использоваться, например методы обработки естественного языка (NLP).

понедельник, 9 февраля 2009 г.

Атрибут xmlns

При попытке выполнить следующий код:

XmlWriter output;
output.WriteStartElement("sparql");
output.WriteAttributeString("xmlns", "http://www.w3.org/2005/sparql-results#");

получаем исключение:

System.Xml.XmlException: Префикс "" не может быть переопределен с "" на "http://www.w3.org/2005/sparql-results#" внутри того же начального тега элемента.

Это все потому, что правильно делать вот так:

XmlWriter output;
output.WriteStartElement("sparql", "http://www.w3.org/2005/sparql-results#");

Ошибка была обнаружена в библиотеке SemWeb. Теперь в репозитории лежит уже исправленная версия.

воскресенье, 1 февраля 2009 г.

Вывод результата запроса в SemWeb

Для того чтобы сериализовать результаты выполнения запроса к RDF хранилищу в нужный нам формат в пространстве имен SemWeb.Query библиотеки SemWeb предусмотрен абстрактный класс QueryResultSync, а так же реализованы несколько его наследников:

  1. SparqlXmlQuerySynk, возвращающий результат запроса в виде XML документа содержащего исходный запрос и результат.
  2. HTMLQuerySink, - возвращает результат в виде таблицы HTML
  3. CSVQuerySynk - как нетрудно догадаться возвращает результат в строку разделенную запятыми
  4. QueryResultBuffer - класс который сохраняет результаты в три коллекции Variables, Bindings, и Coments

В случае если функциональности перечисленных классов нехватает для того чтобы возвратить результаты в необходимой нам форме, можно написать свою реализацию класса QueryResultSyn.


public abstract class QueryResultSink
{
public virtual void Init(Variable[] variables){}
public abstract bool Add(VariableBindings result);
public virtual void Finished() {}
public virtual void AddComments(string comments) {}
}


Примеры реализации лучше всего смотреть в коде самой библиотеки.

Cинглтон и многопоточность

Допустим у нас есть некий синглтон, который сохраняет свои состояния и работает как конечный автомат. И состояний этих у него много. Но допустим нам хотелось бы воспроизвести результаты его поведения в начальном состоянии. А как его в это состояние вернуть непонятно.
В этом случае иногда может выручить многопоточность.

public delegate string GetXmlFromTestedDelegate(Person[] persons);
private string GetXmlFromTested(Params[] params)
{
Singletone.Instance.Import(params);
return Singletone.GetAllInXml();
}

public void GetResultInXml()
{
GetXmlFromTestedDelegate asyncDelegate = GetXmlFromTested;
IAsyncResult result = asyncDelegate.BeginInvoke(Params, null, null);
while (!result.IsCompleted)
{
Thread.Sleep(50);
}
string xml = asyncDelegate.EndInvoke(result);

Assert.That(xml,Is.EqualTo(GetEtalonXML()));
}


А может и не выручить... Это я к чему собственно?? А к тому, что не всякая реализация синглтона действительно синглтон.