You are not logged in.

#26 2015-02-03 18:31:33

OverQuantum
Member
From: Zelenograd
Registered: 2009-06-17
Posts: 1,582
Website

Re: Обсуждаем новые структуры данных API, избавляемся от строка=строка

shura0 wrote:

тут очень хорошо подходит JSON? Он не перегружен форматированием, всё по минимуму.

Ы? Really?

JSON:

"building":
    {
        "type":"public",
        "levels":"2",
        "height":"15m",
        "material":"brick",
        "roof":
        {
            "shape":"flat",
            "material":"rubber"
        }
    }

Моё (если условиться, что всё - рабочие маркеры, а комментарии должны предваряться "/"):

  building
  type: public
  levels: 2
  height: 15m
  material: brick
  {
    roof
    shape: flat
    material: rubber
  }

Кавычек нет, запятых нет, при ошибке обычного синтаксиса в одной строке остальное не ломается


d1g wrote:

В синтаксе OverQuantum предлагаю различать #атрибуты=значния (обычно внутри скобок) и ##понятия (главные теги в старой схеме OSM, poi-теги).

ИМХО, не надо умножать сущности.
Есть маркер, он может иметь значение, а может не иметь.
oneway - не главный тэг

Раз уж пошло активное обсуждение синтаксиса - публикую описание на оригинальный синтаксис для адресной книжки. Есть RFC-образная спецификация.
Поскольку адресная книжка ориентирована на то, что записать информацию важнее, чем её разметить, то там допустим простой текст, без разметки, а # служит разметкой.
Иерархии через { } там вообще нет, т.к. я посчитал, что строго группировать адресную информацию - дело глубоко безнадёжное.

Last edited by OverQuantum (2015-02-03 18:49:08)


Это же OpenStreetMap. Он больше внутри, чем снаружи.

Offline

#27 2015-02-03 18:49:15

d1g
Member
From: not using forum
Registered: 2010-01-23
Posts: 2,380
Website

Re: Обсуждаем новые структуры данных API, избавляемся от строка=строка

OverQuantum wrote:

  building
  type: public
  levels: 2
  height: 15m
  material: brick
  {
    roof
    shape: flat
    material: rubber
  }

Т.е. в таком упрощённом синтаксисе нужно понимать как 5 тегов-понятий и 3 атрибута у каждого из этих понятий?

В этом примере немного путаницы на мой взгляд, так стоит обозначить:

building
{
  type: public
  levels: 2
  height: 15m
  material: brick
  roof = {
    shape: flat
    material: rubber
  }
}

Если же скобки убрать то будет неоднозначность: являются ли нижеследующие атрибутами свойствами понятия (building) или самостоятельными понятиями (type, levels, height). Одно другого не исключает, но в рамках свойств building и старой схемы я придерживаюсь мнения что "этажность" это таки свойство здания (building) и его нужно обрамлять скобочками.

Offline

#28 2015-02-03 19:01:49

OverQuantum
Member
From: Zelenograd
Registered: 2009-06-17
Posts: 1,582
Website

Re: Обсуждаем новые структуры данных API, избавляемся от строка=строка

d1g wrote:

Т.е. в таком упрощённом синтаксисе нужно понимать как 5 тегов-понятий и 3 атрибута у каждого из этих понятий?

Нет.
Всё, что находится внутри одной пары { } является описанием одной сущности. Аналогично с тем, что сейчас все тэги объекта в ОСМ являются описанием одной сущности.
Нет разницы между маркерами внутри одной пары { }, "ключевой" маркер может стоять первым, может последним.
Пара { } внутри другой является описанием подчинённой сущности, которая принадлежит внешней.
Глобальная пара { } подразумевается.

Вот это:

  building
  type: public
  levels: 2
  height: 15m
  material: brick
  {
    roof
    shape: flat
    material: rubber
  }

означает 2 сущности:
Основная: здание, публичное, 2 этажа, высотой 15 метров, из кирпича
Подчинённая сущность: крыша, плоская, из резины


Это же OpenStreetMap. Он больше внутри, чем снаружи.

Offline

#29 2015-02-03 19:10:12

d1g
Member
From: not using forum
Registered: 2010-01-23
Posts: 2,380
Website

Re: Обсуждаем новые структуры данных API, избавляемся от строка=строка

OverQuantum wrote:

"ключевой" маркер может стоять первым, может последним.

Если идентификатор хранить точно там где простые свойства=значения, мы повторяем опыт OSM:
1. если маркер стоит "последним", то нужно обработать все свойства=значения.
2. требуется знать какие из свойств=значений главные, а какие - нет

В нормальных онтологиях специально выделяют "понятие" и специальный синтаксис для него (хештег/двойной хештег) чтобы можно было
1. быстрее отличить его от свойства=значения
2. отличить его без знания предметной области

Т.е. это только вы знаете что building - основной, если у вас по тексту (обозначению)  это не ясно, то значит этой информации недостаточно чтобы извлечь знания.
Напротив, если условится обозначать основые теги как ##building то будет сразу ясно что это "понятие", а не "атрибут".

Offline

#30 2015-02-03 19:17:35

d1g
Member
From: not using forum
Registered: 2010-01-23
Posts: 2,380
Website

Re: Обсуждаем новые структуры данных API, избавляемся от строка=строка

OverQuantum wrote:

Глобальная пара { } подразумевается.

понял, тогда с учётом этого, нужно сделать хотя бы так:

  #building
  type: public
  levels: 2
  height: 15m
  material: brick
  {
    #roof
    shape: flat
    material: rubber
  }

Для быстроты парсинга хештеги должны быть в начале структуры. Т.е. получается чтобы узнать что у здания есть крыша придётся обрабатывать свойста building. Иногда имеет смысл продублировать информацию в хештегах для более быстрой обработки (быстрых запросов, специальных парсеров):

#building
#building:with:roof
/...

В принципе, метки building:with:roof не обязательны. И такие понятия можно добавить в базу в неявном виде или при обработке запроса.


PS. Давно не писал CSS, предок с прямым потомком:

object#building > #roof

можно было бы его ускорить до

object#building:with:roof

Last edited by d1g (2015-02-03 19:22:31)

Offline

#31 2015-02-03 19:56:21

OverQuantum
Member
From: Zelenograd
Registered: 2009-06-17
Posts: 1,582
Website

Re: Обсуждаем новые структуры данных API, избавляемся от строка=строка

d1g wrote:

Т.е. это только вы знаете что building - основной, если у вас по тексту (обозначению)  это не ясно, то значит этой информации недостаточно чтобы извлечь знания.

Мне лично сомнительно преимущество выделения основных тэгов. Самоописательными они от этого не становятся.
Если вы получили объект с описанием

#вигвам
height=10

и не знаете, что такое "вигвам", вам # не поможет. А высоту 10 метров можно бы и распарсить.

d1g wrote:

Для быстроты парсинга хештеги должны быть в начале структуры.

Чё-та мне кажется не надо опитимизировать синтаксис ради быстроты парсинга. Попахивает premature optimization, которая root of all evil.
Рекомендовать их ставить первыми - можно.

И не забываем, что их может быть больше одного, если объект является смесью сущностей с (всеми) общими свойствами.


Это же OpenStreetMap. Он больше внутри, чем снаружи.

Offline

#32 2015-02-03 20:16:53

d1g
Member
From: not using forum
Registered: 2010-01-23
Posts: 2,380
Website

Re: Обсуждаем новые структуры данных API, избавляемся от строка=строка

OverQuantum wrote:

и не знаете, что такое "вигвам", вам # не поможет. А высоту 10 метров можно бы и распарсить.

речь не об этом. Знаний нет, зато вам не нужно угадывать что главное:
- height=
- вигвам=

Прямо сейчас можно наблюдать это в type=.
Вы точно также не знаете что такое height, вигвам - но можете на основе #вигвам отфильтровывать. непонятные хештеги могут сломать вашу программу

OverQuantum wrote:

И не забываем, что их может быть больше одного, если объект является смесью сущностей с (всеми) общими свойствами.

Как тогда быть с этим допущением в синтаксе:
Глобальная пара { } подразумевается.

Т.е. глобальные пара всегда одна, но зачем если мы описываем двойственные объекты?

OverQuantum wrote:

Чё-та мне кажется не надо опитимизировать синтаксис ради быстроты парсинга. Попахивает premature optimization, которая root of all evil.
Рекомендовать их ставить первыми - можно.

А если не требовать, а просто рекомендовать, то парсинг усложняется, причём настолько что этот формат будет не надстройкой на xml, а самостоятельным. В xml атрибуты всегда вначале не просто так:
<xml class="#building"> <!-- понятия здесь (либо типами xsd если это кому-то интересно) -->
<!-- простые атрибуты здесь-->
</xml>

Offline

#33 2015-02-03 20:37:55

OverQuantum
Member
From: Zelenograd
Registered: 2009-06-17
Posts: 1,582
Website

Re: Обсуждаем новые структуры данных API, избавляемся от строка=строка

d1g wrote:

Т.е. глобальные пара всегда одна, но зачем если мы описываем двойственные объекты?

Если все свойства одинаковые у двух сущностей, смешанных в один объект, нет смысла их разделять, дублируя все свойства.
Например, магазин + мастерская, с одним временем работы и т.д.

d1g wrote:

этот формат будет не надстройкой на xml, а самостоятельным. В xml атрибуты всегда вначале не просто так

Конечно, самостоятельным. Текст с хэштэгами и { } единым куском - должен быть основным представлением описания свойств объекта.
XML строго иерархичен (если не начинать мудрить со ссылками).
ИМХО, объекты на карте мира слишком разнообразны, чтобы их описания укладывались в строго иерархичную структуру данных.

Last edited by OverQuantum (2015-02-03 20:38:16)


Это же OpenStreetMap. Он больше внутри, чем снаружи.

Offline

#34 2015-02-03 20:44:56

d1g
Member
From: not using forum
Registered: 2010-01-23
Posts: 2,380
Website

Re: Обсуждаем новые структуры данных API, избавляемся от строка=строка

OverQuantum wrote:

Если все свойства одинаковые у двух сущностей, смешанных в один объект, нет смысла их разделять, дублируя все свойства.

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

Прямо сейчас в osm можно продублировать информацию об объекте мира, этим не злоупотребляют без надобности.

Технически это запретить в любом случае не получится без знания всех доменов в OSM, это займёт много лет такая задача.

OverQuantum wrote:

ИМХО, объекты на карте мира слишком разнообразны, чтобы их описания укладывались в строго иерархичную структуру данных.

Ну я собственно про это и спрашиваю - зачем корень один требовать:
Глобальная пара { } подразумевается.

<описание элемента в osm>
   <суть class="#building"></суть>
   <суть class="#leisure"></суть>
</описание элемента в osm>

Offline

#35 2015-02-03 20:52:12

OverQuantum
Member
From: Zelenograd
Registered: 2009-06-17
Posts: 1,582
Website

Re: Обсуждаем новые структуры данных API, избавляемся от строка=строка

d1g wrote:

Ну я собственно про это и спрашиваю - зачем корень один требовать:
Глобальная пара { } подразумевается.

Для одного объекта ОСМ имелось ввиду.


Это же OpenStreetMap. Он больше внутри, чем снаружи.

Offline

#36 2015-02-03 21:07:02

d1g
Member
From: not using forum
Registered: 2010-01-23
Posts: 2,380
Website

Re: Обсуждаем новые структуры данных API, избавляемся от строка=строка

OverQuantum wrote:

Для одного объекта ОСМ имелось ввиду.

Ну мне тогда не понятно как их считать, как парсить и интерпретировать, на примере xml это можно показать?

<описание элемента в osm>
   <суть class="#building">
      <height>3m</height>
   </суть>
   <суть class="...">
      ...
   </суть>
</описание элемента в osm>

upd: У <описание элемента в osm> есть какие-то общие свойства?

Last edited by d1g (2015-02-03 21:08:18)

Offline

#37 2015-02-03 21:36:04

OverQuantum
Member
From: Zelenograd
Registered: 2009-06-17
Posts: 1,582
Website

Re: Обсуждаем новые структуры данных API, избавляемся от строка=строка

Например, сейчас в XML:

  <way id='36770486' timestamp='2012-08-06T20:36:37Z' uid='109327' user='OverQuantum' visible='true' version='3' changeset='12638603'>
    <nd ref='425868266' />
    <nd ref='427526277' />
    <tag k='bridge' v='yes' />
    <tag k='foot' v='yes' />
    <tag k='highway' v='path' />
    <tag k='layer' v='1' />
  </way>

Моё предложение: вместо перечня tag-ом - описание в виде одного многострочного блока текста с хэштегами. Если основной формат данных остаётся XML - то многострочный блок как-то должен быть завёрнут, чтобы хранится внутри XML. Например, через &#xD так:

  <way id='36770486' timestamp='2012-08-06T20:36:37Z' uid='109327' user='OverQuantum' visible='true' version='3' changeset='12638603'>
    <nd ref='425868266' />
    <nd ref='427526277' />
    <data k='#highway: path &#xD #bridge &#xD layer: 1' />
  </way>

Парсить и интерпретировать - в зависимости от решаемой задачи. Если задача найти объекты определённого вида - ищем в блоке маркеры, которым этот вид объектов обозначается. Если задача отрендерить каждый объект - парсим построчно и сверяемся с перечнем понятных для рендера маркеров.


Это же OpenStreetMap. Он больше внутри, чем снаружи.

Offline

#38 2015-02-03 21:53:53

d1g
Member
From: not using forum
Registered: 2010-01-23
Posts: 2,380
Website

Re: Обсуждаем новые структуры данных API, избавляемся от строка=строка

OverQuantum wrote:

<data k='#highway: path &#xD #bridge &#xD layer: 1' />

Так нет же! Я предлагаю настоящий кусок xml пользователю, а не закодированный xml в параметр

<way старый
   <nd 
   <nd
   <tag
   <tag
   <описание элемента в osm
      <суть
      <суть
</way

Со временем от тегов откажемся (не будем использовать).

OverQuantum wrote:

Парсить и интерпретировать - в зависимости от решаемой задачи. Если задача найти объекты определённого вида - ищем в блоке маркеры, которым этот вид объектов обозначается. Если задача отрендерить каждый объект - парсим построчно и сверяемся с перечнем понятных для рендера маркеров.

В вашем варианте получается обязательно k=' декодировать прежде чем даже отфильтровать данные с #ufo.

Поэтому и вопрос: какие-то свойства у <описание элемента в osm> есть по моей схеме? Или это просто контейнер сутей?

Offline

#39 2015-02-03 22:24:34

OverQuantum
Member
From: Zelenograd
Registered: 2009-06-17
Posts: 1,582
Website

Re: Обсуждаем новые структуры данных API, избавляемся от строка=строка

d1g wrote:

Так нет же! Я предлагаю настоящий кусок xml пользователю, а не закодированный xml в параметр

Я уже два раза писал, что считаю иерархичную XML структуру не подходящей для описания свойств объектов. Геометрия может оставаться в XML, описание - не должно.

d1g wrote:

Поэтому и вопрос: какие-то свойства у <описание элемента в osm> есть по моей схеме? Или это просто контейнер сутей?

Я не понимаю вопроса.
Вы сами ввели "<описание элемента в osm>" и мне задаёте про него вопросы.
Я привёл пример как я вижу описание объекта.


Это же OpenStreetMap. Он больше внутри, чем снаружи.

Offline

#40 2015-02-03 22:30:12

d1g
Member
From: not using forum
Registered: 2010-01-23
Posts: 2,380
Website

Re: Обсуждаем новые структуры данных API, избавляемся от строка=строка

OverQuantum wrote:

Я уже два раза писал, что считаю иерархичную XML структуру не подходящей для описания свойств объектов. Геометрия может оставаться в XML, описание - не должно.

А почему CDATA секции или текстовые элементы не подходят? Вы же не только простой текст в комментарии превращаете, но всё описание получается закодированным.

В каком-то смысле это хуже сейчашних <tag: их нельзя пользователю напрямую редактировать. Ваш формат не текстовый, он полу-бинарный, понимаете?

OverQuantum wrote:

Вы сами ввели "<описание элемента в osm>" и мне задаёте про него вопросы.

Понял, мы совсем о разных вещах говорим тогда. Я понимаю ваш синтаксис как xml с текстом-комментариями в xml.

Offline

#41 2015-02-04 00:00:20

OverQuantum
Member
From: Zelenograd
Registered: 2009-06-17
Posts: 1,582
Website

Re: Обсуждаем новые структуры данных API, избавляемся от строка=строка

d1g wrote:

Ваш формат не текстовый, он полу-бинарный, понимаете?

Перенос строки является частью текста. То что его надо кодировать спец-символом внутри XML - проблема XML.


Это же OpenStreetMap. Он больше внутри, чем снаружи.

Offline

#42 2015-02-04 20:51:59

d1g
Member
From: not using forum
Registered: 2010-01-23
Posts: 2,380
Website

Re: Обсуждаем новые структуры данных API, избавляемся от строка=строка

OverQuantum wrote:

То что его надо кодировать спец-символом внутри XML - проблема XML.

Допустим, а как тогда кодировать текст в первую очередь и ещё машинно читаемую информацию при этом иметь?

Текст отдельно, метаданные отдельно? Как тогда их связывать в визуальном редакторе?

Offline

#43 2015-02-04 21:15:37

OverQuantum
Member
From: Zelenograd
Registered: 2009-06-17
Posts: 1,582
Website

Re: Обсуждаем новые структуры данных API, избавляемся от строка=строка

d1g wrote:

как тогда кодировать текст в первую очередь и ещё машинно читаемую информацию при этом иметь?

Какой "текст в первую очередь"?
Названия - в значениях. Если надо записать пробел в значении, то обязательно обрамляем в {}, если без пробелов - {} не обязательны.
Комментарии к чему угодно - после / и до конца строки.

name: {улица Космонавтов}
max,speed: 40  /знак

"/знак" - комментарий, типа мапперу было влом разбираться как проставить источник инмформации об ограничении скорости.

Машиночитаемость отличная. Записная книжка на 200 000 знаков отлично парсится, валидируется, экспортируется, синхронизируется и т.д.

Last edited by OverQuantum (2015-02-04 21:16:51)


Это же OpenStreetMap. Он больше внутри, чем снаружи.

Offline

Board footer

Powered by FluxBB