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

Question

Смутные, несведущие вопросы:

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

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

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

Answer 1

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

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

Answer 2

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

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

Answer 3

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

Большое исследование случай я всегда указывают, когда люди говорят о Semantic Web в том, чтобы комплекс является Барт ван Лиувен история:

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

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