OpenOrganizations

так же есть вот такой формат: http://schema.org/Organization

Да, это из области SemanticWeb и в большей степени относится к страницам. Из него тоже брали некоторые моменты, особенно по времени работы. Текущий наш продукт полностью размечен по schema.org :slight_smile: Особенно это понравилось гуглы, когда спустя какое-то время он стал более активно в поиске выдавать организации в снипетах :smiley:

Еще один нюанс заложили, так как все же это не визуальные данные, то оценить их достоверность тяжело: либо верны либо нет. К тому же эти данные имеют свойство устаревать, если остров никуда не денется, то организации мигрируют только так. Для отражения этой динамики ввели понятие достоверность и официальные данные. Достоверность изменяется в интервале от 0 до 1. При изменении сущности ее достоверность расчитывается относительно того, кто внес эти правки. Так если пользователь не был замечен в вандализме, но его правки имеют величину 0.5, т.е. данные равновероятно верны и не верны. Если пользователь был замечен и были применены санкции (без бана), то его коэффициент будет ниже. Если правки вносит владелец, то его коэффициент будет равен 1 + сущность помечается как официальная, при изменении другим этот флаг снимается. Далее, в течении определенного времени (сейчас это 3 месяца), коэффициент выравнивается на 0.5. Таким образом, если правка была внесена пользователем с плохой “кармой”, но не исправлена за этот период, то можно считать что она все же наверно верна. Так же если у правки был высокий коэффициент, но долго не обновлялось, то вероятно данные могли устареть.

Ну и конечно для защиты от войны правок есть блокировки.

Еще как-то надо хранить ссылку на источник информации, чтобы можно было протухающие данные перевалидировать.
Это ссыки на офсайт, телефон организации и т.п.

Вот и я заметил, что ложится, когда зашёл на сайт. Потому и обрадовался.
Хотя я пример с телефоном вижу как <компания> - телефон - “строка с телефоном (литерал)”, если номер телефона хранить формализованно, то и представлять его будет удобно в любом виде, не вводя дополнительные поля.
Возможно семантическая система хранения и окажется неоправданно громоздкой для задач проекта, и лучше поискать другие варианты. Но если выгрузки данных в выбранном варианте будут легко раскладываться на формализованнные триплеты и связываться с другими наборами данных - будет здорово.

Вообще не проблема, по-моему. Вон, в wikidata для элемента Q2 сопоставлен URI www.wikidata.org/entity/Q2 , и ничего, работает.

Это очень примитивный подход к информации. В реальности всё намного сложнее:

https://en.wikipedia.org/wiki/Data_cleansing#Data_quality - перескажу основные моменты:

  • информация актуальна только на определённый период. Классические/неразвитые онтологии не учитывают это либо считают сложным/излишним: https://en.wikipedia.org/wiki/Ontology_components#Overview
    – name=*
    – alt_name=*
    – old_name=* - все эти теги “достоверны” но только на определённый “временной интервал” либо “момент времени”
  • информация актуальна только для одного языка (отсюда встроенная многоязычность у Wikibase, “основные” текстовые метки и “альтернативные”)
  • информация верна, но не полна (“я знаю что это телефон в нашем городе”, “я знаю что это сотовый номер”, “оканчивается на …789”)
  • системные сбои и человеческие опечатки это отдельная тема, не связанная ни с чьим “вандализмом” и “кармой”: https://en.wikipedia.org/wiki/Data_integrity#Types_of_integrity_constraints https://en.wikipedia.org/wiki/First_normal_form https://en.wikipedia.org/wiki/Named-entity_recognition - одно и то же явление исследуют многие предметные области
  • отсутствие возможности свободной мета-информации в любом месте (источники, заметки о времени, заметки о неполноте)
  • двоякость в текстовых метках/языках/данных - в онтологиях это “типы” или “свойства” в wikibase, в естественных языках это распознавание объекта по буквам https://en.wikipedia.org/wiki/Entity_linking

Ещё ссылок:
https://en.wikipedia.org/wiki/Information_architecture https://en.wikipedia.org/wiki/Data_management#Topics_in_Data_Management - обзорные статья для человека с улицы
http://www.w3.org/TR/owl-time/ - старый стандарт несколько идей сколько разных бывает “времён”
https://ru.wikipedia.org/wiki/ISO_15926 - новый стандарт, сложнее и правдивее. Человеческое описание - http://habrahabr.ru/post/246991/
http://forum.openstreetmap.org/viewtopic.php?pid=508402#p508402 - мои наблюдения откуда берутся “ошибки” и “опечатки” в OSM

Теория варьируется от самой жёсткой: теория категорий, автоматы, типизированные онтологии, до мягких: частично размеченный текст, обычные “вики” и свободных: неразмеченный текст, поиск интернета, извлечение данных машинным обучением, обработка естесственных языков (современные методы при этом учитывают знания мира wikidata/wikipedia/wordnet).

Примеры из OSM:

С организациями же я бы вам предложил сделать упор на временные стандарты, а не географические. Ваш враг - время, некорректность указания данных во времени. Враг OSM - неточность геометрий и гео-координат. JOSM сложен потому что мы добиваемся гео-пространственной точности, загружаем GPS треки прямо в редакторы, узнаём как врут нам космические снимки.

Обратите внимание на 4D онтологии и ISO 15926, сделайте удобные редакторы для отдельных-фактов-во-времени.

Про карму и достоверность в числах отдельно хотел сказать:

Ни в коем случае не выкидывайте промежуточную информацию при редактировании, историю объектов! Если вы выкинете информацию:

  • “о вандалах” - вы не сможете определять/учить автоматически “вандальные действия”
  • “спам” - вы не сможете определять/учить автоматически “это спам/это не спам”, “что именно спам”, “когда это спам или не спам”
  • “о DDOS” - вы не сможете определять/учить автоматически “нас DDOS-ят нас не DDOS-ят”
  • “о копирующих запрещённое” - вы не сможете автоматически определять заимствования

Механизмы вашей “кармы” не идеальны. Любую “карму” можно сломать/базу рейтингов отравить. Карму того же хабра ломали раз десять точно. У вас должен быть аудит каждого чиха на карме и полное понимание почему “здесь достовеность 0.5555555”, а здесь “0.3879” - иначе что эти числа значат?

Пользователи с “низкой” кармой могуть быть эксператами в своей области, в то время как “опытные” пользователи это просто набивальщики “очков”:

  • для зарплаты
  • для плюсиков в Интернете

Советы:

  • поощрять полноту, а не “количество”: в этом районе три магазина на километр, ты обошёл километр и получишь вознаграждение по ставке …
  • поощрять проверку данных, а не “новые данные”: ты проверил N фактов типа M по ставке …
  • поощрять разные гео-районы по-разному (климат, социальная обстановка, наличие источников, сложный рельеф местности)
  • поощрять по-разному легко проверяемые данные (высокая “достоверность” >0,8, много достоверных данных связанных с этим) и плохо проверяемые (мало других фактов, мало источников)

Карма в данном контексте просто как аналогия. Данная величина зависит не от поставленных ±, а именно от внутренних факторов. Например если человек проживает в том же городе, для которого вносит изменения, то вероятность достоверности выше, можно учитывать это как поправочный коэффициент.
В идеале да, нужны сложные либо достаточные алгоритмы по обработке поведения, на старте у всех коэффициент 0.5. У сотрудников 1 у партнеров 1. Первое время пока не накоплена статистика примитивный алгоритм, просто для поддержания внутренних структур, далее можно усложнять.

Механизм кармы, или социальная модерация плюсиками штука порой сильно сомнительная.

По поводу достоверности на каждый отдельный тэг, обсуждали такой вариант, но выходил достаточно избыточен. Потому просто храним историю изменений каждого объекта целиком: http://openorganizations.org/api/0.1/relation/5/history

До кучи требовать сразу фотки объекта :slight_smile:

И расписку, скрепленную кровью. Тех полутора человек, которые останутся, это всё равно не отпугнёт. :slight_smile:

Модерация в стиле кто больше плюсиков наберёт - нет, а вот проверка правок на “ошибочность” - вполне да. В OSM обсуждали тему плюсиков у пакетов правок, пока это не сделано да и противоречит это OSM в чём-то: настоящая модерация это зло, а вот сообщения о ошибках в данных - пожалуйста. В Википедии модерация называется “патрулирование”, у программистов это называется https://en.wikipedia.org/wiki/Code_review.

Вот такая задача: в моём городе действовала фирма по продаже воды, у них были 20 точек по городу (name=Вода + amenity=drinking_water + operator=Водоносы) и центральный офис (office=company + name=Водоносы + owner=Водоносы). Как это отметить в ваших терминах? Что делать когда “адреса” как такового у объектов нет? Будете игнорировать 20 amenity=drinking_water и отметите только центральный офис?

Ещё вопрос: не все моллы в OSM сейчас детализированы до уровня indoor, отдельных комнат и входов - как будете отмечать организации если молл отмечен только частично? Будете ли перепривязывать к помещениям если их отметят в OSM?

И будет ли загрузка фотографий пользователей (источники, таблички, информация)? В OSM это делается отчасти указанием ссылки на Википедию у которой уж точно есть картинки, но проекты Викимедия не для организаций (насколько я знаю).

Разделил

переделал

исправил

исправил

:slight_smile:

Задачки это хорошо, накидывайте, будет полезно выявлять нестыковки и узкие места. Тут нужно уточнить, что такое точка? Если это что-то стационарное, то может иметь координату. Если это что-то подвижное, то можно иначе рассмотреть. Попробую сейчас отобразить :slight_smile:

R
- organization=service
- service=drinking_water
- name=Водоносы
- legal_form=ООО
- legal_entity=Водоносы
- brand=Живая вода
- B (lat, lon)
-- branch=headquarter
-- country=Страна
-- city=Город
-- street=Улица
-- house=Дом

(вариант если это стационарные точки продажи)
- B (lat, lon)
-- branch=point-of-sale
-- country=Страна
-- city=Город
-- street=Улица
-- house=Дом
-- С
--- person=vendor
--- name=Иван Иванович
--- phone=+792233445566

(если это курьеры)
- R
-- branch=delivery
-- С
--- person=delivery
--- name=Иван Иванович
--- phone=+792233445566

Как-то так получилось, возможно не до конца понял условие. Единственный момент, что нужна физическая привязка в любом случае, хотя есть варианты, когда можно выкрутиться из этого. Для таких случаев была мысль делать ссылки на области, это могут быть уровни административной иерархии (например обслуживает Ростовскую область, но физически не представлен везде там).

Детализация до такого уровня это хорошо, в целом по возможности никто не мешает это делать, надо только посмотреть как это отрисовано в OSM и расширить в редакторе поля, не видел еще таких зданий, надо в Москве посмотреть.

На старте внешние ссылки, либо интеграции с ресурсами, например ссылка на Foursquare, чем не LinkedData :smiley: В перспективе свой сервис.

А как планируете адреса сохранять?
Для случая когда их несколько?

Можно один основной адрес оставить в теле Branch, а остальные вынести как контакты, например


- B (lat, lon) 
-- branch=headquarter 
-- country=Страна 
-- city=Город 
-- street=Улица 
-- house=Дом
-- С
--- location=alias
--- country=Страна 
--- city=Город 
--- street=Улица1
--- house=Дом1
-- С
--- location=alias
--- country=Страна 
--- city=Город 
--- street=Улица2
--- house=Дом2

При условии что точка неизменна, если точка меняется, то нужно указывать новый Branch.

Да точка неизменна, просто у дома в котором расположена организация - два адреса.

С подобным тоже сталкивались, когда в одном городе администрация решила массово сменить адресацию, а народ привык к старой. Старая схема не поддерживала такого, пришлось городить костыли.

В общем это не редкая ситуация. Так же как адреса по микрорайонам например.

Начну фиксировать описания объектов, процесс можно отслеживать здесь: https://trello.com/b/vhEO61W9/guidlines Не уверен, но и вроде редактировать тоже можно.
Когда основные будут зафиксированы, выполню загрузку имеющихся данных по городам + было обнаружено что в открытых данных Москвы много полезной информации есть, так что вторым шагом будет их загрузка. Аналогичные есть для Санкт-Петербурга.

Загрузил рубрикатор из Yandex: http://openorganizations.org/changeset/40
И пока два набора с http://data.mos.ru
Гимназии: http://openorganizations.org/changeset/41
Библиотеки: http://openorganizations.org/changeset/42

http://catalog.openorganizations.org/0.1/ru/search?q=%D0%BB%D0%B5%D0%BD%D0%B8%D0%BD&boundary=20410 - запрос для региона Москва