метрика открытости

[Xasima]

Добрый день, можете ли рассказать о каких-либо существующих (возможных) параметрах,  которых стоит включить в метрику открытости сайтов, прежде всего образовательного (ВУЗЫ) и государственного профиля. 

--
Best regards,
     ~ Xasima ~

[Ivan Mikhailov]

Я бы мерял в джоулях. Если пользователю нужны данные с сайта (Скажем, для аналитики), и он сначала в муках ищет, где бы они могли быть, а потом в ещё больших муках пытается связать с другими данными, то его мозги греются. Это тепло и будет метрикой --- чем оно меньше, тем лучше открыты данные. Если серьёзно, то одной цифрой не обойтись, набирается целый список ортогональных свойств. Данных может быть много или мало, чистых или грязных, живых или редко обновляемых, связанных с LOD или нет, доступных через service endpoint или только в виде дампов... интересных или бесполезных. Разве что  померять "проблемности" по всем свойствам и перемножить --- но тогда на джоули и выйдем. Всего наилучшего, Иван Михайлов. --- On Tue, 4/17/12, Xasima <xas...@gmail.com> wrote:

-- Вы получили это сообщение, поскольку подписаны на группу веб данных. Чтобы добавлять сообщения в эту группу, отправьте письмо по адресу webofdat...@googlegroups.com. Чтобы отменить подписку на эту группу, отправьте сообщение по адресу webofdata-russ...@googlegroups.com. О дополнительных функциях можно узнать в группе по адресу http://groups.google.com/group/webofdata-russian?hl=ru.

[Ivan Begtin]

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

Технологические

- число ошибок выдаваемых валидаторами HTML и CSS

- число ошибок выдаваемых валидаторами по WCAG

- наличие мобильной версии сайта

- наличие версии для слабовидящих

Юридические:

- наличие и характер условий использования материалов (варианты: нет условий использования, условия есть но ограничивающие, раскрытие под свободными лицензиями

- наличие файла robots.txt (важен с точки зрения исков владельцев сайтов к поисковикам и другим краулерам)

Открытые данные:

- экспорт новостей в RSS/ATOM

- машиночитаемое раскрытие ключевых данных в зависимости от тематики сайта 

- публикация даных в форматах Semantic Web (RDF) (почти ни один сайт не будет этому соответствовать)

Содержательное:

- наличие контактов для обратной связи - email, телефон

- наличие информации об организационной структуре

- наличие информации о перечне нормативно-правовых документов согласно которым регулируется данный сайт

- наличие положения о сайте - для органа государственной власти

Плюс есть законы и другие нормативные документы которые регулируют конкретные требования в конкретной стране - имеет смысл включить их в параметры.

С уважением,

   Иван Бегтин

17 апреля 2012 г. 20:01 пользователь Xasima <xas...@gmail.com> написал:

--

Вы получили это сообщение, поскольку подписаны на группу веб данных.
Чтобы добавлять сообщения в эту группу, отправьте письмо по адресу webofdat...@googlegroups.com.
Чтобы отменить подписку на эту группу, отправьте сообщение по адресу webofdata-russ...@googlegroups.com.
О дополнительных функциях можно узнать в группе по адресу http://groups.google.com/group/webofdata-russian?hl=ru.

--

Best Regards,
  Ivan Begtin

email: ibe...@gmail.com

twitter: ibegtin

facebook: facebook.com/ibegtin

personal website: ivan.begtin.name

[Xasima]

On Tue, Apr 17, 2012 at 10:05 PM, Ivan Mikhailov <iv_a...@yahoo.com> wrote:

Я бы мерял в джоулях. Если пользователю нужны данные с сайта (Скажем, для аналитики), и он сначала в муках ищет, где бы они могли быть, а потом в ещё больших муках пытается связать с другими данными, то его мозги греются. Это тепло и будет метрикой --- чем оно меньше, тем лучше открыты данные.

Спасибо. Мне понравилось предложение измерять "открытость" в терминах джоулей "выделяемых мозгом пользователя". Ведь что влияет на субъективное ощущение затрат, необходимых для того чтобы получить, разобрать, интерпретировать данные?

1) Во-первых, это скорость получения и поиска "полуструктурированных" данных. В данном случае, количество затрачиваемых операций может быть мало (мы просто "ждем" поступление данных), но вместе этого возникает "перегрев" использования других ресурсов: времени, переключений, блокировок. 

2) Во-вторых, количество операций, необходимое для того, чтобы произвести их интерпретацию (т.е. связать "карту внешних данных и карту внутреннего их представления"). Думаю, что здесь скорее важна не абсолютная скорость в данный момент, и даже не наихудшая скорость для заданного класса в целом. Пользователь, мне кажется, в качестве меры "сложности" интерпретации скорее воспримет связку ~"амортизированной" и ~"почти всегда" сложностей.  К примеру, пусть для понимания проблемы необходимо или произвести обширное обучение системы  A (построить на своем парке машин аналог IBM Watson) до решения какой-либо задачи, или же можно использовать сервис B который (пусть без сложных вычислений) сразу предоставляет данные в желаемой смысловой интерпретации. Несмотря на равное затрачиваемое время для получения ответа субъективно общая стоимость будет различаться. Т.е. пользователь скорее оценивает общие амортизированные (размазанные на весь цикл решения бизнес-проблемы) затраты. И скорее всего, его будет интересовать скорость решения "почти всех" ЕГО задач. 

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

Принцип Ландауэра гласит, что обработка информации и термодинамические процессы связаны (пусть и опосредованно). Соответственно, можно  искусственно связать блокировки, время, операции, амортизацию, эмоции  с теплообменом "стоимости получения, интерпретации, обработки информации в рамках долговременного решения бизнес-проблемы пользователя, находящегося в заданном контексте". 

Ну, чем не джоули. 

 

[Xasima]

On Tue, Apr 17, 2012 at 10:05 PM, Ivan Mikhailov <iv_a...@yahoo.com> wrote:

Если серьёзно, то одной цифрой не обойтись, набирается целый список ортогональных свойств. Данных может быть много или мало, чистых или грязных, живых или редко обновляемых, связанных с LOD или нет, доступных через service endpoint или только в виде дампов... интересных или бесполезных. Разве что  померять "проблемности" по всем свойствам и перемножить --- но тогда на джоули и выйдем.

Спасибо, мне кажется, что все это верно, единственное, нужно поставить союз И. 

Например, проверить, для одной и той же организации, что через ее "сайт"

1) Доступны актуальные данные (непосредственно на сайте (REST + WADL + RDFa) или где-то в другом указанном месте)

2) Доступен дамп исторических данных за выбранный помежуток (непосредственно на сайте или где-то в заданном месте)

3) Доступны аналитические данные (в виде уже посчитанных данных в СSV и виде графиков с текстом в PDF документах)

4) Доступны используемые примитивные онтологии (хештег для твиттера, XMDP)

5) Доступны каналы мгновенного просмотра изменений (RSS/Atom, twitter)

6) Доступна возможность обогащения и коррекции данных (pull request / github), а также информация о лицензиях (microformats или какие правила) для  распространения данных (fork). 

7) Доступна возможность просмотра публичного ключа (pgp) ресурса 

8) Доступность описания существующих (популярных) услуг (вариантов использования) - OPML (??)

9) Доступность точки интеграции (SPARQL endpoint?) или места, где она расположена (например, сайт отрасли)

10) Доступность описаний (датасетов, точек) в крупных публичных поисковых  репозиториях (??datahub / индустриальные UDDI / google)

11) Доступность статистики использования самих сервисов (в т.ч.  датасеты с комментариями)

12) Доступность подключения к сервисам используя внешних или распределенных провайдеров (openid / oauth / webid)

Перемножение я вижу таким образом. 

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

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

Что-нибудь из списка выше  _совсем_ неприменимым (бесполезным) для произвольного публичного сайта из образовательного или государственного сектора?  Что еще следует добавить из набора "ортогональных" свойств ? Может _явно_  добавить QoS  и доверие? Явно добавить возможность версионирования  (сервиса, форматов, онтологии)?  На верхний уровень вывести категории (статистические, топологические, логические) для предоставляемых данных, запросов, аналитики? 

-- 

[Xasima]

Да, спасибо. Ниже возможные дополнения, как на них смотрите? 

On Tue, Apr 17, 2012 at 11:18 PM, Ivan Begtin <ibe...@gmail.com> wrote:

Технологические

- число ошибок выдаваемых валидаторами HTML и CSS

- число ошибок выдаваемых валидаторами по WCAG

- наличие мобильной версии сайта

- наличие версии для слабовидящих

Возможно стоит добавить такую экзотические возможности, как 

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

  - границы скорости отдачи важного контента. Если у нас сайт с информацией от МЧС, то границы скорости должны быть измеряны. 

 -  почему-то мне хочется сюда вписать и измерять SLA на скорость и механизмы отдачи важного контента под большой нагрузкой. Вопрос даже не в том, сможет ли сам сайт держать большую нагрузку, но в документированных процедурах, по которым, в случае нагрузки можно будет вывести упрощенный контент (с данными) на какие-то CDN / специализированный софт / ресурсы. Опять таки вспоминаются пиковые нагрузки на СМИ и МЧС сайты со списками пострадавших или новостями, что делать в заданной чрезвычайной ситуации. 

Проверять - выписанный SLA  (который для целевых систем как государственные, жизнеобеспечения, мчс должен быть или как  процентов 800 от существующей средней нагрузки или определенный другим способом от известных исторических нагрузок в заданном регионе). И соответственно в день X (с помощью соответствующего провайдера) проводить "тестирование устойчивости" (наподобии того, что делает ... фитч ? для банков). 

Открытые данные:

- публикация даных в форматах Semantic Web (RDF) (почти ни один сайт не будет этому соответствовать)

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

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

 

Содержательное:

- наличие контактов для обратной связи - email, телефон

- наличие информации об организационной структуре

- наличие информации о перечне нормативно-правовых документов согласно которым регулируется данный сайт

- наличие положения о сайте - для органа государственной власти

Иван, а в вашей "геополитической онтологии" есть какие-то наброски о возможном машинопонимаемом описание ссылок на орг.структуру, нормативные документы, "положения". В последних двух случаях хотя бы rel="" с правильными словами.