GraphDb - Лучшие практики по созданию каталога товаров

Я новичок в GraphDB и пытаюсь понять, может ли он быть полезен для моих нужд.

Сценарий: я хочу иметь каталог товаров определенного типа (например, автомобилей, часов, компьютеров и т. Д.). Я хочу иметь базу данных, в которой я могу искать, сортировать, показывать связанные модели и т. Д.

Проблема: продукты поступают из разных источников (веб-майнинг, табличные данные и т. Д.). У каждого бренда есть свои «коллекции», и в каждой коллекции есть модели и вариации. Каждый бренд использует разные названия для характеристики модели. Так что я могу найти похожую характеристику с другим названием в моем каталоге.

Вопрос: я попытался прочитать варианты использования и нашел это (https://www.ontotext.com/knowledgehub/case-studies/edamam-mines-web-data/), что похоже на то, что я хочу реализовать.

Я пытаюсь создать онтологию для своего варианта использования, и мне было трудно понять, когда мне нужно использовать класс / сущность и при использовании отношения.

Я понял:

Model A
      Part A
           Characteristic A
           Characteristic B

Model B
      Part B
            Characteristic C

В этом случае, как лучше всего сказать, что характеристика A совпадает с характеристикой C? Отношение (is the same as)? Определите еще одну сущность с именем «Характеристика D», которая содержит две характеристики?

Следую ли я правильному подходу? Как обычно вы подходите к подобной бизнес-проблеме с помощью GraphDB?

Спасибо :)


person Andrea F.    schedule 09.04.2020    source источник
comment
CharacteristicC owl:sameAs CharacteristicA - это обычная практика в Семантической паутине, когда вы хотите выразить, что оба представляют одну и ту же сущность реального мира. Для классов это owl:equivalentClass соотв. rdfs:subClassOf в обоих направлениях   -  person UninformedUser    schedule 09.04.2020


Ответы (1)


Я не согласен с тем, что owl:sameAs - хорошее решение. По семантике OWL он объединяет (смешивает) два узла, поэтому вы не можете отслеживать их различное происхождение из разных наборов данных.

Если ваши классы имеют только иерархию, но не имеют конкретных свойств, проще всего использовать онтологию SKOS и представлять модели, части и характеристики как skos:Concept. Вы можете иметь разные skos:ConceptScheme или skos:Collection для каждого набора данных, а затем использовать skos:exactMatch для связывания характеристик.

Фактически, вы можете использовать skos:exactMatch для связывания узлов, отличных от skos:Concept. Некоторые авторитетные базы данных используют эту опору для связывания личных / организационных записей между национальными библиотеками.

Для получения дополнительной помощи свяжитесь с нами по адресу info на сайте ontext.com. (Над ЭДАМАМом работал 7-8 лет назад).

person Vladimir Alexiev    schedule 16.09.2020