OpenOrganizations

Communities Россия (Russia)
14

Выложенная часть была готова давно, просто думали открывать или нет в альфе, вот приняли решения, а чего ждать :slight_smile:

Да именно, так. Видел как в забугорной части OSM указывают тэги со ссылкой на Tiger например или туже Википедию, можно по тому же принципу и здесь.

Хороший вопрос. В свое время читал по онтологиям различную информацию, веселая штука. Касательно иерархии. Если я правильно понял, как расписать сложную конструкцию вида назначение организации и уточнения?
Тут как по мне варианта два:

  • идем через рубрикатор
  • идем через тэги

Первый вариант может иметь древовидную структуру, не проблема. На тэгах можно реализовывать простешие отношения, более сложные разбивать. Например расмотрим случай.
Дано: два ресторана (два юр лица), оба управляются одной компанией (управляющая). В первом ресторане есть WiFi, оплата пластиком и наличкой + отдельно доставка. Второй ресторан также имеет WiFi но с паролем, бонусную программу + специализируется на нескольких кухнях и меню есть на сайте. Представим это в нашей схеме:

Возможно это громоздко, но поставленную задачу решило. Определяя такую структуру исходили из следующего:

  • если сущностей может быть не один экземпляр, то выносим в отдельный Contact;
  • если один, то тэги размещаются внутри;
  • если один, но логичские тэги могут пересечься, то тоже выносим;
  • если сущность может включать другую, то это Relation.
15

Интересно, с ходу недостатков не найду.

Движок wikibase не хотите использовать? “statements” это что-то похожее на теги в OSM, но лучше - они строго типизированы

https://www.wikidata.org/wiki/Q2:

https://www.wikidata.org/wiki/Property:P585 - тип времени
https://www.wikidata.org/wiki/Special:WhatLinksHere/Property:P585 - объекты мира с этим свойством

http://wikiba.se/ - сам движок

16

А налоговая не собирается данные открывать?

17

У нас есть выход на администрацию нашего города, работаем с ними по проекту хранению и обмена данными. Сейчас хотим предложить схему синхронизации их баз с нами. Когда проект сними будет выполнен, можно его показывать и другим структурам как пример. Гос структуры ж они такие, так просто не сдвинутся :slight_smile:

ЗЫ в свое время получили данные из налоговой, это ад, указано что попало. Адреса только юридические, а это половина квартиры, контактов почти нет и так далее. По хорошему от них можно взять только юридическую информацию: ИНН КПП и тд.

18

OSM в плане хранения POI сильно ограничен тем, что он не может позволить разделить данные на отдельные сущности, т.к. заточен под хранения геоданных. Хотя и там порой не все одназначно, но все же жить можно. А в POI когда смотрели как там устроено, первое с чем столкнулись это невозможность адекватно отобразить множественные данные, одно только это ставит в тупик. Можно извратиться используя различные соглашения, но это тот еще костыль.

А по ссылкам посмотрю, не натыкался раньше. Но с первого взгляда выглядит очень интересно и в чем-то похоже, можно во всяком случае подчерпнуть оттуда что-нибудь.

Сейчас анализируем данные, рассматриваем возможности и способы их укладки. Пробуем сразу прийти к некоторой формализации эти правил. Первый вариант спецификации был подсмотрен здесь, получилось например вот так:


<?xml version="1.0" encoding="UTF-8"?>
<ooc-tag-definition-list release-date="2014-05-05" release-id="0001" version="1" xsi:noNamespaceSchemaLocation="../schema/ooc-tag-definition-list.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<tag-def key="payment" oncontact="yes">
		<description xml:lang="ru">Способ оплаты</description>
		<value-def value="card">
			<display-name xml:lang="ru">Пластиковая карта</display-name>
		</value-def>
		<value-def value="cash">
			<display-name xml:lang="ru">Наличные</display-name>
		</value-def>
		<value-def value="emoney">
			<display-name xml:lang="ru">Электронные деньги</display-name>
		</value-def>
	</tag-def>
	<tag-def key="emoney">
		<display-name xml:lang="ru">Электронные деньги</display-name>
		<description xml:lang="ru">Наименование системы электронных денег</description>
		<value-def value="webmoney"/>
		<value-def value="bitcoin"/>
		<value-def value="yandex"/>
	</tag-def>
	<tag-def key="wallet">
		<display-name xml:lang="ru">Кошелек</display-name>
		<description xml:lang="ru">Кошелек для перевода электронных денег</description>
	</tag-def>
	<tag-def key="card">
		<display-name xml:lang="ru">Платежная система</display-name>
		<description xml:lang="ru">Платежная система, которой выпущена пластиковая карта</description>
		<value-def value="visa">
			<display-name>Visa</display-name>
		</value-def>
		<value-def value="mastercard">
			<display-name>MasterCard</display-name>
		</value-def>
	</tag-def>
	

	<preset name="card-payment">
		<implies key="tag" value="payment/card"/>
		<requires key="card" />
	</preset>
	
	<preset name="emoney-payment">
		<implies key="tag" value="payment/emoney" />
		<requires key="wallet" />
		<requires key="emoney" />
	</preset>
	
</ooc-tag-definition-list>
19

Ах вот даже как…
В таком случае, категорически рекомендую посмотреть эти ссылки (можно ещё вот эту http://www.youtube.com/watch?v=BUW9S1sVgrQ - с подобными лекциями даже я начал что-то в этом понимать), освежить знания по весёлым онтологиям, Linked Data и Semantic Web.

Пока не поздно и данных мало, есть хорошая возможность вырулить на модель данных будущего. :slight_smile:

20

Попытался ввести организацию. На чем сразу же “споткнулся”:

  • Наименование организации (кстати, попробуйте найти “Вектор, ООО”, их теперь два). Стоит ли пихать форму организации (ООО, ОАО, ЗАО, ПАО и т.п. в наименование или же эти сведения стоит разделить по отдельным полям)? И всякие там сокращенные наименования и т.п. тоже отдельными полями…
  • При вводе номера телефона не дает указать его в международном формате вида +7(3462)00-00-00. Только в виде 83462000000 или 000000. Причем 83462000000 форматируется после ввода в 73462000000 и +7(346)200-00-00.
  • При вводе web-адреса на дает указывать его с префиксом http://, https://. Только само значение. Причем, после сохранения, в начало адреса префикс http:// подставляется автоматически.
  • Для редактирования организации необходимо нажать на название организации, а кнопка “Редактировать” справа - вообще не при делах.
  • После переименования организации “улетели” все её контакты.

Понятно, что это еще глубокая Альфа-версия.

21

Это наверно стоит разделить на отдельные, проблемы нет, скорее всего даже нужно сделать будет. Поставлю себе в ToDo на неделе. Достаточно простая задача.

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

Опять же, наследие старого, перетащилось. Тоже в туду.

Странное поведение, проверю что не так пошло, спасибо.

Собственно для этого и выложили, т.к. у самих глаз уже замылен, все кажется привычным и очевидным.

22

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

А вообще формализованное представление данных по организациям/геоданным и тп достаточно сложная тема, можно хоть кандидатские писать :smiley: Была такая мысля, все минимумы сданы, осталось дело за статьями и самой дисертацией :slight_smile:

23

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

  • телефон организации => <телефон> - принадлежит (по-умолчанию, пустая роль в связи) - <организация>
  • компания дочка другой компании => <компания> - дочка (роль - affiliated) - <компания>
    (если правильно понимаю концепцию онтологий)

Осталось определетить единообразно и системно сущности.

Самая сложная задача в контексте LilnkedData и SemanticWeb это URI. Если человека можно привязать по email, то для организаций сложно. Есть ряд идентификаторов (https://en.wikipedia.org/wiki/International_identifier), но всех они не покрывают. Есть национальные, но там особенности системы надо знать.

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

24

Для сайта openstreetmap.ru была сделана такая штука, возможно и вам подойдёт: http://wiki.openstreetmap.org/wiki/RU:Catalog

25

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

26

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

27

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

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

28

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

29

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

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

30

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

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, сделайте удобные редакторы для отдельных-фактов-во-времени.

31

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

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

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

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

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

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

Советы:

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

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

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

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

33

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