Ipfs: IPFS-LD — связанные данные

Привет, @jbenet , отличная работа с IPFS, очень интересно, что вы делаете, поскольку мы изучаем использование DHT (аналогично Kademlia) + цифровые подписи + сеть запросов для замены именования в Интернете (в конечном итоге замените DNS). Основная работа, которую мы делаем, близка к тому, что вы делаете с IPFS: https://manu.sporny.org/2014/identity-credentials/ . Мы используем JSON-LD для этой инициативы, вы знаете о Telehash? Если нет, вам следует взглянуть, поскольку некоторые из этих концепций могут усилить IPFS.

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

Просто мысли, если будут вопросы, спрашивайте. Требование @context в каждом большом двоичном объекте JSON в сети не является серьезным требованием.

спасибо за мысли!

мы изучаем возможность использования DHT (подобного Kademlia) + цифровых подписей + сети запросов для замены именования в Интернете (в конечном итоге заменить DNS).

Затем обязательно ознакомьтесь с разделом IPNS в документе: http://static.benet.ai/t/ipfs.pdf (3.7). :)

Вы знаете о Телехэш?

Да, я очень одобряю общую концепцию + стремлюсь ее построить, но не поддерживаю многие решения проекта. Например, слоган «JSON + UDP + DHT = свобода», но я думаю, что такие системы не должны (а) не навязывать формат данных, (б) не навязывать транспортный протокол и (с) не навязывать система маршрутизации. Конечно, эти три варианта — отличный выбор _сегодня_, но эти протоколы должны быть построены таким образом, чтобы они подходили для разных уровней и времени. Таким образом, IPFS позволяет пользователям использовать любой желаемый формат, IPFS может накладываться поверх любого транспорта, и хотя первой системой маршрутизации будет DHT, есть и другие, которые нужно изучить.

Вы можете видеть IPFS как Telehash + (merkle) Web.

если вы хотите, чтобы метаданные в сети были машиночитаемыми и обрабатываемыми, но расширяемыми, вам следует использовать JSON-LD.

Я думаю, что мы можем взять на себя часть -LD вашей работы, не требуя JSON в качестве транспорта. Т.е. я думаю, что ваша (замечательная) работа обобщается на любую древовидную структуру данных и намного лучше, чем другие семантические веб-форматы. (удивительная простота + гибкость!) Итак, в этих заметках я указываю на использование эквивалента @context , но в структуре данных ссылок IPFS (которая не является JSON, это двоичный упакованный формат для быстрого поиска по объектам). -- protobuf сегодня, но может быть и самоописывающим позже -- я рассчитываю, что IPFS будет достаточно быстрой для работы в качестве базы данных не сегодня, а в будущем :) ).

Требование @context в каждом большом двоичном объекте JSON в сети не является строгим требованием.

Ага, я так же рассуждал :)

@jbenet re: https://github.com/dataprotocols/dataprotocols/issues/110#issuecomment -43430309 - да, я думал, что ваши аргументы очень хороши и хорошо информированы.

Мне очень интересно, чем вы занимаетесь, я просмотрел газету и начал смотреть ваше видео. К сожалению, у меня есть дедлайны, которые я должен выполнить сегодня, но прочтение вашей статьи и просмотр всего видео в моем списке дел. Не знаю, знаете ли вы об этом, но я работаю над созданием стандартов для Интернета через W3C. Прямо сейчас у нас есть ряд проблем, требующих решения, подобного тому, которое вы описываете. Я хочу посмотреть, сможем ли мы интегрировать некоторые из ваших разработок в стандартное решение входа в систему W3C следующего поколения, над которым мы работаем для Интернета (сообщение, о котором я упоминал выше). В настоящее время мы используем Telehash, но у нас есть некоторые проблемы с ним, и вы, похоже, разложили проблему таким образом, чтобы она лучше подходила для наших вариантов использования.

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

Привет, @jbenet , у меня была возможность более подробно просмотреть технический документ на выходных, а также посмотреть вашу презентацию. Давайте назначим время для разговора на следующей неделе. Я на восточном побережье США. Доступно с 10:00 до 14:00 в большинство дней, кроме вторника и среды. Моя электронная почта: [email protected] , Skype: msporny, SIP: sip:[email protected] Свяжитесь со мной при первой же возможности.

Я хотел бы обсудить ipns и это wrt. вход в Интернет, учетные данные и веб-платежи: https://manu.sporny.org/2014/identity-credentials/

@msporny отлично! Сделаю. Только что отправил электронное письмо для сенсорной базы. Возможно, вы захотите удалить свои контактные данные из этой задачи (поскольку она общедоступна и т. д.).

Сегодня мы обсуждали, как ответить на вопросы «что это за объект?» в IRC. @jbenet упомянул ссылки в стиле LSON-LD @type или @context , но я не уверен, как вы вырветесь из этой цепочки . Это @context ссылки вниз? @tv42 также выразил обеспокоенность по поводу коллизий с именами файлов , поскольку узлы каталогов используют имена дочерних сегментов в качестве своих ключей. Вы можете обойти это, добавив префикс или иным образом экранировав имена сегментов, но это кажется более трудоемким, чем просто добавление явного поля Type для хранения хэш-идентификатора для описания типа . Если мы ожидаем большего от такого рода вещей, возможно, это просто требует разделения ссылок на внутренние и внешние наборы. Вы можете сделать это с помощью предложенного @jbenet подхода расширения Link protobuf (если это станет чем-то важным), добавив «внутреннее» логическое значение, чтобы отделить запись типа @context от любых записей файла @context ( Например).

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

объект ipfs представляет собой дерево, такое как json или что-то еще. это означает, что все решения, доступные для JSON (включая JSON-LD, схему JSON и т. д.), доступны для IPFS. более того, тривиально представить тройки RDF как объекты ipfs. следовательно, вы можете делать что угодно и что угодно.

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

теперь _предпочтительный_ способ — способ, которым мы будем предлагать людям что-то делать — скорее всего, будет @context / @type из (удивительно мощного и простого) JSON-LD.

но я не уверен, как ты вырвешься из этой цепи

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

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

если в структуре данных dir уже есть @context , это не позволит создать другой файл -- (или, в худшем случае, добавить ссылку после (стабильная сортировка)). это то же самое, что пытаться создать два файла с одинаковым именем.

В пятницу, 1 мая 2015 г., в 03:51:22 -07:00, Хуан Батиз-Бенет написал:

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

Расширения ссылок должны работать нормально. И префикс ключей ссылок к
namespace у них тоже не так уж и плохо. Заполнение информации о типе
в данные тоже работает (так теперь работают файлы и каталоги
[1,2,3,4,5]). Перечисление типов не является устойчивым подходом, но
любое из этих мест будет работать как место для хранения хэша типа.

теперь _предпочтительный_ способ - способ, которым мы будем предлагать людям делать что-либо
-- скорее всего, будет @context / @type из
(удивительно мощный и простой) JSON-LD.

JSON-LD — это хорошо, но экосистема вокруг него должна понимать
что @-префикс особенный. Я бы предпочел, чтобы особенность сохранялась
явно, расширив записи Link дополнительными данными (например,
внутренний/внешний флаг), поэтому у нас нет двусмысленности между @context
файл и ссылку типа @context . Но если все ссылки на файлы/подпапки имеют ключ
с ребенком/', тогда у вас может быть 'контекст' для типа
ссылка и «дочерний элемент/контекст» для файла (или что-то еще). это все еще происходит
должно быть внешне определенным соглашением, что генераторы объектов
и потребители должны согласиться через канал без самоописания.

но я не уверен, как ты вырвешься из этой цепи

я не понимаю вопроса. цепи нет, ты решаешь
контекст один раз и все. это файл контекста для
объект. если это неверный контекст -- есть спецификация -- вы
игнорируй это.

Это подходит для меня. Мне было интересно, как вы заканчиваете самоописание
цепь:

Какой тип А? Давайте просто перейдем от A/ @context к B. Что такое B?
Давайте просто перейдем от B/ @context к C…

Но если вы распространяете спецификацию B (в моем примере C), нет
нужна ссылка B/ @context . Но если у вас есть канал для
распространение спецификации типа (C), почему бы также не использовать ее для распространения
сами схемы типа (B)? Кажется, что лучше просто иметь
обычное место в объектах, которое содержит мультихэш, описывающий их
тип (ваша ссылка @context или что-то еще). Тогда уйди с дороги и
оставить это на усмотрение сообществ производителей/потребителей, чтобы решить, является ли это
ссылка на определение типа (может быть, в спецификации C, или Cv2, или
альтернатива CCv1.3 или …), или если они просто хотят использовать мультихэш как
непрозрачный идентификатор. Тогда вы все еще можете делать такие вещи, как:

переключатель pbn.GetType() {
case ft.TDirectory:
root.val = NewDirectory(pointsTo.String(), mnode, root, fs)

просто GetType будет захватывать хэш @context Link (или
куда угодно), а TDirectory будет мультихэшем.
(QmWellKnownDirectoryType).

приложения не должны _зависить_ от правильности этих типов, но
скорее используйте их, когда они есть.

Это звучит как непрозрачный идентификатор. Может быть, мы говорим то же самое
предмет ;).

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

если структура данных dir уже имеет @context , это не позволит
создание другого файла -- (или, в худшем случае, добавление ссылки после
(стабильный сорт)). это то же самое, что пытаться создать два файла с
то же имя.

Это если вы хотите сделать файлы @context незаконными;). Если вы хотите
разрешить людям создавать файлы @context , вам понадобится какой-то способ
устранить неоднозначность между «эта ссылка указывает на тип» и «эта ссылка
указывает на файл/подкаталог/…». Но есть несколько способов
вокруг этой проблемы, так что если мы выберем одну из них, я буду счастлив
;).

Несколько дней назад у меня был разговор с @cryptix , и мы вкратце обсудили использование JSON-LD. Я просто хотел бы отметить, что спецификация для json-ld позволяет использовать «ссылку» для описания сопоставлений из json в json-ld. Я лично предпочитаю этот подход, потому что он позволяет метаданным быть совместимыми с json-ld без реструктуризации их для любой разновидности RDF, которая в настоящее время является «модной».

http://www.w3.org/TR/json-ld/#interpreting-json-as-json-ld

В пятницу, 1 мая 2015 г., в 21:24:27 -07:00, У. Тревор Кинг написал:

Расширения ссылок должны работать нормально. И префикс ключей ссылок к
namespace у них тоже не так уж и плохо. Заполнение информации о типе
в данные тоже работает (так теперь работают файлы и каталоги
[1,2,3,4,5]). Перечисление типов не является устойчивым подходом, но
любое из этих мест будет работать как место для хранения хэша типа.

В соответствующей заметке (распространение идентификаторов хешированных типов вместе с
payload), @tv42 только что привлек мое внимание к Ethos ETypes [1,2,3]. Так
Я думаю, что наличие какого-то явного слота для этих вещей было бы
отличный.

Не видел ETypes, спасибо за всплытие. будет читать в течение следующих нескольких дней. Что-то важное связано с работой Кэтлин Фишер с PADS. Страница проекта PADS, кажется, была недавно изменена (если бы только было какое-то неизменяемое хранилище с адресацией по контенту в Интернете...). (Но снова нас спас интернет-архив \o/: http://web.archive.org/web/20130125041549/http://www.padsproj.org/ )

• PADS: предметно-ориентированный язык для обработки специальных данных.
• Проект PADS: обзор
• PADS/T: язык для описания и преобразования специальных данных
• PADS/ML: язык описания функциональных данных
• LearnPADS: автоматическое создание инструментов на основе специальных данных
• дополнительные документы : http://web.archive.org/web/20120205185831/http://www.padsproj.org/doc.html#papers

В любом случае, у PADS очень правильная идея. но до сих пор не видел широкой реализации, о которой я знаю. возможно, есть что-то в стиле JSON-LD, что может исправить это здесь.

JSON-LD — это не просто добавление ссылки @context . В частности, каждое имя ссылки (ключ в формате JSON) должно относиться к одной из следующих категорий:

• @context : контекстная ссылка или встроенный узел, описывающий данные.
• @id : URI текущего узла
• схема://full-uri : распознается как ссылка, предикатом которой является URI.
• prefix:name : распознается как ссылка, предикат которой является конкатенацией префикса URI (определенного в контексте) и имени
• имя: распознается как ссылка, только если определено в контексте

В частности, JSON-LD, похоже, не поддерживает произвольные карты ключей/значений. Если ключ можно интерпретировать как URI, он будет считаться предикатом, использующим этот URI. Например, следующее неверно:

{
  "http://xmlns.com/foaf/0.1/name": "<!DOCTYPE html><html><body><p>Hello World</p></body></html>"
}

поскольку http://xmlns.com/foaf/0.1/name всегда будет ссылаться на имя FOAF, а не на кешированную версию веб-страницы.

Это не обязательно проблема, но ее следует учитывать, если мы решим интерпретировать ссылки как связанные данные при разработке форматов объектов. Например, каталог можно представить таким образом, используя JSON-LD:

{
  "@context": {
    "entry": {
      "@id": "http://schema/unixfs#entry",
      "name": "http://schema/unixfs#filename",
      "content": {
        "@id": "http://schema/unixfs#filename",
        "@type": "@id"
      }
    }
  },
  "entry": [
    {
      "name": "README.md"
      "content": "/ipfs/<hash-of-README.md>"
    }
  ]
}

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

Это добавляет несколько уровней косвенности, которые приемлемы для документов JSON (поскольку все упаковано в один файл), но могут быть неприемлемы для IPFS, где каждый узел имеет свой хэш и должен отслеживаться отдельно.

Возможно, мы хотим не использовать JSON-LD как есть, а определить собственный формат контекста, вдохновленный JSON-LD. Это было бы лучше, потому что наш формат не JSON и очень специфичен: мы хотим иметь возможность описывать произвольные карты ключей (для unixfs), и мы также хотим использовать раздел данных наших объектов IPFS (JSON не имеет этого ).

Поскольку раздел ссылок объектов IPFS очень ограничен, ссылки имеют имя и указывают на другой объект. Он не может содержать буквенные значения. Что нам нужно указать в контексте, так это полное имя ссылки в форме URI. Поскольку у нас также есть раздел данных, нам нужно определить, что он содержит.

Для unixfs я бы представил следующие объекты:

• directory :
  
  
  
  • ссылка @context , указывающая на контекст каталога
  
  
  • ссылка entry:README.md , указывающая на объект README.md
  
  
  • нет данных
  
  
• README.md :
  
  
  
  • ссылка @context , указывающая на файловый контекст
  
  
  • раздел данных с содержимым README.md
  
  
• каталог-контекст:

```
{
// @type : тип объекта IPFS
"@type": " http://schema/unixfs#Directory "

// entry: declares the links starting with "entry:"
//   <strong i="38">@id</strong>: the relationship with the pointed object
//   <strong i="39">@key</strong>: the relationship with the link name suffix (after ':')
"entry": {
  "@id": "http://schema/unixfs#containsEntry",
  "@key": "http://schema/unixfs#hasFilename"
}

}
```

• файл-контекст:

```
{
"@type": " http://schema/unixfs#Файл "

// <strong i="50">@data</strong>: the relationship with the data section of the object
"@data": "http://schema/unixfs#content"

}
```

Если бы мы хотели представить это в тройках, мы бы имели:

# Contained in directory object:
<hash of directory>        <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://schema/unixfs#Directory>
<hash of directory>        <http://schema/unixfs#containsEntry>              <hash of README.md object>
<hash of README.md object> <http://schema/unixfs#hasFilename>                "README.md"

# Contained in README.md object:
<hash of README.md object> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://schema/unixfs#File>
<hash of README.md object> <http://schema/unixfs#content>                    DATA SECTION of README.md

Привет @mildred - отличный анализ. Как ни странно, я пришел к тем же выводам в разговоре с dlongley в irc://irc.frennode.org#json -ld (могу прислать вам логи, если интересно)

Я немного поэкспериментировал с более разрешительным типом IPLD здесь - в частности, см. примеры. они не являются окончательными (или правильными?), но дают представление о направлении

• https://github.com/ipfs/go-ipld
• https://github.com/ipfs/go-ipld/issues/1
• https://github.com/ipfs/go-ipld/blob/master/ipld.go#L57 -L89
• https://github.com/ipfs/go-ipld/blob/master/examples/commit/commit.go#L10 -L15 (игнорируйте использование @value , это неверно)
• https://github.com/ipfs/go-ipld/blob/master/examples/sig/sig.go#L14 -L16
• https://github.com/ipfs/go-ipld/blob/master/examples/unixfs/unixfs.go#L16 -L18

Важные заметки:

• расслабляющие ссылки на _разрешить_ включение других значений (очень востребовано), мы оставляем за собой только {"@type": "mlink", "hash": "<multihash>"}
• пользователи могут определять контексты для своих структур данных
• может _вкладывать_ ссылки, используя обозначение пути для перехода, например, https://github.com/ipfs/go-ipld/blob/master/ipld.go#L122 -L141

Я думаю, вы и я на правильном пути. Я также думаю, что мы, вероятно, можем сделать многое из этого, не сильно отклоняясь от JSON-LD. просто снятие некоторых ограничений

@mildred регистрируется здесь

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

Я думаю, вы устраните большую путаницу, если будете думать о JSON-LD с точки зрения сгенерированных троек, а не о том, что делает синтаксический анализатор json-ld.js при преобразовании JSON. Шаг преобразования JSON специфичен для этого синтаксического анализатора, и вы можете легко представить его другим способом без проблем.

Теперь, если я хорошо понимаю, что вы делаете с go-ipld , он может заменить раздел Link в текущих объектах IPFS, верно? Эта вещь: merkledag.proto

Я вижу проблему там. Там, где раньше у нас была простая структура, позволяющая эффективно обрабатывать (имя ссылки, непосредственно связанное с путем и хэшем ссылки), теперь у нас немного более сложная структура. Чтобы получить связанный хеш, вам нужно разрешить строку «mlink» в хеш-таблице. это действительно необходимо?

Если вам нужны связанные данные / RDF, почему бы просто не определить свой собственный формат проводов (на мой взгляд, protobuf великолепен) и способ, которым его можно перевести в JSON. Затем используйте контекст JSON-LD поверх этого.

Теперь о другой структуре данных, о которой вы подумали, я думаю, что они великолепны, за исключением unixfs: у нас не может быть имен файлов в качестве ключей JSON-LD, потому что ключи JSON-LD должны при любых обстоятельствах ссылаться на предикаты RDF. Имя файла является буквальным значением.

Вместо:

{
  "@context": "/ipfs/Qmf1ec6n9f8kW8JTLjqaZceJVpDpZD4L3aPoJFvssBE7Eb/merkleweb",
  "foo": {
    "@type": "mlink",
    "@value": <multihash>,
    "unixType": "dir",
    "unixMode": "0755",
  },
  "bar.jpeg": {
    "@type": "mlink",
    "@value": <multihash>,
    "unixType": "file",
    "unixMode": "0644",
  }
}

Я бы смоделировал это как:

{
  <strong i="16">@context</strong>: {
    "ipfs":   "tag:ipfs.io,2015:ipfs:"
    "unixfs": "tag:ipfs.io,2015:unixfs:"
  }
  <strong i="17">@type</strong>: "unixfs:directory"
  "unixfs:contains": [
    {
      "@id":   "ipfs://<IPFS Hash>"
      "@type": ["unixfs:directory"]
      "unixfs:name": "foo"
      "unixfs:mode": "0755"
    },
    {
      "@id":   "ipfs://<IPFS Hash>"
      "@type": ["unixfs:file"]
      "unixfs:name": "bar.jpeg"
      "unixfs:mode": "0644"
    }
  ]
}

Опять же, двоичная/сериализованная версия не должна быть такой. Способ представления этой последней записи в виде рубцов RDF будет следующим:

DIRECTORY              <tag:ipfs.io,2015:unixfs:contains> <ipfs://Hash:foo>
DIRECTORY              <tag:ipfs.io,2015:unixfs:contains> <ipfs://Hash:bar.jpeg>
<ipfs://Hash:foo>      <strong i="21">@type</strong>                              <tag:ipfs.io,2015:unixfs:directory>
<ipfs://Hash:foo>      <tag:ipfs.io,2015:unixfs:name>     "foo"
<ipfs://Hash:foo>      <tag:ipfs.io,2015:unixfs:mode>     "0755"
<ipfs://Hash:bar.jpeg> <strong i="22">@type</strong>                              <tag:ipfs.io,2015:unixfs:file>
<ipfs://Hash:bar.jpeg> <tag:ipfs.io,2015:unixfs:name>     "bar.jpeg"
<ipfs://Hash:bar.jpeg> <tag:ipfs.io,2015:unixfs:mode>     "0644"

Я в IRC, не стесняйтесь пинговать меня там.

Для тех, кто не знаком с RDF в этой теме, вот небольшое пояснение:

RDF — это способ структурировать ваши данные. это модель данных, лежащая в основе JSON-LD. В RDF все данные должны быть закодированы триплетами:

<subject> <predicate> <object>

• Субъект — это узел, который идентифицируется URI
• Предикат — это URI, например <http://www.w3.org/1999/02/22-rdf-syntax-ns#name> . URI однозначно определяет отношение и желательно должен быть четко определен в спецификации или схеме.
• Объект является целью ссылки/предиката. Это может быть буквальное значение (строка, которую можно ввести, например, как целое число или дату, обычно полученную из схемы xsd), или это может быть другой узел, идентифицируемый своим URI.

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

Ключи JSON в JSON-LD — это предикаты, связывающие субъект (объект, в котором присутствует ключ) и объект: значение ключа JSON-LD. В этом случае URI не используются для ссылки на субъект и объект. Если вы хотите указать URI объекта, который можно использовать для ссылки на него, существует свойство @id .

Есть ли где-нибудь запись, объясняющая, как работают связанные данные через IPFS по сравнению с тем, как они работают через HTTP? (На что похожи URI? Какими должны быть передовые методы для издателей и потребителей связанных данных через IPFS?)

Видеть:

• https://github.com/ipfs/specs/pull/37
• https://github.com/ipfs/specs/blob/ipld-spec/merkledag/ipld.md

IPLD предоставляет вам модель данных json. вы можете наложить любой JSON-LD поверх IPLD.

(еще не приземлился)

@jbenet только что прочитал эту ветку, использование связанных данных - отличная инициатива, ИМХО

Вы правы в том, что связанные данные не требуют какой-либо сериализации. Можно использовать JSON-LD, RDF/XML, RDFa, Turtle или кучу других форматов.

Для связанных данных требуется, чтобы ключи в JSON были URI. Это может быть так же просто, как добавить к ним префикс urn:string:<key> , для которого при использовании JSON-LD можно было бы сделать одну строку в контексте или написать явно.

Другим (обычно предпочтительным) способом было бы поместить термины для ключей в http(s) или ipfs: документ, который содержит удобочитаемые описания для каждого термина.

Я думаю, что также интересны метаданные для хеша IPFS, записанные в Linked Data. Я сделал быструю попытку сделать это сегодня в Черепахе, повторно используя шаблон, описанный в RFC6920 :

<ni:///multihash;QmZvTvRQ2voimuYwBtKsyMqMqirDt5Xrq4sdow2RM5ynKj> 
    <https://schema.org/sameAs> 
        <https://gateway.ipfs.io/ipfs/QmZvTvRQ2voimuYwBtKsyMqMqirDt5Xrq4sdow2RM5ynKj> ,
        <http://ia801506.us.archive.org/3/items/NodeUp114/NodeUp%20114.mp3> ,
        <ipfs:/ipfs/QmZvTvRQ2voimuYwBtKsyMqMqirDt5Xrq4sdow2RM5ynKj> ;
    <https://schema.org/contentType>
        "audio/mpeg" ;
    <https://schema.org/title>
        "NodeUp: A Node.js Podcast - Episode 114 - Internationalization Deep Dive" .

https://namedinstance.com/.well-known/ni/multihash/QmZvTvRQ2voimuYwBtKsyMqMqirDt5Xrq4sdow2RM5ynKj

Идея связанных данных заключается в том, что идентификаторы, которые вы даете вещам, если вы их ищете, дают им полезные данные, включая данные, которые ссылаются на связанные вещи. Таким образом, каталог дает вам список URI вещей, которые он содержит, событие дает вам время, данные и ссылки на приглашенных людей, люди дают вам ссылки на группы и других людей и так далее. Выполнение всего этого через ipfs: вместо http:, конечно, работает нормально, и вы можете связать два пространства. Вы можете, например, утверждать, что что-то в одном пространстве такое же, как что-то в другом. Вы можете задокументировать своих друзей в http:space, а ваши публикации задокументировать в ipfs:space или как вам угодно.

(Как rdfhead, я предпочитаю формат Turtle, так как считаю его простым и мощным, но вы, конечно, можете использовать JSONLD)

/me не может подключиться к static.benet.ai для чтения http://static.benet.ai/t/ipfs.pdf

@timbl вы можете найти более свежую версию документа IPFS здесь: https://github.com/ipfs/papers/blob/master/ipfs-cap2pfs/ipfs-p2p-file-system.pdf или тот же документ через общедоступные шлюзы IPFS: https://ipfs.io/ipfs/QmV9tSDx9UiPeWExXEeH6aoDvmihvx6jD5eLb4jbTaKGps

Вы можете, например, утверждать, что что-то в одном пространстве такое же, как что-то в другом.

Да! Это все одинаковые:

• dweb:/ipfs/somehash
• ipfs://somehash
• https://dweb.link/ipfs/somehash

Извините, схема dweb: URI и https://dweb.link пока не работают.

На данный момент это fs:/ipfs/somehash для URI (в дополнении IPFS Gateway Redirect) и https://ipfs.io/ipfs/somehash для HTTP:

• ipfs://somehash
• фс:/ipfs/somehash
• https://ipfs.io/ipfs/somehash

На случай, если люди в этой теме пропустили это, это произошло!

https://ipld.io/

продолжим общение на https://github.com/ipld/ipld

Конечно. Не стесняйтесь зайти, чтобы обсудить аспекты связанных данных по адресу:

https://gitter.im/linkeddata/чат

@nicola Я уверен, что не новичок в этом канале

На самом деле сегодня мы обсуждали добавление ipfs: URI в нашу систему. Желаем удачи с ipld!

Зачем использовать четко определенный термин «связанные данные» для чего-то, что явно не является LD?
https://www.w3.org/standards/semanticweb/data

Итак, я знаю, что это старая тема, но я добавляю себя, чтобы смешать для потомков.

Я работал с моделью данных «Проверяемые учетные данные» (https://w3c.github.io/vc-data-model/) и столкнулся с некоторыми проблемами при согласовании @context , представленных в JSON-LD и IPLD. (см.: https://github.com/w3c/vc-data-model/pull/261). Я могу признать, что JSON-LD полностью совместим с IPLD, но IPLD не полностью обратно совместим с JSON-LD, что было бы необходимо для взаимодействия с существующими спецификациями. На мой взгляд, решением было бы добавить ipld: в качестве допустимой схемы в ietf (см.: https://github.com/ipld/specs/issues/98), а затем разрешить { <attr> : ipld:<cid> } быть таким же, как { "/" : <cid> } в IPLD (см.: https://github.com/ipld/specs/issues/99). Также/дополнительно зарегистрируйте MIME Content-type application/ipld , чтобы объявить тип, определяющий протокол. Это усугубляет ситуацию, позволяя application/json+ipld против application/cbor+ipld , чтобы избежать путаницы. ( @mildred Мне не нравится ipfs:// для этого, так как нам нужны естественные ссылки и ` { "@context" : "/ipfs/"}" является допустимым URI)

Что касается семантической совместимости, я размещал контекст JSON-LD поверх IPLD. Однако это приводит к проблеме укоренения, которую легко решить, внедрив URI в качестве допустимых значений в JSON-LD.

В конце концов, это Черепахи до самого низа :turtle: > :turtle: > :turtle: пока не дойдете до самого дна, где вы найдете @timbl , вот почему я думаю, что он предпочитает Черепаху как формат : smiley:.

(Как rdfhead, я предпочитаю формат Turtle, так как считаю его простым и мощным, но вы, конечно, можете использовать JSONLD)

Прекрасным примером этого является обработка даты и времени в @context для проверяемых учетных данных на https://w3id.org/did/v1 , которая ссылается на xsd:datetime , которая ссылается на http://www.w3.org/ 2001/XMLSchema# , где объяснение в качестве источника документации находится в формате html .

Моя любимая аннотация в этом xml:

Сначала встроенные примитивные типы данных. Эти определения предназначены только для информации, настоящие встроенные определения — это волшебство.

Я могу работать с этой магией, пока мы принимаем, что в нижней части стека :turtle: > :turtle: > :turtle: мы соглашаемся, что это @timbl , а затем мы можем согласовать обратную совместимость с JSON-LD, используя выше с ipld: .

@jonnycrunch Я поддерживаю ваши идеи. Черепаха не самая популярная, потому что JSON довольно хорошо зарекомендовал себя в Интернете, особенно потому, что JSON является родным для браузеров и имеет неглубокую кривую обучения.

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

Проблема @context исчезнет, ​​если вы введете полный URL-адрес. Хотя это больше символов, я думаю, что это лучше, если не лучшая практика, учитывая, что она позволяет избежать кругового пути, и вам не нужно проверять целостность удаленного файла.

В конечном итоге возникает путаница в том, что URI являются одновременно именами (uuid) и локаторами (протокол), и мозгу нелегко думать об обоих одновременно. Если мы сможем добраться до точки, где мы будем использовать URI или сокращение для URI в ключах нашего JSON, многие из этих проблем исчезнут. Действительно, именование ipfs: и http: должно стать частью совместной сети со связанными данными в качестве своего рода клея.

я обновил свой комментарий, чтобы использовать синтаксис ipld:<cid> , понимая, что он неавторитетный и, следовательно, не достоин двойной косой черты $# ipld:// // . Поскольку полезная нагрузка описывает себя, она является авторитетной и должна существовать сама по себе. Но это аргумент для специалистов.

@jonnycrunch написал:

решением было бы добавить ipld: как допустимую схему в IETF.

Я очень поддерживаю этот подход и думаю, что это приведет к отличной истории взаимодействия между (более традиционным) сообществом связанных данных и сообществом IPFS/IPLD.