Наконец-то эту идею реализовали в открытом виде.
Ведь это, как я понял, те же Викиданные, только по организациям - та часть информации, которую Викиданные не охватывают. Как вариант, можно будет в последствии не расписывать организацию в OSM, а указывать тег с идентификатором OpenOrganizations.
Таксономии в ваших данных есть в каком-либо виде? Дело в том что многие теги в OSM исторические и смысла не имеют по большей части: amenity=fuel, amenity=car_repair, amenity=bar.
Насколько сложно будет реализовать в вашей системе иерархии? Если вы выбрали путь как и OSM для POI тегов то рано или поздно вы придёте к такой же проблеме.
Хотелось бы верить что это будет так. Некоторые компании реализуют это юридически авторским правом, а “свободность” обеспечивается только словесно. У некоторых компаний случаются кризисные моменты и они выбирают путь защищать свои данные любой ценой и теряют наполнителей и сообщество. Не повторяйте их ошибки:
Если же когда-нибудь захотите импортировать в главную базу OSM будем всегда рады: https://wiki.openstreetmap.org/wiki/Import/Guidelines - всё сводится к тому, чтобы договориться с сообществом как будет проходить импорт
Выложенная часть была готова давно, просто думали открывать или нет в альфе, вот приняли решения, а чего ждать
Да именно, так. Видел как в забугорной части OSM указывают тэги со ссылкой на Tiger например или туже Википедию, можно по тому же принципу и здесь.
Хороший вопрос. В свое время читал по онтологиям различную информацию, веселая штука. Касательно иерархии. Если я правильно понял, как расписать сложную конструкцию вида назначение организации и уточнения?
Тут как по мне варианта два:
идем через рубрикатор
идем через тэги
Первый вариант может иметь древовидную структуру, не проблема. На тэгах можно реализовывать простешие отношения, более сложные разбивать. Например расмотрим случай. Дано: два ресторана (два юр лица), оба управляются одной компанией (управляющая). В первом ресторане есть WiFi, оплата пластиком и наличкой + отдельно доставка. Второй ресторан также имеет WiFi но с паролем, бонусную программу + специализируется на нескольких кухнях и меню есть на сайте. Представим это в нашей схеме:
Возможно это громоздко, но поставленную задачу решило. Определяя такую структуру исходили из следующего:
если сущностей может быть не один экземпляр, то выносим в отдельный Contact;
если один, то тэги размещаются внутри;
если один, но логичские тэги могут пересечься, то тоже выносим;
если сущность может включать другую, то это Relation.
У нас есть выход на администрацию нашего города, работаем с ними по проекту хранению и обмена данными. Сейчас хотим предложить схему синхронизации их баз с нами. Когда проект сними будет выполнен, можно его показывать и другим структурам как пример. Гос структуры ж они такие, так просто не сдвинутся
ЗЫ в свое время получили данные из налоговой, это ад, указано что попало. Адреса только юридические, а это половина квартиры, контактов почти нет и так далее. По хорошему от них можно взять только юридическую информацию: ИНН КПП и тд.
OSM в плане хранения POI сильно ограничен тем, что он не может позволить разделить данные на отдельные сущности, т.к. заточен под хранения геоданных. Хотя и там порой не все одназначно, но все же жить можно. А в POI когда смотрели как там устроено, первое с чем столкнулись это невозможность адекватно отобразить множественные данные, одно только это ставит в тупик. Можно извратиться используя различные соглашения, но это тот еще костыль.
А по ссылкам посмотрю, не натыкался раньше. Но с первого взгляда выглядит очень интересно и в чем-то похоже, можно во всяком случае подчерпнуть оттуда что-нибудь.
Сейчас анализируем данные, рассматриваем возможности и способы их укладки. Пробуем сразу прийти к некоторой формализации эти правил. Первый вариант спецификации был подсмотрен здесь, получилось например вот так:
Ах вот даже как…
В таком случае, категорически рекомендую посмотреть эти ссылки (можно ещё вот эту http://www.youtube.com/watch?v=BUW9S1sVgrQ - с подобными лекциями даже я начал что-то в этом понимать), освежить знания по весёлым онтологиям, Linked Data и Semantic Web.
Пока не поздно и данных мало, есть хорошая возможность вырулить на модель данных будущего.
Попытался ввести организацию. На чем сразу же “споткнулся”:
Наименование организации (кстати, попробуйте найти “Вектор, ООО”, их теперь два). Стоит ли пихать форму организации (ООО, ОАО, ЗАО, ПАО и т.п. в наименование или же эти сведения стоит разделить по отдельным полям)? И всякие там сокращенные наименования и т.п. тоже отдельными полями…
При вводе номера телефона не дает указать его в международном формате вида +7(3462)00-00-00. Только в виде 83462000000 или 000000. Причем 83462000000 форматируется после ввода в 73462000000 и +7(346)200-00-00.
При вводе web-адреса на дает указывать его с префиксом http://, https://. Только само значение. Причем, после сохранения, в начало адреса префикс http:// подставляется автоматически.
Для редактирования организации необходимо нажать на название организации, а кнопка “Редактировать” справа - вообще не при делах.
После переименования организации “улетели” все её контакты.
Это наверно стоит разделить на отдельные, проблемы нет, скорее всего даже нужно сделать будет. Поставлю себе в ToDo на неделе. Достаточно простая задача.
Интерфейс редактора опирался на наши текущие наработки, точнее даже так, для прототипа редактора были взяты текущие наработки и адаптированы под новую схему. Значение указывается в чистом формате, т.е. без каких либо знаков, только цифры, а вот в поле синоним забивается так, как хотелось бы видеть его. Надо поработать на названиями полей.
Опять же, наследие старого, перетащилось. Тоже в туду.
Странное поведение, проверю что не так пошло, спасибо.
Собственно для этого и выложили, т.к. у самих глаз уже замылен, все кажется привычным и очевидным.
Данные есть, но они на стадии устаканивания соглашений по тэгам и тд. Т.к. если их уже залить, то переиграть будет уже сложно. А то возможных данных много, те что можем пощупать уже в целом ясно как укладывать, но возможных случаев много, а как это описать еще больше.
А вообще формализованное представление данных по организациям/геоданным и тп достаточно сложная тема, можно хоть кандидатские писать Была такая мысля, все минимумы сданы, осталось дело за статьями и самой дисертацией
Вспомнил годы аспирантские Семантичаская модель хороша, но достаточно тяжелая как по внутренней структуре так и технически. Имеет смысл сделать сам сервис интероперабельным.
В целом модель которую заложили не плохо ложится на триплеты, например:
телефон организации => <телефон> - принадлежит (по-умолчанию, пустая роль в связи) - <организация>
компания дочка другой компании => <компания> - дочка (роль - affiliated) - <компания>
(если правильно понимаю концепцию онтологий)
Осталось определетить единообразно и системно сущности.
Самая сложная задача в контексте LilnkedData и SemanticWeb это URI. Если человека можно привязать по email, то для организаций сложно. Есть ряд идентификаторов (https://en.wikipedia.org/wiki/International_identifier), но всех они не покрывают. Есть национальные, но там особенности системы надо знать.
Но в целом, имея семантическую модель, можно прийти к тому что запросы к модели формируют не конечный ответ, а промежуточный фильтр, который выгребает уже конечные данные. Но это уже задача на будущее, пока держу в голове, посматриваю почитываю, охватить тяжело все и сразу.
Да, это из области SemanticWeb и в большей степени относится к страницам. Из него тоже брали некоторые моменты, особенно по времени работы. Текущий наш продукт полностью размечен по schema.org Особенно это понравилось гуглы, когда спустя какое-то время он стал более активно в поиске выдавать организации в снипетах
Еще один нюанс заложили, так как все же это не визуальные данные, то оценить их достоверность тяжело: либо верны либо нет. К тому же эти данные имеют свойство устаревать, если остров никуда не денется, то организации мигрируют только так. Для отражения этой динамики ввели понятие достоверность и официальные данные. Достоверность изменяется в интервале от 0 до 1. При изменении сущности ее достоверность расчитывается относительно того, кто внес эти правки. Так если пользователь не был замечен в вандализме, но его правки имеют величину 0.5, т.е. данные равновероятно верны и не верны. Если пользователь был замечен и были применены санкции (без бана), то его коэффициент будет ниже. Если правки вносит владелец, то его коэффициент будет равен 1 + сущность помечается как официальная, при изменении другим этот флаг снимается. Далее, в течении определенного времени (сейчас это 3 месяца), коэффициент выравнивается на 0.5. Таким образом, если правка была внесена пользователем с плохой “кармой”, но не исправлена за этот период, то можно считать что она все же наверно верна. Так же если у правки был высокий коэффициент, но долго не обновлялось, то вероятно данные могли устареть.
Ну и конечно для защиты от войны правок есть блокировки.
Еще как-то надо хранить ссылку на источник информации, чтобы можно было протухающие данные перевалидировать.
Это ссыки на офсайт, телефон организации и т.п.