Продолжая тему про государственные информационные системы, мобильные приложения, передачу данных третьим сторонам. Рассмотрим одно мобильное приложение от Минцифры в подробностях.

Лидеры цифрового развития
Опубликовано в Google Play от Минцифры России [1], последний раз обновлялось 3 октября 2019 года.
В "политике кофиденциальности" указана ссылка на сайт самарской компании Eventicious [2] которая действительно, делает такие приложения для частного рынка и для разного рода госкомпаний по 223-ФЗ [3].

Особенность этих приложений в том что данные хранятся в России на серверах компании Ивентишес и тут возникает вопрос. А какой статус у этого приложения. Оно ГИС или не ГИС? Или оно часть услуги ? Если оно часть услуги, то почему приложение опубликовано от Минцифры РФ, если оно заказано как приложение (кстати, не могу найти контракт), то почему данные не хранятся на серверах Министерства или одного из его подведов?

К этим вопросам добавляется ещё один. В приложениях Eventicious есть код со ссылками на два сервиса за пределами РФ [4]. Это chat-prod.eventic.io с адресом в Ирландии и time.eventicious.com с адресом в Голландии.
—
А я напомню про наше исследование приватности в государственных мобильных приложениях [5] и ещё раз подчеркну что проблема чаще не в том что данные передаются за рубеж, а в двуличности государственной политики в этой области.

Ссылки:
[1] https://play.google.com/store/apps/details?id=ru.ddl
[2] https://eventicious.com/privacy/#ru
[3] https://clearspending.ru/supplier/inn=6311151902&kpp=631101001
[4] https://beta.pithus.org/report/23bd9b1823cfa48ef9f3ee5abb48f30ec3f5671f22e3059614690915967003c5
[5] https://privacygosmobapps.infoculture.ru/

#privacy #mobile #apps #digital

Регулярные полезные инструменты и ссылки для тех кто работает с данными регулярно:
- Data Connector [1] позволяет работать напрямую с Google таблицами из языка Python
- Process large datasets without running out of memory [2] - подборка статей о том как обрабатывать большие объёмы данных с помощью языка Python и без утечек в памяти
- MAD (for machine learning, AI and data) index [3] - индекс компаний по использованию машинного обучения, AI и данных, перекликается с большой картинкой/постером AI & Data Landscape 2020 [4]
- MC2 [5] - плафторма по аналитике и обработке зашифрованных данных безопасным образом. Да, такие задачи бывают, да, такое бывает необходимо.

Ссылки:
[1] https://github.com/brentadamson/dataconnector
[2] https://pythonspeed.com/memory/
[3] https://mattturck.com/madindex/
[4] https://46eybw2v1nh52oe80d3bi91u-wpengine.netdna-ssl.com/wp-content/uploads/2020/09/2020-Data-and-AI-Landscape-Matt-Turck-at-FirstMark-v1.pdf
[5] https://github.com/mc2-project/mc2

#data #tools

Вчера в интервью Росбалту [1] я постарался насколько возможно изложить все опасения по поводу того как данные собираются мобильными приложениям и в чём проблема регулирования/отсутствия регулирования в этой области.

Ох и сложно, конечно, выдерживать конструктивную критику, но я старался как мог.

Ссылки:
[1] https://www.rosbalt.ru/moscow/2021/04/13/1897113.html

#privacy #mobile

В рубрике интересные наборы данных слепок всех отчетов кредитных организаций в России о их бенефициарах собранный с сайта Банка России [1]. Формально эти документы называются "Список лиц, под контролем либо значительным влиянием которых находится кредитная организация", их публикует ЦБ РФ на страницах кредитных организаций. Например, на странице Сбербанка на сайте ЦБ [2], но там опубликован только последний файл со схемой, а в этом архиве все изменения за всё время с начала подобной отчетности. Например, код Сбербанка в ЦБ 1481 и в архиве есть документы о структуре бенефициаров с 2015 года.

Вот такой список файлов:
- RB1481_20150814.pdf
- RB1481_20180416.pdf
- RB1481_20190826.pdf
- RB1481_20200413.pdf
- RB1481_20200508.pdf
- RB1481_20200907.pdf
и так по всем кредитным организациям.

Формат наименования документов: RB[кодбанка]_[YYYddmm].pdf , пример RB3535_20200904.pdf

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

Получить список кодов банков можно на сайте ЦБ РФ по ссылке [3].

Не стесняйтесь обратной связи и идей как можно превращать эти PDF документы в машиночитаемые наборы данных.

А мы тем временем начинаем восстанавливать и ре-активировать Хаб открытых данных [4], это один из самых первых порталов открытых данных в России который я когда создавал под брендом OpenGovData (ещё в 2010-2011 годах). В последние годы мы больше усилий положили на общественный портал данных для НКО NGOData [5], но есть много данных которые в тематику НКО не укладываются и они будут появляться на хабе.

Ссылки:
[1] https://hubofdata.ru/dataset/bankbenef
[2] http://www.cbr.ru/banking_sector/credit/coinfo/?id=350000004
[3] http://www.cbr.ru/banking_sector/credit/FullCoList/
[4] http://hubofdata.ru
[5] http://ngodata.ru

#data #opendata #cbr #banking #ownership

Open Ownership, проект по разработке стандарта и публикации данных о бенефициарах юридических лиц, опубликовали доклад о применении данных о бенефициарах при процедурах госзаказа Beneficial ownership data in procurement [1]. Об этом же исследовании и его контексте в их блоге [2] и в блоге Data in Government [3] на государственном портале Великобритании gov.uk

Не случайно что эту инициативу упоминают и работают над ней именно в Великобритании. В декабре 2020 года был опубликован документ Transforming public procurement (Green paper) [4] для обсуждения с экспертами и профессионалами. В нём, на 82 страницах текста были изложены вопросы реформы государственного заказа, по итогам года с COVID-19, ситуаций описываемых в документе как "экстремальный кризис" и с необходимостью адаптации процедур государственных расходов под современные технологии и реалии. И вот в этом документе и явным образом есть упоминание на необходимость введения обязательного требования по раскрытию конечных бенефициаров компаний, вплоть до того чтобы это было отсекающим критерием для любой конкурентной процедуры. Не раскрыл сведения о бенефициарах - не можешь получать деньги от государства.

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

При этом, судя по развитию реформ государственного заказа по развитым странам, я бы оценивал высокой вероятность перехода стандартов Open Ownership и Open Contracting [5] в международный статус и постепенное внедрение их в рекомендации ОЭСР, Всемирного банка и иных межгосударственных организаций. Они и так уже есть в рекомендациях OGP и далее вопрос лишь времени в дальнейшем развитии.

Ссылки:
[1] https://www.openownership.org/uploads/OO%20BO%20Data%20in%20Procurement.pdf
[2] https://www.openownership.org/blogs/beneficial-ownership-data-in-procurement-beyond-transparency-and-accountability/
[3] https://dataingovernment.blog.gov.uk/2021/04/08/who-really-benefits-from-uk-business-ownership/
[4] https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/943946/Transforming_public_procurement.pdf
[5] https://www.open-contracting.org/

#opendata #opengov #procurement

Ещё один "мелкий нюанс" с новым реестром отечественного ПО [1] - это "гниение ссылок". Ссылки из старого реестра не открываются в новом заменой домена, а также при формировании ссылок в них указывается не номер программы в реестре, а на технический идентифкатор в базе данных. Вот пример: [2], код программы в реестре ПО 10269, а идентификатор в ссылке 330494 (reestr.digital.gov.ru/reestr/330494/). Такое вообще не редкость и бывает когда разработчики изначально не думают о пользователях. Я знаю десятки сайтов органов власти где подобное происходило неоднократно при замене CMS системы или создании нового сайта госоргана/госучреждения.

Эта проблема есть не только у госорганов. Например, в Великобритании достаточно давно, с 2017 года, обсуждают об создании постоянных ссылок для государственных документов [3] и рассматривают DOI в этом качестве. Казалось бы какая очевидная идея и можно было бы применять не только для цифровых документов, но "почему то", такие инновации внедряются с большим трудом и не только в государстве.

Но есть и примеры постоянных ссылок с момента появления организации. W3C имеет W3C URI Persistence Policy [4] с 1999 года и все опубликованные документы W3C всегда доступны по тем ссылкам что они были размещены.

Впрочем, надо отдать должное коллегам из Минцифры, экспорт в XML из реестра, наконец-то, заработал, что, отчасти снимает проблему устаревания ссылок поскольку в экспортированных данных есть уникальные идентификаторы ПО.  Но, счастье было бы полным, если бы экспорт в XML содержал _все_ данные по карточкам ПО, например, сейчас не экспортируются код ОГРН владельца ПО.

Кроме того, я напомню, в данных есть ошибки с реквизитами организаций. Сильно меньше чем в других госреестрах, но доли процента записей (около 10 невалидных кодов ИНН).

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

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

В остальном же лучше публиковать данные дампами на дату и создавать раздел "Открытые данные" и у этого есть 2 причины:
1. Так просто напросто удобнее в работе с данными которые меняются со временем. Пример похожей модели - это данные ФИАС где регулярные дампы в XML и DBF и всегда можно их сравнить
2. Некоторые криворукие разработчики делают экспорт данных динамическим. Когда таким образом экспортируется от 10 до 100 записей проблем не возникает. Когда идёт экспорт всего реестра - это гарантированный способ положить всю систему DDoS атакой. Кешировать данные для экспорта - это, также, подставка для кривых рук. Регулярные (ежесуточные/еженедельные) дампы и API - это правильное решение.

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

Ссылки:
[1] http://reestr.digital.gov.ru
[2] https://reestr.digital.gov.ru/reestr/330494/
[3] https://github.com/alphagov/open-standards/issues/75
[4] https://www.w3.org/Consortium/Persistence

#opendata #digital #registries

В рубрике интересных наборов данных, база монетарных мер центральных банков в исследовательской статье A global database on central banks' monetary responses to Covid-19 [1] и в виде Excel файла [2]. Материалы опубликованы на сайте банка международных расчётов (BIS) и является результатом мониторинга реакции центральных банков в виде 900 зарегистрированных событий от 39 банков.

Банка России нет в этом списке, но много других есть и сама база полезна для исследователям COVID-19 и реакции на него.

Ссылки:
[1] https://www.bis.org/publ/work934.htm
[2] https://www.bis.org/publ/work934_data.xlsx

#opendata #datasets

Я не люблю комментировать политику и политические решения, но, конечно, по поводу последних санкций США против нескольких не самых больших и известных российских ИТ компаний могут показаться довольно странными. Не крупнейшие компании, не так много взаимодействующие с контрагентами за рубежом, ну и ещё немало вопросов. Вот и в MIT Technology Review пишут об этом [1], несколько раз упоминая Kaspersky (Лаборатория Касперского) и упоминая их предыдущий инцидент в США и работу с правительствами многих стран. Намёк более чем прозрачен и похоже что эти санкции в США специально проведены по модели "давайте вломим по не самым важным и крупным, чтобы остальные заполошились и побежали договариваться". Так часто делают, во многих делах, меры против не самых крупных лоббистов принимаются не по причине их веса, а чтобы "открыть кассовую комнату"  куда побегут лоббисты и нанятые GR специалисты.

Хуже то что власти в США реально могут похоронить ИТ бизнес/ИТ рынок в России не только через санкции на компании, но и через запрет участие российским компаниям в технологических экосистемах в их юрисдикции. Это всё достаточно серьёзно и, честно говоря, я не понимаю что с этим можно будет сделать потому что госполитика в части поддержки российского бизнес/цифровых платформ была, если честно, хреноватая.  

Больше всего у меня вызывает опасения что если США наложат санкции на крупнейшие российские цифровых холдинги, то российская модель развития Интернета и рынков связанных с цифровой пойдёт по пути буквальной чоболизации, официальной  и законодательно закреплённой отдаче отдельных рынков в монополии корпораций доходы которой резко просядут.

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

Ссылки:
[1] https://www.technologyreview.com/2021/04/15/1022895/us-sanctions-russia-positive-hacking/

#digital

Обновилась документация, появился новый портал с документацией [1], по проекту Frictionless Data. Теперь там довольно удобно собраны примеры, описания и руководства по работе с этим фреймворком. Лично я уделяю ему столько внимания потому что на сегодняшний день - это одна из наиболее продуманных инициатив с открытым кодом по стандартизации наборов данных.

Альтернативы ему, или коммерческие, с централизованными реестрами/репозиториями такими как QRI, или узкоспециализированные под академическую работу - RO-CRATE или под архивацию цифровых объектов такие как BagIt.

Но, конечно, есть и множество альтернатив: DataCrate [2], BioCompute [3], стандарты RDA [4], стандарты Force11 [5], CodeMeta [6] и многочисленные стандарты публикации данных и метаданных используемые на национальном уровне и в рамках отдельных отраслей (биоинформатика, лингвистика и тд).

Впрочем большая часть стандартов, всё же, про научную сферу, а Frictionless Data про общепринятую. Ещё год-два и публиковать данные в виде "голого" CSV или XML файла будет неприличным. Упакованные данные куда ценнее и пригоднее к работе.

Ссылки:
[1] https://framework.frictionlessdata.io
[2] https://github.com/UTS-eResearch/datacrate
[3] https://github.com/biocompute-objects/BCO_Specification
[4] https://rd-alliance.org/
[5] https://www.force11.org/
[6] https://codemeta.github.io/

#opendata #data #standards

The Verge пишет о запрете в Евросоюзе на применение ИИ для массовой слежки и систем социальных кредитов [1]. Причём, ожидаемо, новое регулирование будет экстерриториальным, с оборотными штрафами и прочими подходами уже опробованными в GDPR. Подробнее об этом в материалах Politico [2], которые и раздобыли черновик регулирования.

Это регулирование сильно отличается от того что происходит в этой теме в США или в Китае, много аргументов про инновации и не только.

Если говорить про экономику, да, такие ограничения сдержат часть инноваций. Но если говорить про смысл, то не все инновации одинаково полезны. Можно приравнять ИИ в массовой слежке к опытом на людях. Да, запрет опытов над людьми тоже сдерживает инновации, но может оно и неплохо?

Ссылки:
[1] https://www.theverge.com/2021/4/14/22383301/eu-ai-regulation-draft-leak-surveillance-social-credit
[2] https://www.politico.eu/article/europe-strict-rules-artificial-intelligence/

#ai #data #regulation #eu

В 2020 году в России было зарегистрировано 605.5 тысяч ИП и ликвидировано 947.5 тысяч ИП, зарегистрировано 232.1 тысячи юридических лиц и ликвидировано 545.6 тысяч юридических лиц. Это наибольшее число ликвидаций ИП с 2012 года, наименьшее число регистраций ИП с 2014 года и наименьшее число регистраций юридических лиц с 2012 года.

Причин может быть множество:
- снижение деловой активности на время COVID-19
- ухудшение экономической ситуации
- ограниченный режим регистрации ИП и юридических лиц и ограничения в сроках приёма в налоговых органов
А может быть и что-то ещё.

В рубрике "полезные наборы данных", актуализированный набор данных временных рядов налоговой статистики [1] регистрации юр. лиц и индивидуальных предпринимателей.
Набор данных включает:
- данные статистики по субъектам федерации в виде временных рядов
- данные статистики по субъектам федерации по годам и индикаторам
- данные статистики по Российской Федерации (агрегировано)
- первичные данные с сайта ФНС России в формате Excel файлов
- исходный код для обработки Excel файлов и генерации файлов статистики

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

Объём данных небольшой, но полезный в рамках исследований по COVID-19 и деловой активности в принципе.

Ссылки:
[1] https://hubofdata.ru/dataset/nalogstats-timeseries

#opendata #datasets #statistics

В рубрике интересные наборы данных (за рубежом). Национальное управление архивов и документации США опубликовало два больших набора данных на инфраструктуре Amazon AWS. Это национальный архивный каталог [1] и данные переписи 1940 года [2].

Национальный архивный каталог - это база из 225 гигабайт с описанием 127 миллионов цифровых объектов
Перепись 1940 года - это 15 терабайт включающих метаданные к 3.7 миллионам сканированных документов и сами документы с описанием переписных листов, карт переписи и так далее.
Обо всём этом подробнее в блоге NARA [3]

Надо отдать должное Amazon, в их реестре открытых данных [4] всего 233 набора, довольно скудные метаданные по ним, но все эти наборы и базы данных огромного размера и востребованные аудиторией для которых они публикуются.

Ссылки:
[1] https://registry.opendata.aws/nara-national-archives-catalog/
[2] https://registry.opendata.aws/nara-1940-census/
[3] https://aotus.blogs.archives.gov/2021/04/15/nara-datasets-on-the-aws-registry-of-open-data/
[4] https://registry.opendata.aws/

#opendata #datasets #archives #usa #amazon #aws

Я уже написал несколько лонгридов в рассылку [1] о том как собирать, анализировать и описывать данные. Но, всё время чувствую что недостаточно раскрываю эту тему.
Управление метаданными не такая сложная штука в концептуальном смысле, но тяжело ложится в логику российского планирования. Потому что метаданные к данным, документация, хорошо описанный код, пометки к исследованиям, просто заметки к своей работе - это всё культура помнить о себе и других не только в моменте, а в будущем, через много лет. Обычно к этому приходят, или с годами, особенно когда сталкиваются с невозможностью разобрасться с чужими или собственными документами/кодом/данными и тд. многолетней давности, или через культуры среды, например, воспроизводимость исследований - это часть культуры и принципов работы исследователей. Кто-то трактует это узко - возможность воспроизвести в коротком промежутке времени, а кто-то как возможность воспроизвести исследование и через 20 лет.

Управление метаданными - это именно вопрос стратегического понимания зачем данные или иные цифровые объекты создаются.

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

Научные архивы отличаются тем что, с одной стороны, они "ближе к земле", а с другой требуют всё того стратегического подхода. Поэтому есть десятки стандартов метаданных по отраслям: лингвистика, биоинформатика, генетика, метеорология и тд.
Но научные архивы напрямую связаны с таким понятием как "воспроизводимость исследований", а в современном мире технологических исследований - это "воспроизводимое вычислительное исследование" (reproducible computational research, RCA). А особенность таких исследований что не только данные нужны, но и методика и все инструменты. А эти инструменты могут быть как жёстко проприетарными (и как тогда воспроизводить?) так и самописными и во всех случаях для них необходимо воссоздание необходимой среды.  Вот очень полезная статья о роли метаданных для RCA, оттуда новый термин "капитал метаданных" (metadata capital) - это вложения организации в создание высоко-качественных метаданных для своих данных.

Отдельно можно поговорить про данные в корпоративных каталогах, а вернее системах управления данными (data management systems) и в каталогах данных для ИИ или иных каталогов данных особенно большого размера. Корпоративный мир предельно практичен. К наборам данных добавляются лишь критически значимые метаданные, те же каталоги Kaggle, Amazon Open Data или открытые данные Azure - радикально минималистичные. А вот внутрикорпоративные каталоги для data science наоборот, часто весьма детальные, но с чётким акцентом на data discovery (находимость данных) в достаточно ограниченном промежутке времени.  

Во всех случаях важно помнить что метаданные - описание наборов данных, артефактов кода, иных цифровых объектов это совсем недёшево, не с точки зрения денег, а с точки зрения трудозатрат и времени. Качество метаданных - это первая ступень анализа качества любого каталога/реестра/перечня данных, его можно мониторить автоматизировано, но по результатам мониторинга его надо и исправлять.

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

Ссылки:
[1] https://begtin.substack.com
[2] https://arxiv.org/ftp/arxiv/papers/2006/2006.08589.pdf

#metadata

Главная проблема большей части утечек личных данных именно в сопоставлении. Даже сопоставление десятка баз по email адресам может дать очень много инсайтов. Неприятных инсайтов(

Что и требовалось доказать. Уже стали появляться обогащенные базы сторонников Навального :-( "Да там просто e-mail и ничего больше", - говорили они. Ага, щазззз. Сейчас еще смапят в утекшую базу LovePlanet и вперед :-) pic.twitter.com/B5zazapYT7
— Alexey Lukatsky (@alukatsky) April 19, 2021

Лично я не то чтобы удивился по поводу новости о том что НИИ Восход просит субсидию на локализацию SAP [1] и том что это нужно «Ростех», «Росатом» и ОАО РЖД и тд., а просто до сих пор не могу прийти в себя. SAP - это очень специфическая платформа, прям даже сказать "очень" - это ничего не сказать. Это вещь в себе и не случайно практика SAP есть в нескольких крупных интеграторах и точно не в НИИ Восход, там такое просто не могло никогда появиться в виду специфики работы подведа Минцифры и отсутствия SAP в Минцифре и в ФОИВах (и других органах власти) как явления.

Тут всё очень просто, на самом деле, когда РЖД, Росатому или Ростеху что-то надо - они сами это делают и у них есть на это деньги, ресурсы, люди или компетенции. При всём желании я не поверю что у Росатома меньше ИТ компетенций и так далее по всем госкорпорациям по списку.

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

Ссылки:
[1] https://www.kommersant.ru/doc/4780864

#it #russia

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

🔎 Поиск пунктов вакцинации теперь доступен в «Яндекс.Картах». «Жители любого города смогут найти адрес, контакты и время работы ближайшего пункта, а также построить до него маршрут», — уточнили в компании.

📱Нужно вбить ключевые фразы (например «вакцинация» или «где сделать прививку») в поисковой строке. Более 4,5 тыс. текущих точек будут дополняться совместно с Минздравом.

💉 Напоминаем, массовая вакцинация в России началась 18 января. Сегодня в стране зарегистрированы три препарата: «Спутник V», «ЭпиВакКорона» и «КовиВак». Привиться можно в государственных или частных медучреждениях.

⚡️ Больше новостей по актуальной теме вакцинации читайте на вакцина.стопкоронавирус.рф и будьте здоровы. Позаботьтесь о себе и близких, запишитесь на прививку по ссылке.вакцина.стопкоронавирус.рф и будьте здоровы. Позаботьтесь о себе и близких, запишитесь на прививку по ссылке.

#стопкоронавирус #здоровьевприоритете #coronavirus

Может ли мягкий искусственный интеллект приносить повседневную пользу? Да, например, один энтузиаст прикрутил OpenAI к командной строке в Linux и написал об этом подробно [1] и заснял видео [2]. Если вкратце, то автор сделал надстройку над терминалом Linux и с помощью OpenAI научился транслировать задачи написанные на естественном языке в команды Shell.

Конечно, далеко не всё распознаётся как хотелось бы и всё это куда больше похоже на забавный эксперимент, но... не стоит недооценивать развитие технологий. В самых очевидных, полуавтоматизированных задачах применение OpenAI и других AI технологий может дать интересный результат. Например, написать текст на основе синопсиса, нарисовать эскиз веб-приложения из текстового описания, рисовать картину со слов человека и ещё многое другое.  

Ссылки:
[1] https://riveducha.onfabrica.com/openai-powered-linux-shell
[2] https://www.youtube.com/watch?v=j0UnS3jHhAA

#ai #tools #shell #linux

В рубрике интересных наборов данных, база Web Data Commons - Schema.org Table Corpus [1] j опубликованный 29 марта 2021 года командой Web Data Commons [2], проекта Университета Манхейма. В наборе данных 4.2 миллиона таблиц в виде данных в формате schema.org [3] извлечённых из веб-страниц Common Crawl.

Исходный код экстрактора данных данных также доступен [4].

Хороший проект, интересные результаты, и реальная польза от Common Crawl как гигантской базы данных веб-страниц на основе которой проводятся многочисленные исследования. А для разного рода коммерческих проектов по агрегации данных это всё может быть интересным источником вдохновения.

Ссылки:
[1] http://webdatacommons.org/structureddata/schemaorgtables/
[2] http://webdatacommons.org/
[3] https://schema.org/
[4] http://webdatacommons.org/framework/index.html

#opendata #data #web #crawl