Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 23
А чем и в чем у вас обрабатывается RDF? :) В отрыве от этого сложно сказать чем он лучше XML.
если бы оно у меня обрабатывалось, я бы не написал этот пост :)
Где-то в средине я упомянул что у меня работает нечто похожее по смыслу, но существенно отличное по синтаксису и форматам, скриптоподобие :)
Где-то в средине я упомянул что у меня работает нечто похожее по смыслу, но существенно отличное по синтаксису и форматам, скриптоподобие :)
Тут вопрос больше в том, нужна ли вам целостность данных. Если не нужна, то и XML можно потоком парсить.
нельзя... точнее смысла нет - описание каждого узла вложено внутрь тэга. Т.е. даже если иметь возможность разбора на лету, я получу всю информацию по элементу до того, как смогу сказать "ага, вот и сам элемент у нас получился". Я не могу оставить "на потом" самые тяжелые его части.
потом... парсить ХМЛ регулярными выражениями вместо DOM-a мне кажется некузявым. Или есть другие способы?
потом... парсить ХМЛ регулярными выражениями вместо DOM-a мне кажется некузявым. Или есть другие способы?
В RDF тоже вложено. Разницы по сути нет.
Это вы не улавливаете, я ошибаюсь, или у нас различная терминология?
Вложение в RDF логическое - да, есть. Но оно никак не связано с синтаксисом разметки.
Я могу указать атрибуты и свойства элемента, объявленного в начале документа, в средине (а в некоторых случаях вообще в другом документе) так, что это вообще не повлияет на выходную объектную модуль документа. Изменится только порядок ее генерации.
В XML, чтобы реализовать нечто подобное, потребуется дополнительно ухищряться, в связи с тем, что у элементов должен быть обязательный родительский элемент, описание элемента начинается с открывающего и заканчивается закрывающим тэгом - все что вне этой пары, к описанию элемента не имеет отношения (если искусственно вынести какие-то параметры в другой элемент, объединив их по айдишнику - это придется дополнительно обрабатывать).
ЗЫ я правильно понял что потоком вы предлагали парсить XML регулярными выражениями?
Вложение в RDF логическое - да, есть. Но оно никак не связано с синтаксисом разметки.
Я могу указать атрибуты и свойства элемента, объявленного в начале документа, в средине (а в некоторых случаях вообще в другом документе) так, что это вообще не повлияет на выходную объектную модуль документа. Изменится только порядок ее генерации.
В XML, чтобы реализовать нечто подобное, потребуется дополнительно ухищряться, в связи с тем, что у элементов должен быть обязательный родительский элемент, описание элемента начинается с открывающего и заканчивается закрывающим тэгом - все что вне этой пары, к описанию элемента не имеет отношения (если искусственно вынести какие-то параметры в другой элемент, объединив их по айдишнику - это придется дополнительно обрабатывать).
ЗЫ я правильно понял что потоком вы предлагали парсить XML регулярными выражениями?
Вложение в RDF логическое - да, есть. Но оно никак не связано с синтаксисом разметки.
Если оно было бы не связано, то как вы узнаете, что это элемент относится туда, а этот уже ко второму элементу?
Я могу указать атрибуты и свойства элемента, объявленного в начале документа, в средине (а в некоторых случаях вообще в другом документе) так, что это вообще не повлияет на выходную объектную модуль документа. Изменится только порядок ее генерации.
В XML тоже не повлияет.
В XML, чтобы реализовать нечто подобное, потребуется дополнительно ухищряться, в связи с тем, что у элементов должен быть обязательный родительский элемент, описание элемента начинается с открывающего и заканчивается закрывающим тэгом - все что вне этой пары, к описанию элемента не имеет отношения
Никто мне мне мешает объявлять несколько элементов с одинаковым ID. Такой XML является валидным и то как вы его обрабатывать будете это ваше личное дело.
если искусственно вынести какие-то параметры в другой элемент, объединив их по айдишнику - это придется дополнительно обрабатывать
В RDF тоже прийдется. Потому что в начале разметки указывается к какому элементу относятся свойства.
ЗЫ я правильно понял что потоком вы предлагали парсить XML регулярными выражениями?
К примеру, но есть и потоковые библиотеки, которые не строят полное дерево.
В RDF тоже прийдется. Потому что в начале разметки указывается к какому элементу относятся свойства.
В том-то вся и соль что не придется. Т.е. придется, конечно, но не пользователю. Эту работу берет на себя библиотека для обработки протокола.
В случае rdf значительно упрощается обработка связей - не надо доставать все по айдишникам из разных частей документа, как вы предлагаете, и склеивать их. К варианту с JSON это тоже относится.
Этот язык разметки изначально создавался чтобы описывать связи между различными объектами. И именно за счет этой его узкой по сравнению с xml нишей, который все-таки позиционируется, как язык для описания всего, работать с ним в условиях современного интернета получается удобнее.
В том-то вся и соль что не придется. Т.е. придется, конечно, но не пользователю. Эту работу берет на себя библиотека для обработки протокола.
Я вообще-то смотрю на RDF как на формат, в отрыве от библиотеки. К тому же такое действо является стандартным?
Этот язык разметки изначально создавался чтобы описывать связи между различными объектами. И именно за счет этой его узкой по сравнению с xml нишей, который все-таки позиционируется, как язык для описания всего, работать с ним в условиях современного интернета получается удобнее.
Обычно узкоспециализированные форматы в своей нише удобнее, но вот в не своей...
Это замечательная статья, но не забудьте добавить после аннотации.
XML и сам не люблю, но и эта нотация, по мне, — велосипед какой-то.
Что мешает с тем же успехом "наращивать" json - структуру?
Тупо, всё, что приходит, оформлять в отдельный объект, а потом сливать с основой.
{'element_1':{'ID':1, 'Xcoord':100, 'Ycoord':100}} +
{'element_1':{'Title': 'Первый элемент'}} ->
{'element_1':{'ID':1, 'Xcoord':100, 'Ycoord':100, 'Title': 'Первый элемент'}}
Что мешает с тем же успехом "наращивать" json - структуру?
Тупо, всё, что приходит, оформлять в отдельный объект, а потом сливать с основой.
{'element_1':{'ID':1, 'Xcoord':100, 'Ycoord':100}} +
{'element_1':{'Title': 'Первый элемент'}} ->
{'element_1':{'ID':1, 'Xcoord':100, 'Ycoord':100, 'Title': 'Первый элемент'}}
ничего не мешает. Более того, сейчас это единственный способ делать нечто подобное.
Только не в виде Json, а в виде JavaScript:
<script>
process({'element_1':{'ID':1, 'Xcoord':100, 'Ycoord':100}});
process({'element_1':{'Title': 'Первый элемент'}});
</script>
Только не в виде Json, а в виде JavaScript:
<script>
process({'element_1':{'ID':1, 'Xcoord':100, 'Ycoord':100}});
process({'element_1':{'Title': 'Первый элемент'}});
</script>
Я бы не стал так отделять json от конечного интерпретатора.
Иначе с тем же успехом можно про и 3 нотацию сказать, что мерджится она "не в виде 3 нотации, а в виде её парсера".
Иначе с тем же успехом можно про и 3 нотацию сказать, что мерджится она "не в виде 3 нотации, а в виде её парсера".
Соглашусь.
Сейчас у нас особо выбора нет, а данная заметка - не более чем предположение о развитии.
С моей точки зрения я отчетливо вижу, что третья нотация несет в себе очень удобные идеи с лаконичным синтаксисом. Моя точка зрения основывается на моем опыте работы с DOM, где я начал применять нечто подобное, не успев ознакомится еще с RDF. (у меня оно как раз на JSON ездит, к слову).
При этом, если учесть, что это только самый верхний уровень RDF, то я уже сейчас читаю его спецификацию в поиске новых идей, которые можно применить на практике.
Сейчас у нас особо выбора нет, а данная заметка - не более чем предположение о развитии.
С моей точки зрения я отчетливо вижу, что третья нотация несет в себе очень удобные идеи с лаконичным синтаксисом. Моя точка зрения основывается на моем опыте работы с DOM, где я начал применять нечто подобное, не успев ознакомится еще с RDF. (у меня оно как раз на JSON ездит, к слову).
При этом, если учесть, что это только самый верхний уровень RDF, то я уже сейчас читаю его спецификацию в поиске новых идей, которые можно применить на практике.
Вопрос у меня
Я пытаюсь смастерить онтологию для описания кактегорий товаров в веб магазине.
так вот, категории товаров идут как субклассы друг друга
Category_2_1 rdfs:subClassOf Category_2
а вот как мне корректно описать чтоу товаров в такой-то категории должны быть такие-то аттрибуты
например у товара в категории Обувь должны быть параметры Brand, Size, forSeason
а поотм еще и указать типа данных
например что Brad и forSeason- это литерал, а Size- число?
как это корректно изложить с помощью rdfs?
Я пытаюсь смастерить онтологию для описания кактегорий товаров в веб магазине.
так вот, категории товаров идут как субклассы друг друга
Category_2_1 rdfs:subClassOf Category_2
а вот как мне корректно описать чтоу товаров в такой-то категории должны быть такие-то аттрибуты
например у товара в категории Обувь должны быть параметры Brand, Size, forSeason
а поотм еще и указать типа данных
например что Brad и forSeason- это литерал, а Size- число?
как это корректно изложить с помощью rdfs?
Давно я не копал эту тему.
Насколько я понимаю, атрибуты описываются в описании классов по типу как тут:
www.w3.org/1999/02/22-rdf-syntax-ns
rdf.data-vocabulary.org/rdf.xml
Насколько я понимаю, атрибуты описываются в описании классов по типу как тут:
www.w3.org/1999/02/22-rdf-syntax-ns
rdf.data-vocabulary.org/rdf.xml
Единственно надо поискать где указаны такие параметры как сезон, размер и прочее. Быть может найдется даже описание таких параметров как строка или число
Допустим я опишу их как
Category2 rdfs:property Size
Category2 rdfs:property Brand
Category_2_1 rdfs:subClassOf Category_2
Category2_1 rdfs:property forSeason
а вот вопрос, по идее субкатегория должна наследовать атрибуты родительской категории
как спросить все атрибуты субкатегории так, чтобы они включали родительскую?
мутить какой-то sparql монструозный?
или вот скажем proteje/apache jena может родить класс какой-то жавовский на базе этого описания?
Не баловались таким?
Category2 rdfs:property Size
Category2 rdfs:property Brand
Category_2_1 rdfs:subClassOf Category_2
Category2_1 rdfs:property forSeason
а вот вопрос, по идее субкатегория должна наследовать атрибуты родительской категории
как спросить все атрибуты субкатегории так, чтобы они включали родительскую?
мутить какой-то sparql монструозный?
или вот скажем proteje/apache jena может родить класс какой-то жавовский на базе этого описания?
Не баловались таким?
Вообще без понятия. Ни до sparql ни до java я в итоге так и не добрался. У меня история с изучением rdf вылилась в рефакторинг ORMки в одном из проектов, на чем все и закончилось.
Как я понимаю общую философию — нельзя толком валидировать тип аттрибутов и вообще их наличие. То есть все описание — это лишь рекомендация, которому могут следовать агенты при парсинге и как-то интерпретировать это описание. И если один из источников данных упорно считает, что размер — это, к примеру, не размер, а число, то агенты будут считать так же. Если есть несколько источников, в которых разные типы, то они вполне могут интерпретировать это чуть ли не как «это скорее размер, чем число».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
XML, RDF и Я.