Comments 20
Спасибо большое за статью. Надеюсь вы на этом не остановитесь.
У меня никак не доходят руки разобраться в этих штуках, но очень интересно.
Если ваша карма подрастёт (чего вам желаю) советую переместить топик в блог семантическая сеть или web 3.0
Кстати, недавно появился перевод OWL2 на сайте SHCERBAK.NET
У меня никак не доходят руки разобраться в этих штуках, но очень интересно.
Если ваша карма подрастёт (чего вам желаю) советую переместить топик в блог семантическая сеть или web 3.0
Кстати, недавно появился перевод OWL2 на сайте SHCERBAK.NET
Да, ещё объясните пожалуйста «на пальцах» связь OWL и RDF если можно. Я понимаю что RDF — это тройка [объект, субъект, предикат], а OWL — язык описания онтологий. OWL может использовать словарь RDF — верно? Короче я немного тут запутался
RDF — это общее название всей модели, технологии представления данных в виде троек, или фактов, или более оффициально триплетов. Видов непосредcтвенно записи троек существует несколько: оригинальный RDF/XML, различные краткие нотации вроде N3 или просто изображение в виде графа. Так как помимо самих троек необходимо делать соглашения о смысле и взаимосвязях предикатов (типов ссылок или ребер графа от объекта к субъекту в тройке), то их описывают с помощью RDF Schema (RDFS).
Язык или скорее набор правил OWL предлагает запись всей онтологии с помощью классов, их отношений и конкретных объектов (индивидов). Опять же OWL можно выразить разными способами: тем же RDF/XML, OWL/XML, функциональным или «манчестерским» синтаксисом и т.д. Можно сказать, что OWL сомещает в себе запись троек RDF с их описанием RDFS на более высоком продуманном уровне, но и более сложном для освоения и понимания.
Если не прав, дополните пожалуйста.
Язык или скорее набор правил OWL предлагает запись всей онтологии с помощью классов, их отношений и конкретных объектов (индивидов). Опять же OWL можно выразить разными способами: тем же RDF/XML, OWL/XML, функциональным или «манчестерским» синтаксисом и т.д. Можно сказать, что OWL сомещает в себе запись троек RDF с их описанием RDFS на более высоком продуманном уровне, но и более сложном для освоения и понимания.
Если не прав, дополните пожалуйста.
Чего-то никто тут не пишет :(
Попробую сам. Как я понимаю у «Термина есть Описание», и мы хотим выразится таким образом чтобы описание принадлежало определённому автору. Некий автор добавил к Термину такое-то описание.
Получается что класс Термин имеет свойство Описание. Описание — это класс имеющий два свойства. Первое свойство Описания — ТекстОписания. Второе ПринадлежитАвтору. Автор в свою очередь — это класс являющийся подклассом класса Персона
P.S. Вы ничего не напутали в "#"? И, правильно ли я описал свойство hasText как DatatypeProperty?
Попробую сам. Как я понимаю у «Термина есть Описание», и мы хотим выразится таким образом чтобы описание принадлежало определённому автору. Некий автор добавил к Термину такое-то описание.
Получается что класс Термин имеет свойство Описание. Описание — это класс имеющий два свойства. Первое свойство Описания — ТекстОписания. Второе ПринадлежитАвтору. Автор в свою очередь — это класс являющийся подклассом класса Персона
// создаем классы <owl:Class rdf:ID="Termin"/> <owl:Class rdf:ID="Author"/> <owl:Class rdf:ID="Description"/> // задаём свойства <owl:ObjectProperty rdf:ID="includes"> // объект и субъект должны быть Терминами <rdfs:domain rdf:resource="#Termin"/> <rdfs:range rdf:resource="#Termin"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="hasDescription"> // объект: термин, субъект: описание <rdfs:domain rdf:resource="#Termin"/> <rdfs:range rdf:resource="#Description"/> </owl:ObjectProperty> < owl:ObjectProperty rdf:ID="hasAutor"> // объект: описание, субъект: автор <rdfs:domain rdf:resource="#Description"/> <rdfs:range rdf:resource="&xsd;string"/> </owl:ObjectProperty> <owl: owl:DatatypeProperty y rdf:ID="hasText"> // объект: описание, субъект: текст <rdfs:domain rdf:resource="#Description"/> <rdfs:range rdf:resource="&xsd;string"/> </owl:ObjectProperty>
P.S. Вы ничего не напутали в "#"? И, правильно ли я описал свойство hasText как DatatypeProperty?
ой, там в конце опечатка
<owl:DatatypeProperty rdf:ID="hasText">
Здесь пока может быть много чего напутано. Пытаемся разобраться.
Основная идея, которую мне хочется реализовать, это указание для каждой(!) тройки её автора. Создавать отдельное свойство hasAuthor для каждого вида предиката кажется не самым лучшим, хотя и работающим вариантом. Желательно найти более универсальный способ. Например навреное можно как-то создать иерархию всех свойств (предикатов) и вынести свойство «hasAuthor» на самый верх. Также можно конечно реализовывать это вне RDF вообще. Например просто хранить дополнительные данные об авторе каждой тройки в БД.
Различают два типа свойств:
1) свойства — значения, отношения между представителями классов и RDF-литералами или типами данных, определяемых XML Schema;
2) свойства-объекты, отношения между представителями двух классов.
Создаётся впечатление, что 1 задаётся с помощью ObjectProperty, а 2 — с помощью DatatypeProperty. Тогда если author у нас это просто внешний id, то hasAutor тоже будет DatatypeProperty.
С #, путями к файлам это отдельный вопрос. Хотелось бы получить подсказку по поводу как указывать пути к файлу словаря, чтобы обработчик понимал запросы с учетом его.
Основная идея, которую мне хочется реализовать, это указание для каждой(!) тройки её автора. Создавать отдельное свойство hasAuthor для каждого вида предиката кажется не самым лучшим, хотя и работающим вариантом. Желательно найти более универсальный способ. Например навреное можно как-то создать иерархию всех свойств (предикатов) и вынести свойство «hasAuthor» на самый верх. Также можно конечно реализовывать это вне RDF вообще. Например просто хранить дополнительные данные об авторе каждой тройки в БД.
Различают два типа свойств:
1) свойства — значения, отношения между представителями классов и RDF-литералами или типами данных, определяемых XML Schema;
2) свойства-объекты, отношения между представителями двух классов.
Создаётся впечатление, что 1 задаётся с помощью ObjectProperty, а 2 — с помощью DatatypeProperty. Тогда если author у нас это просто внешний id, то hasAutor тоже будет DatatypeProperty.
С #, путями к файлам это отдельный вопрос. Хотелось бы получить подсказку по поводу как указывать пути к файлу словаря, чтобы обработчик понимал запросы с учетом его.
Можно воспользоваться тем, что каждая тройка RDF сама по себе может быть представлена как объект rdf:Statement со свойствами rdf:subject, rdf:object и rdf:predicate; но тогда, при наивном хранении, в три раза возрастает объем представления одной и той же информации, т.к. каждую тройку надо держать в расписанном виде. Если движок дает возможность хранить мета-факты в более компактном виде (ссылкой на ID тройки в таблице или еще как-нибудь), то вполне даже вариант.
насчет автора для каждой тройки —
Я так понимаю речь идет представлении служебной информации в RDF, например, об авторе или создателе конкретной тройки RDF.
Потому что «вишня» как экземляр класса Ягода, у которой автор Вася Пупкин, как то глупо звучит. Значит, вероятно всего вы имеете ввиду служебную информации тогда вынос hasAuthor в корень иерархии в общем ничего не дает. Хотя например в редакторе онтологий Protege есть наборы служебных классов, выполняющие подобные функции, которые не отображаются в основном дереве представления RDF
C другой стороны, я не зря вспомнил, создателя. Просто если с филосовской точки зрения посмотреть — то все имеет своего создателя, например, даже мир имеет создателя.
В любом случае, конструкцию автор триплета лучше вынести во вне, до лучших времен — пока не введут синтаксическую конструкцию в OWL об авторстве.
кстати, под конец моего рассуждения, пришла мысль о том, что есть же Dublin Core, как расширение RDF
в котором рассматривается понятие авторства информации… А это значит, что информация из другого пространства имен, не будет связана по смыслу с «основными» знаниями о предметной области.
Так что все просто, ответ на ваш вопрос — введение Dublin Core в ваш проект ))))))))))))))
Я так понимаю речь идет представлении служебной информации в RDF, например, об авторе или создателе конкретной тройки RDF.
Потому что «вишня» как экземляр класса Ягода, у которой автор Вася Пупкин, как то глупо звучит. Значит, вероятно всего вы имеете ввиду служебную информации тогда вынос hasAuthor в корень иерархии в общем ничего не дает. Хотя например в редакторе онтологий Protege есть наборы служебных классов, выполняющие подобные функции, которые не отображаются в основном дереве представления RDF
C другой стороны, я не зря вспомнил, создателя. Просто если с филосовской точки зрения посмотреть — то все имеет своего создателя, например, даже мир имеет создателя.
В любом случае, конструкцию автор триплета лучше вынести во вне, до лучших времен — пока не введут синтаксическую конструкцию в OWL об авторстве.
кстати, под конец моего рассуждения, пришла мысль о том, что есть же Dublin Core, как расширение RDF
в котором рассматривается понятие авторства информации… А это значит, что информация из другого пространства имен, не будет связана по смыслу с «основными» знаниями о предметной области.
Так что все просто, ответ на ваш вопрос — введение Dublin Core в ваш проект ))))))))))))))
Автору статьи +1 к карме за то, что я не смог с ходу найти ответ на возникший вопрос о служебной информации в RDF
О, здорово. Автор shcherbak.net подтянулся :)
Даже целую статью написал.
А как насчёт ARC? Может, авторство триплета и можно описать с помощью Дублинского Ядра, но сможем мы потом использовать готовое хранилище и делать SPARQL запросы с учётом авторства? Например выбрать все утверждения автора об объектах определённого класса?
Даже целую статью написал.
А как насчёт ARC? Может, авторство триплета и можно описать с помощью Дублинского Ядра, но сможем мы потом использовать готовое хранилище и делать SPARQL запросы с учётом авторства? Например выбрать все утверждения автора об объектах определённого класса?
Пока что я не могу понять, как составлять запросы. Как в запросу указать что нужно использовать файл словаря, в котором прописаны отношения классов, в том числе словарь DC?
Проще всего вам посмотреть, как реализована поддержка Dublin Сore в Protege 4.0 и сделать по аналогии — а именно откройте файл OWL и посмотрите какие пространства имен вам надо добавить и какие свойства.
А насчет запросов — я не помню — можно ли в ARC использовать отличные пространства имен по умолчанию в запросах. хотя для sparql это не должно быть преградой. Скоро будет готов перевод по SPARQL, тогда и отвечу
А насчет запросов — я не помню — можно ли в ARC использовать отличные пространства имен по умолчанию в запросах. хотя для sparql это не должно быть преградой. Скоро будет готов перевод по SPARQL, тогда и отвечу
насчет ARC не знаю, но расширение RDF через DC это естественная операция, проблем с SPARQL не должно быть
Очень хорошая идея насчет Dublin Core
В protege 4.0 это, кстати, уже есть
Когда добавляешь Annotation, допустим, к классу, там есть Dublin Core Annotation URI's — «creator» или «contributor»
В protege 4.0 это, кстати, уже есть
Когда добавляешь Annotation, допустим, к классу, там есть Dublin Core Annotation URI's — «creator» или «contributor»
Продолжение в студию! :)
Sign up to leave a comment.
Простой RDF-репозиторий на PHP и MySQL для начинающих