RDF, Tripleles и Semantic Web в повседневных приложениях

Question

Неопределенные, неосведомленные вопросы:

1. Почему почти 100% разработчиков приложений, сообществ разработчиков приложений и литературы (книги, учебные пособия и т. Д.) Считают само собой разумеющимся, что вы хотите выражать данные, используя либо реляционную базу данных, либо хранилище значений ключей?

2: Почему не все используют "тройные" структуры данных?

3: Разве тройки не применимы к каждой проблеме, связанной с реляционными базами данных и хранилищами значений ключей, и разве с тройками не так легко работать в каждом случае?

Answer 1

Тройки могут представлять любую другую структуру данных. Но это не обязательно облегчает работу с ними. Если ваша проблема имеет форму таблицы, то структура данных таблицы будет работать лучше. Со структурой графических данных вам нужно подумать о том, как составлять таблицы из троек, и это дополнительная работа.

Решение большинства проблем (особенно простых проблем, когда форма ваших данных предсказуема) не требует гибкости структуры данных графа.

Answer 2

1. Большинство разработчиков используют реляционные базы данных и / или хранилища ключей / значений, потому что они хорошо известны, широко преподаются, легко доступны и адекватны большинству того, о чем заботится большинство разработчиков.
2. Большинство разработчиков не видят (если таковые имеются) причины использовать тройки, за исключением (возможно) для нескольких специальных целей (и даже последний является несколько необычным).
3. Нет - тройки не особенно просты в использовании, когда большинство людей не понимают их или как их использовать. Даже тем разработчикам, которые их понимают, обычно все равно, что они предоставляют.

В целом, я думаю, что многие разработчики быстро теряются в неразберихе с RDF, OWL, SKOS, онтологиями, механизмами рассуждений и т. Д. Для тех, кто думает: "но я просто хочу историю заказов пользователя" (или что-то в этом роде)), это слишком много, чтобы принять, разобраться и т. д.

Answer 3

Я задавал себе тот же вопрос раньше. Обычно люди называют сложность проблемой. Это действительно плохая привычка, потому что чем дольше мы оставляем проблему, тем хуже она будет. Семантическая паутина - это сложное решение сложной проблемы. Это не становится легче. Я также считаю, что сравнение простоты с RDBMS наивно. Большинство разработчиков в настоящее время знакомы с ORM и работают с абстрактным постоянством, а некоторые даже не знают о механизме постоянного хранения. Фреймворки персистентности для семантической сети (ORDFM) обычно не настолько сложны или развиты. При этом многие организации отходят от СУБД и инвестируют в решения NoSQL, из которых RDF и SPARQL, на мой взгляд, являются лучшими кандидатами.

Отличным примером, на который я всегда обращаю внимание, когда люди говорят о сложном семантическом вебе, является история Барта ван Левена:

http://semtechbizsf2012.semanticweb.com/sessionPop.cfm?confid=65&proposalid=4590

Если настоящий штатный пожарный (который тушит настоящие пожары) может использовать SPARQL и RDF вместо баз данных и проприетарных форматов для решения подлинной проблемы (доступность данных в аварийных службах), то у остальных из нас мало оправданий не, Я хочу сказать, что барьером является не технология, а нечто иное.