Ipfs: IPFS-LD - Datos vinculados

Hola @jbenet , gran trabajo con IPFS, muy interesado en lo que está haciendo, ya que estamos investigando el uso de DHT (similar a Kademlia) + firmas digitales + red de consulta para reemplazar los nombres en Internet (reemplazar DNS eventualmente). El trabajo básico que estamos haciendo es similar a lo que está haciendo con IPFS: https://manu.sporny.org/2014/identity-credentials/ . Estamos usando JSON-LD para esa iniciativa, ¿conoces Telehash? De lo contrario, debería echar un vistazo, ya que algunos de esos conceptos podrían fortalecer IPFS.

En cualquier caso, si desea que los metadatos en la red sean legibles y procesables por máquina, pero de manera extensible, debe usar JSON-LD. Si usa JSON-LD, existe una buena posibilidad de que pueda integrar el trabajo de pagos web y credenciales que se lleva a cabo en el W3C porque ambos conjuntos de trabajo también se construyen sobre JSON-LD. Uno de los principales beneficios de JSON-LD es que puede fusionar datos de fuentes dispares. Otra es que puede especificar el formato de datos básico y permitir que las personas amplíen el protocolo sin coordinarse con usted (lo cual es importante si desea que el sistema crezca a un ritmo exponencial).

Solo algunos pensamientos, si tiene preguntas, por favor pregunte. Requerir un @context en cada blob JSON en la red no es un requisito pesado.

gracias por los pensamientos!

estamos investigando el uso de DHT (similar a Kademlia) + firmas digitales + red de consulta para reemplazar los nombres en Internet (reemplazar DNS eventualmente).

Luego, asegúrese de ver la sección IPNS en el documento: http://static.benet.ai/t/ipfs.pdf (3.7). :)

¿Conoces Telehash?

Sí, apruebo mucho el concepto general + impulso para construirlo, pero no estoy a favor de muchas de las decisiones del proyecto. Por ejemplo, el eslogan es "JSON + UDP + DHT = Libertad", pero creo que este tipo de sistemas deberían (a) no forzar un formato de datos, (b) no forzar un protocolo de transporte y (c) no forzar un sistema de enrutamiento Por supuesto, estas tres son excelentes opciones _hoy_, pero estos protocolos deben construirse para adaptarse a todas las capas ya lo largo del tiempo. Por lo tanto, IPFS permite a los usuarios usar cualquier formato que deseen, IPFS puede superponerse a cualquier transporte y, aunque el primer sistema de enrutamiento será un DHT, hay otros para explorar.

Puede ver IPFS como Telehash + la Web (merkle).

si desea que los metadatos en la red sean legibles y procesables por máquina, pero de una manera extensible, debe usar JSON-LD.

Creo que podemos tomar la parte -LD de su trabajo sin requerir JSON como transporte. Es decir, creo que su (increíble) trabajo se puede generalizar a cualquier estructura de datos de árbol y es mucho mejor que otros formatos de web semántica. (¡increíble simplicidad + flexibilidad!) Entonces, lo que estoy señalando en estas notas es usar el equivalente de @context pero en la estructura de datos del enlace IPFS (que no es JSON, es un formato empaquetado binario para buscar rápidamente a través de objetos -- protobuf hoy, pero también puede ser autodescriptivo más adelante -- Tengo la intención de que IPFS sea lo suficientemente rápido para funcionar como una base de datos. No hoy, sino en el futuro :)).

Requerir un @context en cada blob JSON en la red no es un requisito pesado.

Sí, he argumentado lo mismo :)

@jbenet re: https://github.com/dataprotocols/dataprotocols/issues/110#issuecomment -43430309 - sí, pensé que sus argumentos eran muy buenos y estaban bien informados.

Estoy realmente interesado en lo que estás haciendo, hojeé el periódico y comencé a ver tu video. Lamentablemente, tengo fechas límite que debo cumplir hoy, pero tengo que leer su artículo y ver el video completo en mi lista de tareas pendientes. No sé si sabes esto, pero trabajo en la creación de estándares para la Web a través del W3C. Tenemos una serie de problemas en este momento que necesitan una solución similar a la que estás describiendo. Quiero ver si podemos integrar parte de su trabajo en la solución de inicio de sesión estándar W3C de próxima generación en la que estamos trabajando para la Web (la publicación a la que aludí anteriormente). Actualmente estamos usando Telehash, pero tenemos algunas preocupaciones y parece que ha descompuesto el problema de una manera que podría adaptarse mejor a nuestros casos de uso.

En cualquier caso, déjame entrar en lo que has creado y luego te responderé. Si no tiene noticias mías dentro de la semana, por favor hágame un ping nuevamente.

Hola @jbenet , tuve la oportunidad de revisar el documento técnico con más detalle durante el fin de semana y ver su presentación. Establezcamos un tiempo para hablar la próxima semana. Estoy en la costa este, EE.UU. Disponible de 10 a. m. a 2 p. m. la mayoría de los días, excepto los martes y miércoles. Mi correo electrónico: [email protected] , Skype: msporny, SIP: sip:[email protected] Póngase en contacto conmigo lo antes posible.

Me gustaría hablar sobre ipns y este wrt. iniciar sesión en la Web, Credenciales y Pagos Web: https://manu.sporny.org/2014/identity-credentials/

@msporny genial! servirá. Envié un correo electrónico ahora mismo para tocar la base. Es posible que desee eliminar sus datos de contacto de este problema (ya que es público, etc.).

Estábamos dando vueltas sobre cómo responder preguntas de "qué tipo de objeto es este" en IRC hoy. @jbenet mencionó el estilo LSON-LD @type o @context enlaces, pero no estoy seguro de cómo se sale de esa cadena . ¿Son enlaces @context hasta el final? @tv42 también expresó su preocupación por las colisiones con los nombres de archivo , ya que los nodos de directorio usan nombres de segmentos secundarios como sus claves. Puede solucionar esto agregando un prefijo o escapando de los nombres de los segmentos, pero eso parece más trabajo que simplemente agregar un campo Tipo explícito para contener la ID hash para la descripción del tipo . Si esperamos más de este tipo de cosas, tal vez solo requiera dividir los enlaces en conjuntos internos y externos. Podría hacer eso con el enfoque de extensión Link protobuf propuesto por @jbenet (si eso se convierte en una cosa) agregando un booleano 'interno' para separar la entrada de tipo @context de cualquier entrada de archivo @context ( por ejemplo).

lo siento, el formato (casi seguro) no está cambiando en este momento. Pasé meses reduciéndolo a esto y no volvería a abrir las compuertas en eso. las preguntas restantes (como las extensiones de enlace) se conocen desde hace algún tiempo y solo se está encontrando la forma correcta de hacerlo.

un objeto ipfs es un árbol como json o cualquier otra cosa. esto significa que todas las soluciones disponibles para JSON (incluido JSON-LD, JSON-schema, etc.) están disponibles para IPFS. además, es trivial representar triples RDF como objetos ipfs. por lo tanto, puedes hacer cualquier cosa y todo.

los datos reales son muy desordenados. nadie en el mundo ha tenido éxito en obligar a las personas a adoptar un sistema de escritura de datos en particular, y no voy a perder tiempo en esos argumentos. La única solución que creo que es viable a largo plazo es hacer un sistema lo suficientemente flexible para que las personas hagan lo que quieran, y lo suficientemente rígido para que todo se interrelacione.

ahora, la forma _preferida_, la forma en que sugeriremos que las personas hagan las cosas, probablemente será la @context / @type del (increíblemente poderoso y simple) JSON-LD.

pero no estoy seguro de cómo rompes esa cadena

no entiendo la pregunta no hay cadena, resuelves el contexto una vez y listo. ese es el archivo de contexto para el objeto. si no es un contexto válido, hay una especificación, lo ignora. las aplicaciones no deberían _depender_ de que estos tipos sean correctos, sino aprovecharlos cuando lo sean.

@tv42 también expresó su preocupación por las colisiones con los nombres de archivo, ya que los nodos de directorio usan nombres de segmentos secundarios como sus claves.

si una estructura de datos dir ya tiene un @context , no permitiría la creación de otro archivo-- (o en el peor de los casos, agregar el enlace después de (clasificación estable)). es lo mismo que intentar crear dos archivos con el mismo nombre.

El viernes 01 de mayo de 2015 a las 03:51:22 AM -0700, Juan Batiz-Benet escribió:

lo siento, el formato (lo más probable) no está cambiando en este punto. I
pasó meses reduciéndolo a esto y no va a abrir la inundación
Gates en eso de nuevo. las preguntas restantes (como extensiones de enlace)
se conocen desde hace algún tiempo y acaban de encontrar la manera correcta de hacerlo
eso.

Las extensiones de enlace deberían funcionar bien. Y anteponer claves de enlace a
el espacio de nombres tampoco es tan malo. Relleno de la información de tipo
into Data también funciona (así es como funcionan ahora los archivos y directorios
[1,2,3,4,5]). Enumerar tipos no es un enfoque sostenible, pero
cualquiera de estos lugares funcionaría como un lugar para almacenar un hash de tipo.

ahora, la forma _preferida_: la forma en que sugeriremos que las personas hagan las cosas
-- es probable que sea el @context / @type del
(increíblemente poderoso y simple) JSON-LD.

JSON-LD está bien, pero el ecosistema que lo rodea deberá comprender
que el prefijo @ es especial. Preferiría que esa especialidad se almacene
explícitamente ampliando las entradas de enlace con datos adicionales (por ejemplo, un
bandera interna/externa) para que no tengamos ambigüedad entre un @context
archivo y un enlace de tipo @context . Pero si todos los enlaces de archivos/subdirectorios están codificados
con niño/', entonces podría tener 'contexto' para el tipo
enlace y 'hijo/contexto' para el archivo (o lo que sea). todavía va
tener que ser una convención definida externamente que los generadores de objetos
y los consumidores deben ponerse de acuerdo a través de un canal que no se describe a sí mismo.

pero no estoy seguro de cómo rompes esa cadena

no entiendo la pregunta no hay cadena, tu resuelves
contexto una vez y eso es todo. ese es el archivo de contexto para el
objeto. si no es un contexto válido, hay una especificación, usted
ignoralo.

Funciona para mi. Me preguntaba cómo terminas una autodescripción
cadena:

¿Qué tipo es A? Simplemente sigamos A/ @context a B. ¿Qué tipo es B?
Simplemente sigamos B/ @context a C...

Pero si está distribuyendo la especificación B (C en mi ejemplo), no hay
necesidad de un enlace B/ @context . Pero si tienes un canal para
distribuir la especificación de tipo (C), ¿por qué no usarlo también para distribuir el
esquemas de tipos en sí mismos (B)? Parece que es mejor simplemente tener un
lugar convencional en objetos que contiene un multihash que describe su
escriba (su enlace @context , o lo que sea). Entonces sal del camino y
dejar que las comunidades de productores/consumidores decidan si eso es un
referencia a una definición de tipo (tal vez bajo la especificación C, o Cv2, o la
alternativa CCv1.3, o...) o si solo quieren usar el multihash como
un identificador opaco. Entonces todavía puedes hacer cosas como:

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

es solo que GetType estaría agarrando el hash @context Link (o
donde sea), y TDirectory sería un multihash
(QmWellKnownDirectoryType).

las aplicaciones no deben _depender_ de que estos tipos sean correctos, pero
más bien aprovecharlos cuando lo sean.

Esto suena como un identificador opaco. Tal vez estamos diciendo lo mismo
cosa ;).

@tv42 también expresó su preocupación por las colisiones con los nombres de archivo, ya que
los nodos de directorio usan nombres de segmentos secundarios como sus claves.

si una estructura de datos dir ya tiene @context , no permitiría
la creación de otro archivo-- (o en el peor de los casos, agregar el enlace después
(clasificación estable)). es lo mismo que intentar crear dos archivos con el
mismo nombre.

Lo es si desea que los archivos @context sean ilegales;). Si quieres
permitir que la gente cree archivos @context , necesitará alguna forma de
eliminar la ambigüedad entre "este enlace apunta a un tipo" y "este enlace
apunta a un archivo/subdirectorio/…”. Pero hay varias formas
alrededor de ese problema, así que mientras elijamos uno de ellos, estaré feliz
;).

Tuve una conversación con @cryptix hace varios días y hablamos brevemente sobre el uso de JSON-LD. Solo me gustaría señalar que la especificación para json-ld permite el uso de un "enlace" para describir las asignaciones de json a json-ld. Personalmente, prefiero este enfoque porque permite que los metadatos cumplan con json-ld sin reestructurarlos para cualquier sabor de RDF que esté actualmente "de moda".

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

El viernes 1 de mayo de 2015 a las 09:24:27 p. m. -0700, W. Trevor King escribió:

Las extensiones de enlace deberían funcionar bien. Y anteponer claves de enlace a
el espacio de nombres tampoco es tan malo. Relleno de la información de tipo
into Data también funciona (así es como funcionan ahora los archivos y directorios
[1,2,3,4,5]). Enumerar tipos no es un enfoque sostenible, pero
cualquiera de estos lugares funcionaría como un lugar para almacenar un hash de tipo.

En una nota relacionada (distribuir ID de tipo hash junto con el
payload), @tv42 acaba de llamar mi atención sobre Ethos ETypes [1,2,3]. Entonces
Creo que tener algún tipo de espacio explícito para estas cosas sería
estupendo.

No he visto ETypes, gracias por aparecer. se leerá durante los próximos días. Algo relevante es el trabajo + relacionado con PADS de Kathleen Fisher. La página del proyecto PADS parece haber cambiado recientemente (si tan solo hubiera alguna tienda inmutable de contenido dirigido a la web...). (Pero el archivo de Internet nos salvó de nuevo \o/: http://web.archive.org/web/20130125041549/http://www.padsproj.org/ )

• PADS: un lenguaje específico de dominio para procesar datos ad hoc
• El Proyecto PADS: una visión general
• PADS/T: un lenguaje para describir y transformar datos ad hoc
• PADS/ML: un lenguaje de descripción de datos funcional
• LearnPADS: generación automática de herramientas a partir de datos ad-hoc
• más artículos: http://web.archive.org/web/20120205185831/http :// www.padsproj.org/doc.html#papers

De todos modos, PADS tiene mucho de la idea correcta. pero hasta ahora no ha visto una implementación amplia, que yo sepa. tal vez haya algo en el estilo de JSON-LD que pueda arreglar eso aquí.

JSON-LD no se trata solo de agregar un enlace @context . En particular, cada nombre de enlace (clave en JSON) debe pertenecer a una de estas categorías:

• @context : enlace de contexto o nodo en línea que describe los datos
• @id : la URI del nodo actual
• esquema://full-uri : se reconoce como un enlace cuyo predicado es el URI
• prefix:name : se reconoce como un enlace cuyo predicado es la concatenación del prefijo URI (definido en contexto) y el nombre
• nombre: se reconoce como un enlace solo si se define en contexto

En particular, JSON-LD no parece admitir mapas de clave/valor arbitrarios. Si la clave se puede interpretar como un URI, se considerará un predicado utilizando este URI. Por ejemplo, lo siguiente no es válido:

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

como http://xmlns.com/foaf/0.1/name siempre se referirá a un nombre FOAF, y no a la versión en caché de una página web.

Esto no es necesariamente un problema, pero debe tenerse en cuenta si decidimos interpretar los enlaces como datos enlazados al diseñar formatos de objetos. Por ejemplo, un directorio podría representarse de esta manera 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>"
    }
  ]
}

En IPFS-LD tendríamos un nodo para el directorio, enlazando a un contexto ya un nodo para cada entrada. Cada entrada tendría enlaces a su propio contexto, un nodo con su nombre y un nodo con el contenido del archivo.

Esto agrega múltiples niveles de direccionamiento indirecto, que son aceptables para documentos JSON (porque todo está empaquetado en un archivo), pero pueden no ser aceptables para IPFS, donde cada nodo tiene un hash diferente y debe rastrearse por separado.

Tal vez, lo que queremos no es usar JSON-LD tal cual, sino definir nuestro propio formato de contexto inspirado en JSON-LD. Esto sería mejor porque nuestro formato no es JSON y es muy específico: queremos poder describir mapas de teclas arbitrarios (para Unixfs) y también queremos usar la sección de datos de nuestros objetos IPFS (JSON no tiene eso). ).

Como la sección de enlace de los objetos IPFS es muy restrictiva, los enlaces tienen un nombre y apuntan a otro objeto. No puede contener valores literales. Lo que necesitamos especificar en el contexto es el nombre completo del enlace en forma de URI. Como también tenemos una sección de datos, necesitamos definir qué contiene.

Para unixfs, me imagino los siguientes objetos:

• directory :
  
  
  
  • enlace @context apuntando al contexto del directorio
  
  
  • enlace entry:README.md apuntando al objeto README.md
  
  
  • sin datos
  
  
• README.md :
  
  
  
  • enlace @context apuntando al contexto del archivo
  
  
  • sección de datos con el contenido de README.md
  
  
• directorio-contexto:

```
{
// @type : el tipo del objeto IPFS
"@type": " http://esquema/unixfs#Directorio "

// 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 de archivo:

```
{
"@type": " http://esquema/unixfs#Archivo "

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

}
```

Si quisiéramos representar esto en triples, tendrí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

Hola @mildred , excelente análisis. Curiosamente llegué a las mismas conclusiones en una conversación con dlongley en irc://irc.frennode.org#json -ld (puedo enviarle registros si está interesado)

He estado experimentando un poco con un tipo de IPLD más permisivo aquí; en particular, vea los ejemplos. estos no son definitivos (¿o correctos?), pero dan un sentido de dirección

• 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 el uso de @value , es incorrecto)
• 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

Notas importantes:

• enlaces relajantes para _permitir_ la inclusión de otros valores (muy solicitados), solo reservamos {"@type": "mlink", "hash": "<multihash>"}
• los usuarios pueden definir contextos para sus estructuras de datos
• puede _anidar_ enlaces, usando la notación de ruta para atravesar, por ejemplo, https://github.com/ipfs/go-ipld/blob/master/ipld.go#L122 -L141

Creo que tú y yo estamos muy en el camino correcto. También creo que probablemente podamos hacer mucho de esto sin desviarnos mucho de JSON-LD. simplemente eliminando algunas restricciones

@mildred registra aquí

también debería decir que, según mi conversación con dlongley, debería ser posible hacer lo que queramos sin desviarnos técnicamente del estándar JSON-LD, solo que _llamar a las transformaciones (compactación/expansión)_ eliminaría todos los "no -Teclas definidas por el contexto". (Debemos esforzarnos por no desviarnos)

Creo que eliminaría mucha confusión al pensar en JSON-LD en términos de triples generados, en lugar de lo que hace el analizador json-ld.js al transformar JSON. El paso de transformación JSON es específico para ese analizador y podría imaginarse transformarlo fácilmente de otra manera sin problemas.

Ahora, si entiendo bien lo que está haciendo con go-ipld , puede reemplazar la sección Enlace en los objetos IPFS actuales, ¿verdad? Esta cosa: merkledag.proto

Veo un problema ahí. Donde antes teníamos una estructura simple que permitía un procesamiento eficiente (nombre del enlace, directamente relacionado con la ruta y hash del enlace), ahora tenemos una estructura un poco más compleja. Para llegar al hash vinculado, debe resolver la cadena "mlink" en una tabla hash. ¿es eso realmente necesario?

Si desea datos vinculados / RDF, ¿por qué no simplemente definir su propio formato de cable (protobuf es excelente en lo que a mí respecta) y la forma en que se puede traducir a JSON? Luego use el contexto JSON-LD además de eso.

Ahora, sobre las diferentes estructuras de datos en las que estabas pensando, creo que son geniales, con la excepción de Unixfs: no podemos tener nombres de archivo como claves JSON-LD porque las claves JSON-LD deben, bajo todas las circunstancias, referirse a predicados RDF. Un nombre de archivo es un valor literal.

En lugar de:

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

Yo modelaría esto 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"
    }
  ]
}

De nuevo, la versión binaria/serializada no necesita ser así. La forma de representar esta última notación como tripas RDF sería:

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"

Estoy en IRC, no dudes en contactarme allí.

Para aquellos que no están familiarizados con RDF en este hilo, aquí hay una pequeña explicación:

RDF es una forma de estructurar sus datos. es el modelo de datos detrás de JSON-LD. En RDF, todos los datos deben codificarse en triples:

<subject> <predicate> <object>

• El sujeto es un nodo identificado por un URI
• El predicado es un URI como <http://www.w3.org/1999/02/22-rdf-syntax-ns#name> . El URI define de forma única la relación y, preferiblemente, debe estar bien definido en una especificación o esquema.
• El objeto es el destino del enlace/predicado. Puede ser un valor literal (una cadena, que puede escribirse opcionalmente, por ejemplo, como un número entero o una fecha, generalmente derivada del esquema xsd) o puede ser otro nodo, identificado por su URI

La notación triple supone que cada nodo sujeto y objeto tiene una URI que lo identifica de manera única. Define la estructura de datos completa enumerando todos los triples que contiene uno por línea.

Las claves JSON en JSON-LD son predicados que vinculan el sujeto (el objeto en el que está presente la clave) y el objeto: el valor de la clave JSON-LD. En este caso, los URI no se utilizan para referirse al sujeto y al objeto. Si desea especificar el URI de un objeto que se puede usar para referirse a él, existe la propiedad @id .

¿Hay algún artículo que explique cómo funcionan los datos vinculados a través de IPFS en comparación con cómo funcionan a través de HTTP? (¿Cómo son los URI? ¿Cuáles deberían ser las mejores prácticas para los editores y consumidores de datos vinculados sobre IPFS?)

Ver:

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

IPLD le brinda el modelo de datos json. puede superponer cualquier JSON-LD sobre IPLD.

(aún no aterrizado)

@jbenet acaba de leer este hilo, usar datos vinculados es una gran iniciativa en mi humilde opinión

Tiene razón en que los datos vinculados no exigen ninguna serialización. Es posible usar JSON-LD, RDF/XML, RDFa, Turtle o muchos otros formatos

Lo que Linked Data requiere es que las claves en JSON sean URI. Esto podría ser tan simple como prefijarlos con urn:string:<key> para lo cual, si se usa JSON-LD, podría hacerse como una línea en el contexto, o escribirse explícitamente.

Otra forma (generalmente preferida) sería colocar los términos para las claves en un documento http(s) o ipfs: que contenga descripciones legibles por humanos para cada término.

Creo que también son interesantes los metadatos para un hash de IPFS escrito en datos vinculados. Hice un intento rápido de esto hoy en Turtle, reutilizando el patrón descrito en 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

La idea de los datos vinculados es que los identificadores que le das a las cosas, si los buscas, les dan datos útiles, incluidos los datos que se vinculan a cosas relacionadas. Entonces, un directorio te da una lista de los URI de las cosas que contiene, un Evento te da la hora y los datos y los enlaces a las personas invitadas, las personas te dan enlaces a grupos y otras personas, y así sucesivamente. Hacer todo esto sobre ipfs: en lugar de http: por supuesto funciona bien, y podría vincular los dos espacios. Por ejemplo, puede afirmar que algo en un espacio es lo mismo que algo en otro. Podrías documentar a tus amigos en http: space y tus publicaciones documentadas en ipfs: space o lo que quieras.

(Como rdfhead, prefiero Turtle como formato porque lo encuentro simple y poderoso, pero puedes usar JSONLD seguro)

/me no puede conectarse a static.benet.ai para leer http://static.benet.ai/t/ipfs.pdf

@timbl puede encontrar una versión más actualizada del documento IPFS aquí: https://github.com/ipfs/papers/blob/master/ipfs-cap2pfs/ipfs-p2p-file-system.pdf o el mismo documento a través de puertas de enlace IPFS públicas: https://ipfs.io/ipfs/QmV9tSDx9UiPeWExXEeH6aoDvmihvx6jD5eLb4jbTaKGps

Por ejemplo, puede afirmar que algo en un espacio es lo mismo que algo en otro.

¡Sí! Estos son todos iguales:

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

Lo siento, el esquema dweb: URI y https://dweb.link en realidad aún no funcionan.

Por ahora es fs:/ipfs/somehash para URI (en el complemento IPFS Gateway Redirect) y https://ipfs.io/ipfs/somehash para HTTP:

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

En caso de que la gente de este hilo se lo haya perdido, ¡sucedió!

https://ipld.io/

continuemos la conversación en https://github.com/ipld/ipld

Por supuesto. Siéntase libre de entrar para discutir aspectos de los datos vinculados en:

https://gitter.im/linkeddata/chat

@nicola Estoy seguro de que no es ajeno a ese canal

De hecho, hoy discutíamos agregar ipfs: URI a nuestro sistema. ¡Mucha suerte con ipld!

¿Por qué usar el término bien definido "Datos vinculados" para algo que claramente no es LD?
https://www.w3.org/standards/semanticweb/data

Entonces, sé que este es un hilo antiguo, pero me estoy agregando para mezclarlo para la posteridad.

He estado trabajando en el modelo de datos de Credenciales verificables (https://w3c.github.io/vc-data-model/) y se me ocurrieron algunos problemas al conciliar el @context representado en JSON-LD frente a IPLD. (ver: https://github.com/w3c/vc-data-model/pull/261). Puedo reconocer que JSON-LD es completamente compatible con IPLD, pero IPLD no es completamente retrocompatible con JSON-LD, lo que sería necesario para la interoperabilidad con las especificaciones existentes. Tal como lo veo, la solución sería agregar ipld: como un esquema válido en ietf (ver: https://github.com/ipld/specs/issues/98) y luego permitir { <attr> : ipld:<cid> } sea lo mismo que { "/" : <cid> } logra en IPLD (ver: https://github.com/ipld/specs/issues/99). Registre también/adicionalmente el tipo de contenido MIME de application/ipld para declarar el tipo que define el protocolo. Esto se combinaría para permitir application/json+ipld frente a application/cbor+ipld para aliviar la confusión. ( @mildred No me gusta ipfs:// para esto porque necesitamos enlaces naturales y ` { "@context" : "/ipfs/" }' es un URI válido)

En cuanto a la interoperabilidad semántica, he estado colocando capas de contexto JSON-LD sobre IPLD. Sin embargo, esto genera un problema de enraizamiento, que se resuelve fácilmente incorporando URI como valores válidos en JSON-LD.

En última instancia, es Turtles todo el camino hacia abajo :turtle: > :turtle: > :turtle: hasta que llegas al final donde encuentras @timbl , por lo que creo que prefiere Turtle como formato : smiley:.

(Como rdfhead, prefiero Turtle como formato porque lo encuentro simple y poderoso, pero puedes usar JSONLD seguro)

Un ejemplo perfecto de esto es el manejo de fecha y hora en @context para credenciales verificables en https://w3id.org/did/v1 que enlaza con xsd:datetime que hace referencia a http://www.w3.org/ 2001/XMLSchema# , donde la explicación como fuente de documentación está en html .

Mi anotación favorita en este xml es:

Primero los tipos de datos primitivos incorporados. Estas definiciones son solo para información, las definiciones integradas reales son mágicas.

Puedo trabajar con esta magia, siempre que aceptemos que en la parte inferior de la pila de :tortuga: > :tortuga: > :tortuga: acordamos que es @timbl y luego podemos reconciliar la compatibilidad con versiones anteriores con JSON-LD usando lo anterior con ipld: .

@jonnycrunch Apoyo tus ideas. Turtle no es el más popular, porque JSON está bastante bien establecido en la web, especialmente porque JSON es nativo de los navegadores y tiene una curva de aprendizaje poco profunda.

Se debe lograr un equilibrio entre atraer a una amplia comunidad de desarrolladores y tener un sistema que sea interoperable (no algo tan blanco y negro) y rico en funciones.

El problema de @context desaparece si escribe la URL completa. Si bien son más caracteres, empiezo a pensar que es una práctica mejor, si no la mejor, dado que evita un viaje de ida y vuelta y no necesita verificar la integridad del archivo remoto.

En última instancia, surge la confusión en el sentido de que los URI son nombres (uuids) y localizadores (protocolo) y el cerebro no piensa fácilmente en ambos a la vez. Si podemos llegar al punto en el que usamos URI o abreviaturas de URI en las claves de nuestro JSON, muchos de estos problemas desaparecerán. De hecho, como nombrar ipfs: y http: deberían convertirse en parte de una red cooperativa, con datos vinculados como una especie de pegamento.

Actualicé mi comentario para usar la sintaxis ipld:<cid> al darme cuenta de que no tiene autoridad y, por lo tanto, no es digno de la barra doble ipld:// // . Dado que la carga útil se describe a sí misma, es su propia autoridad y debe valerse por sí misma. Pero ese es un argumento para los expertos.

@jonnycrunch escribió:

la solución sería agregar ipld: como esquema válido en IETF

Apoyo mucho este enfoque y creo que conduciría a una gran historia de interoperabilidad entre la comunidad de datos vinculados (más tradicional) y la comunidad de IPFS/IPLD.