Как обрабатывать XML/RDF-синтаксис RDF с помощью XSLT читаем здесь:http://shcherbak.net/rdf_xslt_tech/
Категории:Semantic Web, Прикладные проекты и инициативы
7 комментария к этой записи
Оставить комментарий
Как обрабатывать XML/RDF-синтаксис RDF с помощью XSLT читаем здесь:http://shcherbak.net/rdf_xslt_tech/
7 комментария к этой записи
Оставить комментарий
почему не выкладываешь сорцы?
как на счёт клиентских трансформаций?
почему не owl? он вроде как призван заменить rdf.
почему трансформируешь в html а не в какой-нибудь svg?
насчет клиенских преобразований – скрипты можно использовать на клиенте… но нужны ли они на клиенте?
Если я буду подгружать в браузер файл онтологии размером в 1 мегабайт только для того, чтобы визуализировать два объекта, нужно ли клиентское преобразование?
ед-но, где я эти скрипты использую на клиенте, когда получаю ответ от RDF Store, тогда это эффективно…
почему не OWL?
Все просто… я это писал в 2004 году
тогда OWL только появлялся…
В основе OWL лежит RDF-граф, который обрабатывается почти так же, как я в статье написал…
Разница в том, что разметка стала более сложной и нужно писать дополнительные правила трансформации для обработки «отношений» OWL.
Вообще нет проблем, можно и OWL обрабатывать, включая версию Full.
Почему не SVG – я писал прежде всего «движок» для сайта на HTML…А для визуализации SVG нужно на клиенте ставить дополнительное ПО, что может ограничивать доступность сайта.
Для генерации SVG нужно использовать XSLT-fo, а среди бесплатно распространяемых FOP-процессоров был только Apache FOP более-менее справляющийся с задачами публикации. Хотя сейчас появилась новая версия, может быть она работает лучше… Будет свободная минута посмотрю на SVG, но насколько я помню идея преобразований RDF в SVG будет та же, шаблоны единственно нужно будет адаптировать для использования форматирующих объектов.
Исходники можно выложить конечно… вопрос только в том зачем это делать? Сайт доступен, скрипты просты…
Для просветительских целей мне кажется этого вполне достаточно(?)
Вот выложить движок ontolib.com это другое дело, там и скриптов обработки RDF намного больше и технология более интересна. Я в раздумье
В любом случае, не забывайте устанавливать рейтинги(оценки) для записей… По рейтингам я буду ориентироваться, по каким темам желательно добавлять материалы в блог.
Все в Ваших руках
клиентские трансформации – я имел ввиду xslt
> файл онтологии размером в 1 мегабайт
почему бы не разбить файл онтологии на несколько? меня не очень как-то прикалывает для получения какой-то информации через спаркл выкачивать мегабайты онтологий с каждого сайта.
> А для визуализации SVG нужно на клиенте ставить дополнительное ПО
вроде есть серверные утилиты для рендеринга свг в пнг. впрочем, если уж конвертить в картинку, то лучше заюзать http://www.graphviz.org/
Через sparql как раз и не нужно выкачивать мегабайты инфо, я говорю об онтологиях в виде файлов, обращаясь на сервер за которыми мы будем вынуждены передать всю онтологию на клиент для обработки. Хотя был проект SMART где делали серверную обработку онтологий…
Дробление онтологии на более мелкие файлы тоже не выход… потому что файловые операции ввода-вывода очень много забирают вычислительных ресурсов + это просто не удобно…
Лучше использовать RDF Store!
Если мы используем RDF Store, тогда на клиент не нужно передавать мегабайты информации… sparql запрос отфильтрует все лишнее и возвратит только ту информацию которая нужна (в виде, например, RDF)
Graphviz мне не понравился…для визуализации онтологии в protege мне больше нравиться использовать TGVIz
> и возвратит только ту информацию которая нужна (в виде, например, RDF)
которую клиент обработает через xslt в нужный ему вид.
собственно к чему я и вёл – на сервере информация хранится в базе данных из которой по запросу клиента формируется необходимая онтология.
у Graphviz и TGVIz совершенно различное предназначение. первая – для пакетной генерации изображений графов. вторая – для интерактивной визуализации онтологий.
Я противник хранения онтологий в реляционной базе данных.. Особенно на объектах с высоким уровнем детализации..
Это просто не эффективно… и заставляет нас выдумывать много лишних алгоритмов, чтобы онтологии естественным образом функционировали.
поэтому лучше на клиент отправлять фрагменты онтологий с RDF Store(или специализированной CУБД) в виде отдельных объектов или их экземпляров.
насчет GraphViz ничего сказать не могу, под Linux у меня он когда то не заработал…так я на него и не смотрю