Ipfs: IPFS-LD - Dados vinculados

Ei @jbenet , ótimo trabalho com IPFS, muito interessado no que você está fazendo, pois estamos analisando o uso de DHTs (tipo Kademlia) + assinaturas digitais + rede de consulta para substituir a nomenclatura na Internet (substituir o DNS eventualmente). O trabalho básico que estamos fazendo é próximo ao que você está fazendo com IPFS: https://manu.sporny.org/2014/identity-credentials/ . Estamos usando JSON-LD para essa iniciativa, você conhece o Telehash? Caso contrário, você deve dar uma olhada, pois alguns desses conceitos podem fortalecer o IPFS.

De qualquer forma, se você quiser que os metadados na rede sejam legíveis por máquina e processáveis, mas de forma extensível, você deve usar JSON-LD. Se você usa JSON-LD, há uma boa chance de integrar o trabalho de Pagamentos pela Web e Credenciais que está acontecendo no W3C porque ambos os conjuntos de trabalho também são construídos em cima do JSON-LD. Um dos principais benefícios do JSON-LD é que você pode mesclar dados de fontes diferentes. Outra é que você pode especificar o formato básico de dados e permitir que as pessoas estendam o protocolo sem coordenação com você (o que é importante se você deseja que o sistema cresça a uma taxa exponencial).

Apenas alguns pensamentos, se você tiver dúvidas, por favor, pergunte. Exigir um @context em cada blob JSON na rede não é um requisito pesado.

obrigado pelos pensamentos!

estamos analisando o uso de DHTs (tipo Kademlia) + assinaturas digitais + rede de consulta para substituir a nomeação na Internet (substituir o DNS eventualmente).

Então certifique-se de ver a seção IPNS no artigo: http://static.benet.ai/t/ipfs.pdf (3.7). :)

Você conhece o Telehash?

Sim, eu aprovo muito o conceito geral + impulso para construí-lo, mas não sou a favor de muitas das decisões do projeto. Caso em questão, o slogan é "JSON + UDP + DHT = Freedom", mas acho que esses tipos de sistemas devem (a) não forçar um formato de dados, (b) não forçar um protocolo de transporte e (c) não forçar um sistema de roteamento. É claro que essas três são ótimas opções _hoje_, mas esses protocolos devem ser criados para se ajustarem às camadas e ao longo do tempo. Assim, o IPFS permite que os usuários usem qualquer formato que desejarem, o IPFS pode se sobrepor a qualquer transporte e, embora o primeiro sistema de roteamento seja um DHT, há outros a serem explorados.

Você pode ver o IPFS como Telehash + a (merkle) Web.

se você quiser que os metadados na rede sejam legíveis por máquina e processáveis, mas de forma extensível, você deve usar JSON-LD.

Acho que podemos pegar a parte -LD do seu trabalho sem exigir JSON como transporte. Ou seja, acho que seu (incrível) trabalho é generalizável para qualquer estrutura de dados em árvore e é muito melhor do que outros formatos da web semântica. (incrível simplicidade + flexibilidade!) Então, o que estou apontando nestas notas é usar o equivalente a @context mas na estrutura de dados do link IPFS (que não é JSON, é um formato binário compactado para busca rápida através de objetos -- protobuf hoje, mas também pode ser auto-descritivo mais tarde -- Eu pretendo que o IPFS seja rápido o suficiente para funcionar como um banco de dados. não hoje, mas no futuro :) ).

Exigir um @context em cada blob JSON na rede não é um requisito pesado.

Sim, eu argumentei o mesmo :)

@jbenet re: https://github.com/dataprotocols/dataprotocols/issues/110#issuecomment -43430309 - sim, achei seus argumentos muito bons e bem informados.

Estou realmente interessado no que você está fazendo, dei uma olhada no papel e comecei a assistir seu vídeo. Infelizmente, tenho prazos que preciso cumprir hoje, mas tenho que ler seu artigo e assistir ao vídeo inteiro na minha lista de tarefas. Não sei se você sabe disso, mas eu trabalho na construção de padrões para a Web através do W3C. Temos um conjunto de problemas agora que precisam de uma solução semelhante à que você está descrevendo. Quero ver se podemos integrar parte do seu trabalho na solução de login padrão W3C de próxima geração em que estamos trabalhando para a Web (o post que mencionei acima). No momento, estamos usando o Telehash, mas temos algumas preocupações com ele e você parece ter decomposto o problema de uma maneira que pode se encaixar melhor em nossos casos de uso.

De qualquer forma, deixe-me entrar no que você criou e depois voltar para você. Se você não tiver notícias minhas dentro de uma semana, por favor, envie-me um ping novamente.

Olá @jbenet , tive a chance de analisar o whitepaper com mais detalhes no fim de semana e assistir à sua apresentação. Vamos marcar um horário para conversar na próxima semana. Estou na costa leste, EUA. Disponível das 10h às 14h na maioria dos dias, exceto ter/qua. Meu e-mail: [email protected] , Skype: msporny, SIP: sip:[email protected] Entre em contato comigo o quanto antes.

Eu gostaria de discutir ipns e este wrt. login na Web, Credenciais e Pagamentos na Web: https://manu.sporny.org/2014/identity-credentials/

@msporny ótimo! vai fazer. Enviei um e-mail agora mesmo para a base de contato. Você pode querer remover seus detalhes de contato deste problema (já que é público, etc).

Estávamos discutindo como responder a perguntas sobre “que tipo de objeto é esse” no IRC hoje. @jbenet mencionou links de estilo LSON-LD @type ou @context , mas não tenho certeza de como você sai dessa cadeia . São links @context até o fim? @tv42 também levantou preocupações sobre colisões com nomes de arquivos , já que os nós de diretório usam nomes de segmentos filhos como suas chaves. Você pode contornar isso prefixando ou escapando os nomes dos segmentos, mas isso parece mais trabalhoso do que apenas adicionar um campo Type explícito para manter o ID do hash para a descrição do tipo . Se esperamos mais desse tipo de coisa, talvez ele apenas exija o particionamento de Links em conjuntos internos e externos. Você pode fazer isso com a abordagem de extensão protobuf de link proposta do @jbenet (se isso se tornar uma coisa) adicionando um booleano 'interno' para separar a entrada do tipo @context de qualquer entrada de arquivo @context ( por exemplo).

desculpe, o formato (quase certamente) não está mudando neste momento. Passei meses resumindo a isso e não vou abrir as comportas de novo. as perguntas restantes (como extensões de link) são conhecidas há algum tempo e estão apenas encontrando o caminho certo para fazê-lo.

um objeto ipfs é uma árvore como json ou qualquer outra coisa. isso significa que todas as soluções disponíveis para JSON (incluindo JSON-LD, JSON-schema e assim por diante) estão disponíveis para IPFS. além disso, é trivial representar triplos RDF como objetos ipfs. portanto, você pode fazer tudo e qualquer coisa.

dados reais são muito confusos. ninguém no mundo conseguiu forçar as pessoas a adotar um determinado sistema de digitação de dados - e não vou perder tempo com esses argumentos. A única solução que acho viável a longo prazo é tornar um sistema flexível o suficiente para que as pessoas façam o que quiserem, e rígido o suficiente para que tudo se interligue.

agora, a maneira _preferred_ -- a maneira como sugerimos que as pessoas façam as coisas -- provavelmente será a @context / @type do JSON-LD (incrivelmente poderoso e simples).

mas não tenho certeza de como você sai dessa cadeia

eu não entendo a pergunta. não existe chain, você resolve o contexto uma vez e pronto. esse é o arquivo de contexto para o objeto. se não for um contexto válido -- há uma especificação -- você a ignora. os aplicativos não devem _depender_ desses tipos estarem corretos, mas sim aproveitá-los quando estiverem.

@tv42 também levantou preocupações sobre colisões com nomes de arquivos, já que os nós de diretório usam nomes de segmentos filhos como suas chaves.

se uma estrutura de dados dir já tiver um @context , ela não permitirá a criação de outro arquivo-- (ou, na pior das hipóteses, anexar o link depois (classificação estável)). é o mesmo que tentar criar dois arquivos com o mesmo nome.

Em sex, 01 de maio de 2015 às 03:51:22 -0700, Juan Batiz-Benet escreveu:

desculpe, o formato (provavelmente) não está mudando neste momento. eu
passou meses se resumindo a isso e não vai abrir o dilúvio
portões sobre isso novamente. as perguntas restantes (como extensões de link)
já são conhecidos há algum tempo e apenas encontrando a maneira certa de fazer
isto.

As extensões de link devem funcionar bem. E prefixando chaves de link para
namespace eles também não são tão ruins. Preenchendo as informações de tipo
into Data também funciona (é assim que os arquivos e diretórios funcionam agora
[1,2,3,4,5]). Enumerar tipos não é uma abordagem sustentável, mas
qualquer um desses locais funcionaria como um local para armazenar um hash de tipo.

agora, a maneira _preferida_ -- a maneira como sugerimos que as pessoas façam as coisas
-- provavelmente será o @context / @type do
(incrivelmente poderoso e simples) JSON-LD.

JSON-LD é bom, mas o ecossistema em torno dele precisará entender
que o prefixo @ é especial. Eu preferiria que a especialidade fosse armazenada
explicitamente estendendo as entradas de Link com dados adicionais (por exemplo, um
sinalizador interno/externo) para que não tenhamos ambiguidade entre um @context
arquivo e um link do tipo @context . Mas se todos os links de arquivo/subdiretório forem codificados
com criança/', então você poderia ter 'contexto' para o tipo
link e 'filho/contexto' para o arquivo (ou qualquer outro). Ainda vai
ter que ser uma convenção definida externamente que os geradores de objetos
e os consumidores precisam concordar por meio de um canal não autodescritivo.

mas não tenho certeza de como você sai dessa cadeia

eu não entendo a pergunta. não há cadeia, você resolve
contexto uma vez e é isso. esse é o arquivo de contexto para o
objeto. se não for um contexto válido -- há uma especificação -- você
ignore isto.

Isso funciona para mim. Eu queria saber como você termina uma auto-descrição
cadeia:

Que tipo é A? Vamos apenas seguir A/ @context para B. Que tipo é B?
Vamos apenas seguir B/ @context para C…

Mas se você estiver distribuindo a especificação B (C no meu exemplo), não há
necessidade de um link B/ @context . Mas se você tem um canal para
distribuindo o type spec (C), por que não usá-lo também para distribuir o
esquemas de tipo em si (B)? Parece que é melhor ter apenas um
lugar convencional em objetos que contém um multihash descrevendo sua
digite (seu link @context , ou qualquer outro). Então saia do caminho e
deixar para as comunidades de produtores/consumidores decidir se isso é um
referência a uma definição de tipo (talvez sob especificação C, ou Cv2, ou o
alternativa CCv1.3, ou …) ou se eles querem apenas usar o multihash como
um identificador opaco. Então você ainda pode fazer coisas como:

switch pbn.GetType() {
case ft.TDirectory:
root.val = NewDirectory(pointsTo.String(), mnode, root, fs)

é só que GetType estaria pegando o hash @context Link (ou
onde) e TDirectory seria um multihash
(QmWellKnownDirectoryType).

aplicativos não devem _depender_ desses tipos estarem corretos, mas
em vez disso, alavancá-los quando eles são.

Isso soa como um identificador opaco. Talvez estejamos dizendo o mesmo
coisa ;).

@tv42 também levantou preocupações sobre colisões com nomes de arquivos, já que
os nós de diretório usam nomes de segmento filho como suas chaves.

se uma estrutura de dados dir já tiver um @context , não permitiria
a criação de outro arquivo-- (ou na pior das hipóteses, anexar o link após
(classificação estável)). é o mesmo que tentar criar dois arquivos com o
mesmo nome.

É se você quiser tornar os arquivos @context ilegais;). Se você quiser
permitir que as pessoas criem arquivos @context , você precisará de alguma maneira de
desambiguar entre “este link aponta para um tipo” e “este link
aponta para um arquivo/subdiretório/…”. Mas há várias maneiras
em torno desse problema, desde que escolhamos um deles, ficarei feliz
;).

Conversei com @cryptix há vários dias e conversamos brevemente sobre o uso de JSON-LD. Gostaria apenas de salientar que a especificação para json-ld permite o uso de um "link" para descrever os mapeamentos do json para json-ld. Eu pessoalmente prefiro essa abordagem porque permite que os metadados sejam compatíveis com json-ld sem reestruturar para qualquer sabor de RDF que seja atualmente "hip".

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

Em sex, 01 de maio de 2015 às 21:24:27 -0700, W. Trevor King escreveu:

As extensões de link devem funcionar bem. E prefixando chaves de link para
namespace eles também não são tão ruins. Preenchendo as informações de tipo
into Data também funciona (é assim que os arquivos e diretórios funcionam agora
[1,2,3,4,5]). Enumerar tipos não é uma abordagem sustentável, mas
qualquer um desses locais funcionaria como um local para armazenar um hash de tipo.

Em uma nota relacionada (distribuindo IDs de tipo hash junto com o
payload), @tv42 acabou de chamar minha atenção para Ethos ETypes [1,2,3]. assim
Acho que ter algum tipo de espaço explícito para essas coisas seria
excelente.

Não vi ETypes, obrigado por aparecer. vai ler nos próximos dias. Algo relevante é o trabalho PADS de Kathleen Fisher + relacionado. A página do projeto PADS parece ter sido alterada recentemente (se houvesse algum armazenamento imutável endereçado ao conteúdo da web...). (Mas o arquivo da internet nos salvou novamente \o/: http://web.archive.org/web/20130125041549/http://www.padsproj.org/ )

• PADS: Uma linguagem específica de domínio para processamento de dados ad hoc
• O Projeto PADS: uma visão geral
• PADS/T: uma linguagem para descrever e transformar dados ad hoc
• PADS/ML: Uma linguagem de descrição de dados funcional
• LearnPADS: geração automática de ferramentas a partir de dados ad hoc
• mais artigos : http://web.archive.org/web/20120205185831/http://www.padsproj.org/doc.html#papers

De qualquer forma, o PADS tem a ideia certa. mas até agora não viu ampla implementação, que eu saiba. talvez haja algo no estilo do JSON-LD que possa corrigir isso aqui.

JSON-LD não é apenas adicionar um link @context . Em particular, cada nome de link (chave em JSON) deve se enquadrar em uma destas categorias:

• @context : link de contexto ou nó embutido que descreve os dados
• @id : o URI do nó atual
• esquema://full-uri : é reconhecido como um link cujo predicado é o URI
• prefix:name : é reconhecido como um link cujo predicado é a concatenação do prefixo URI (definido no contexto) e nome
• nome: é reconhecido como um link somente se definido no contexto

Em particular, o JSON-LD não parece oferecer suporte a mapas de chave/valor arbitrários. Se a chave puder ser interpretada como um URI, ela será considerada um predicado usando esse URI. Por exemplo, o seguinte é inválido:

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

pois http://xmlns.com/foaf/0.1/name sempre se referirá a um nome FOAF, e não à versão em cache de uma página da web.

Isso não é necessariamente um problema, mas deve ser considerado se decidirmos interpretar links como dados vinculados ao projetar formatos de objeto. Por exemplo, um diretório pode ser representado dessa maneira usando 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>"
    }
  ]
}

No IPFS-LD teríamos um nó para o diretório, ligando a um contexto e a um nó para cada entrada. Cada entrada teria então links para seu próprio contexto, um nó contendo seu nome e um nó com o conteúdo do arquivo.

Isso adiciona vários níveis de indireção, que são aceitáveis ​​para documentos JSON (porque tudo é compactado em um arquivo), mas podem não ser aceitáveis ​​para IPFS, onde cada nó tem um hash diferente e deve ser rastreado separadamente.

Talvez o que queremos não seja usar o JSON-LD como está, mas definir nosso próprio formato de contexto inspirado no JSON-LD. Isso seria melhor porque nosso formato não é JSON e é muito específico: queremos poder descrever mapas de chaves arbitrárias (para unixfs) e também queremos usar a seção de dados de nossos objetos IPFS (JSON não tem isso ).

Como a seção de links dos objetos IPFS é muito restritiva, os links têm um nome e apontam para outro objeto. Não pode conter valores literais. O que precisamos especificar no contexto é o nome totalmente qualificado do link no formato URI. Como também temos uma seção de dados, precisamos definir o que ela contém.

Para unixfs, eu imaginaria os seguintes objetos:

• directory :
  
  
  
  • link @context apontando para o contexto do diretório
  
  
  • link entry:README.md apontando para o objeto README.md
  
  
  • sem dados
  
  
• README.md :
  
  
  
  • link @context apontando para o contexto do arquivo
  
  
  • seção de dados com o conteúdo de README.md
  
  
• contexto-diretório:

```
{
// @type : o tipo do objeto 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"
}

}
```

• contexto do arquivo:

```
{
"@type": " http://schema/unixfs#File "

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

}
```

Se quiséssemos representar isso em triplos, teríamos:

# 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

Ei @mildred -- ótima análise. Curiosamente cheguei às mesmas conclusões em uma conversa com dlongley em irc://irc.frennode.org#json -ld (pode enviar logs se estiver interessado)

Eu tenho experimentado um pouco com um tipo de coisa IPLD mais permissiva aqui - em particular, veja os exemplos. estes não são finais (ou corretos?), mas dão um senso de direção

• 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 (ignore o uso de @value , está incorreto)
• 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

Anotações importantes:

• links relaxantes para _permitir_ inclusão de outros valores (muito solicitados), apenas reservamos {"@type": "mlink", "hash": "<multihash>"}
• os usuários podem definir contextos para suas estruturas de dados
• pode _nest_ links, usando notação de caminho para percorrer, por exemplo https://github.com/ipfs/go-ipld/blob/master/ipld.go#L122 -L141

Acho que você e eu estamos no caminho certo. Acho também que provavelmente podemos fazer muito disso sem nos desviarmos muito do JSON-LD. apenas deixando cair algumas restrições

@mildred registra aqui

também devo dizer que -- da minha conversa com dlongley -- deve ser possível fazer o que queremos sem desviar tecnicamente do padrão JSON-LD, apenas que _chamar as transformações (compactação/expansão)_ removeria todos os "não -chaves definidas pelo contexto". (devemos nos esforçar para não nos desviar)

Acho que você removeria muita confusão pensando no JSON-LD em termos de triplos gerados, em vez do que o analisador json-ld.js faz na transformação do JSON. A etapa de transformação JSON é específica para esse analisador e você pode imaginar facilmente transformá-lo de outra maneira sem problemas.

Agora, se eu entendi bem o que você está fazendo com go-ipld , ele pode substituir a seção Link nos objetos IPFS atuais, certo? Essa coisa: merkledag.proto

Eu vejo um problema aí. Onde antes tínhamos uma estrutura simples que permitia um processamento eficiente (nome do link, diretamente relacionado ao caminho e hash do link), agora temos uma estrutura um pouco mais complexa. Para chegar ao hash vinculado, você deve resolver a string "mlink" em uma tabela de hash. Isso é mesmo necessário?

Se você deseja dados / RDF vinculados, por que não simplesmente definir seu próprio formato de fio (protobuf é ótimo no que me diz respeito) e a maneira como ele pode ser traduzido para JSON. Em seguida, use o contexto JSON-LD em cima disso.

Agora, sobre as diferentes estruturas de dados que você estava pensando, acho que são ótimas, com exceção do unixfs: não podemos ter nomes de arquivos como chaves JSON-LD porque as chaves JSON-LD devem, em todas as circunstâncias, se referir a predicados RDF. Um nome de arquivo é um valor literal.

Ao invés de:

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

Eu modelaria isso como:

{
  <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"
    }
  ]
}

Novamente, a versão binária/serializada não precisa ser assim. A maneira de representar esta última notação como tripes RDF seria:

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"

Estou no IRC, não hesite em me enviar um ping lá.

Para aqueles que não estão familiarizados com RDF neste tópico, aqui está uma pequena explicação:

RDF é uma maneira de estruturar seus dados. é o modelo de dados por trás do JSON-LD. Em RDF, todos os dados devem ser codificados em triplos:

<subject> <predicate> <object>

• O assunto é um nó que é identificado por um URI
• O predicado é um URI como <http://www.w3.org/1999/02/22-rdf-syntax-ns#name> . O URI define exclusivamente o relacionamento e, de preferência, deve ser bem definido em uma especificação ou esquema.
• O objeto é o destino do link/predicado. Pode ser um valor literal (uma string, que pode ser opcionalmente digitada, por exemplo, como um inteiro ou uma data, geralmente derivada do esquema xsd) ou pode ser outro nó, identificado por seu URI

A notação tripla supõe que cada nó sujeito e objeto possui um URI que o identifica exclusivamente. Ele define a estrutura de dados completa listando todas as triplas que contém uma por linha.

As chaves JSON em JSON-LD são predicados que ligam o sujeito (o objeto no qual a chave está presente) e o objeto: o valor da chave JSON-LD. Nesse caso, URI não é usado para se referir ao assunto e ao objeto. Se você deseja especificar o URI de um objeto que pode ser usado para se referir a ele, existe a propriedade @id .

Existe um artigo explicando em algum lugar como o Linked Data over IPFS funciona em comparação com o funcionamento do HTTP? (Como são os URIs? Quais devem ser as melhores práticas para editores e consumidores de Linked Data sobre IPFS?)

Ver:

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

O IPLD fornece o modelo de dados json. você pode colocar qualquer JSON-LD sobre o IPLD.

(ainda não desembarcou)

@jbenet acabou de ler este tópico, usar dados vinculados é uma ótima iniciativa IMHO

Você está correto em que o Linked Data não exige nenhuma serialização. É possível usar JSON-LD, RDF/XML, RDFa, Turtle ou vários outros formatos

O que os dados vinculados exigem é que as chaves em JSON sejam URIs. Isso pode ser tão simples quanto prefixá-los com urn:string:<key> para o qual, se usar JSON-LD, pode ser feito como um forro no contexto ou escrito explicitamente.

Outra maneira (geralmente preferida) seria colocar os termos para as chaves em um documento http(s) ou ipfs: que contém descrições legíveis para cada termo.

Também acho interessante os metadados de um hash IPFS escrito em Linked Data. Fiz uma tentativa rápida disso hoje no Turtle, reutilizando o padrão descrito no 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

A ideia de dados vinculados é que os identificadores que você fornece às coisas, se você os pesquisar, fornecem dados úteis, incluindo dados que vinculam a coisas relacionadas. Assim, um diretório fornece uma lista dos URIs das coisas que ele contém, um evento fornece o tempo e os dados e links para pessoas convidadas, pessoas fornecem links para grupos e outras pessoas e assim por diante. Fazer tudo isso por ipfs: em vez de http: é claro que funciona bem, e você pode vincular os dois espaços. Você pode, por exemplo, afirmar que algo em um espaço é o mesmo que algo em outro. Você pode documentar seus amigos em http: space e suas publicações documentadas em ipfs: space ou o que quiser.

(Como rdfhead, prefiro Turtle como formato, pois acho simples e poderoso, mas você pode usar JSONLD com certeza)

/me não pode se conectar a static.benet.ai para ler http://static.benet.ai/t/ipfs.pdf

@timbl você pode encontrar uma versão mais atualizada do documento IPFS aqui: https://github.com/ipfs/papers/blob/master/ipfs-cap2pfs/ipfs-p2p-file-system.pdf ou o mesmo papel via gateways IPFS públicos: https://ipfs.io/ipfs/QmV9tSDx9UiPeWExXEeH6aoDvmihvx6jD5eLb4jbTaKGps

Você pode, por exemplo, afirmar que algo em um espaço é o mesmo que algo em outro.

Sim! Estes são todos iguais:

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

Desculpe por isso, o dweb: esquema URI e https://dweb.link ainda não funcionam.

Por enquanto é fs:/ipfs/somehash para URIs (no addon IPFS Gateway Redirect) e https://ipfs.io/ipfs/somehash para HTTP:

• ipfs://somehash
• fs:/ipfs/somehash
• https://ipfs.io/ipfs/somehash

Caso as pessoas neste tópico tenham perdido, aconteceu!

https://ipld.io/

vamos continuar a conversa em https://github.com/ipld/ipld

Certo. Sinta-se à vontade para entrar para discutir aspectos de dados vinculados em:

https://gitter.im/linkeddata/chat

@nicola tenho certeza que não é estranho a esse canal

Na verdade, estávamos discutindo a adição de ipfs: URIs ao nosso sistema hoje. Boa sorte com o ipld!

Por que usar o termo bem definido "Linked Data" para algo que claramente não é LD?
https://www.w3.org/standards/semanticweb/data

então, eu sei que esse é um tópico antigo, mas estou me adicionando para mixar para a posteridade.

Eu tenho trabalhado no modelo de dados de Credenciais Verificáveis ​​(https://w3c.github.io/vc-data-model/) e encontrei alguns problemas para conciliar o @context representado em JSON-LD vs IPLD. (consulte: https://github.com/w3c/vc-data-model/pull/261 ). Posso reconhecer que o JSON-LD é totalmente compatível com o IPLD, mas o IPLD não é totalmente compatível com o JSON-LD, o que seria necessário para a interoperabilidade com as especificações existentes. A meu ver, a solução seria adicionar ipld: como um esquema válido no ietf (consulte: https://github.com/ipld/specs/issues/98 ) e permitir { <attr> : ipld:<cid> } seja o mesmo que { "/" : <cid> } realiza no IPLD (consulte: https://github.com/ipld/specs/issues/99). Registre também/adicionalmente o tipo de conteúdo MIME de application/ipld para declarar o tipo que define o protocolo. Isso seria composto para permitir application/json+ipld vs application/cbor+ipld para aliviar a confusão. ( @mildred eu não gosto de ipfs:// para isso, pois precisamos de links naturais e ` { "@context" : "/ipfs/" }' é um URI válido)

Quanto à interoperabilidade semântica, tenho colocado o contexto JSON-LD em camadas sobre o IPLD. No entanto, isso chega a um problema de enraizamento, facilmente resolvido com a incorporação de URIs como valores válidos no JSON-LD.

Em última análise, é Turtles todo o caminho :turtle: > :turtle: > :turtle: até chegar ao fundo onde você encontra @timbl , e é por isso que acho que ele prefere Turtle como formato : smiley:.

(Como rdfhead, prefiro Turtle como formato, pois acho simples e poderoso, mas você pode usar JSONLD com certeza)

Um exemplo perfeito disso é a manipulação de data e hora em @context para Credenciais Verificáveis ​​em https://w3id.org/did/v1 que vincula a xsd:datetime que faz referência a http://www.w3.org/ 2001/XMLSchema# , onde a explicação como fonte de documentação está em html .

Minha anotação favorita neste xml é:

Primeiro os tipos de dados primitivos embutidos. Essas definições são apenas para informação, as definições internas reais são mágicas.

Eu posso trabalhar com essa mágica, desde que aceitemos isso na parte inferior da pilha de :turtle: > :turtle: > :turtle: concordamos que é @timbl e então podemos reconciliar a retrocompatibilidade com JSON-LD usando acima com ipld: .

@jonnycrunch Eu apoio suas ideias. O Turtle não é o mais popular, porque o JSON está bem estabelecido na web, especialmente porque o JSON é nativo dos navegadores e tem uma curva de aprendizado rasa.

Há um equilíbrio a ser obtido entre atrair uma ampla comunidade de desenvolvedores e ter um sistema que seja interoperável (não algo tão preto e branco) e rico em recursos.

O problema @context desaparece se você digitar o URL completo. Embora seja mais caracteres, estou olhando para pensar que é uma prática melhor, se não a melhor, já que evita uma viagem de ida e volta e você não precisa verificar a integridade do arquivo remoto.

Em última análise, surge a confusão em que os URIs são tanto nomes (uuids) quanto localizadores (protocolo) e o cérebro não pensa facilmente em ambos ao mesmo tempo. Se chegarmos ao ponto em que estamos usando URIs ou abreviação de URIs nas chaves do nosso JSON, muitos desses problemas desaparecem. De fato, como nomear ipfs: e http: deve se tornar parte de uma rede cooperativa, com dados vinculados como uma espécie de cola.

atualizei meu comentário para usar a sintaxe ipld:<cid> percebendo que não é autoritativo e, portanto, não é digno da barra dupla ipld:// // . Como a carga útil é autodescritiva, ela é sua própria autoridade e deve ser independente. Mas isso é um argumento para os especialistas.

@jonnycrunch escreveu:

a solução seria adicionar ipld: como um esquema válido no IETF

Eu apoio muito essa abordagem e acho que isso levaria a uma grande história de interoperabilidade entre a comunidade Linked Data (mais tradicional) e a comunidade IPFS/IPLD.