Ipfs: IPFS-LD - Données liées

Hey @jbenet , excellent travail avec IPFS, très intéressé par ce que vous faites car nous envisageons d'utiliser des DHT (de type Kademlia) + des signatures numériques + un réseau de requêtes pour remplacer la dénomination sur Internet (remplacer éventuellement le DNS). Le travail de base que nous faisons est proche de ce que vous faites avec IPFS : https://manu.sporny.org/2014/identity-credentials/ . Nous utilisons JSON-LD pour cette initiative, connaissez-vous Telehash ? Sinon, vous devriez jeter un coup d'œil car certains de ces concepts pourraient renforcer IPFS.

Dans tous les cas, si vous souhaitez que les métadonnées sur le réseau soient lisibles et traitables par la machine mais de manière extensible, vous devez utiliser JSON-LD. Si vous utilisez JSON-LD, il y a de fortes chances que vous puissiez intégrer le travail sur les paiements Web et les informations d'identification qui se déroule au W3C, car ces deux ensembles de travaux sont également construits sur JSON-LD. L'un des principaux avantages de JSON-LD est que vous pouvez fusionner des données provenant de sources disparates. Une autre est que vous pouvez spécifier le format de données de base et permettre aux gens d'étendre le protocole sans coordination avec vous (ce qui est important si vous voulez que le système se développe à un rythme exponentiel).

Juste quelques réflexions, si vous avez des questions, n'hésitez pas. Exiger un @context dans chaque blob JSON sur le réseau n'est pas une exigence lourde.

merci pour les pensées!

nous envisageons d'utiliser des DHT (de type Kademlia) + des signatures numériques + un réseau de requêtes pour remplacer la dénomination sur Internet (remplacer éventuellement le DNS).

Assurez-vous ensuite de consulter la section IPNS dans le document : http://static.benet.ai/t/ipfs.pdf (3.7). :)

Connaissez-vous Telehash ?

Oui, j'approuve beaucoup le concept général + la volonté de le construire, mais je ne suis pas favorable à de nombreuses décisions du projet. Par exemple, le slogan est "JSON + UDP + DHT = Freedom" mais je pense que ces types de systèmes ne devraient (a) pas forcer un format de données, (b) ne pas forcer un protocole de transport, et (c) ne pas forcer un système de routage. Bien sûr, ces trois sont d'excellents choix _aujourd'hui_, mais ces protocoles doivent être conçus pour s'adapter à toutes les couches et dans le temps. IPFS permet ainsi aux utilisateurs d'utiliser n'importe quel format qu'ils désirent, IPFS peut se superposer à n'importe quel transport, et bien que le premier système de routage soit un DHT, il y en a d'autres à explorer.

Vous pouvez voir IPFS comme Telehash + le Web (merkle).

si vous souhaitez que les métadonnées sur le réseau soient lisibles et traitables par la machine mais de manière extensible, vous devez utiliser JSON-LD.

Je pense que nous pouvons prendre la partie -LD de votre travail sans avoir besoin de JSON comme transport. C'est-à-dire que je pense que votre travail (génial) est généralisable à n'importe quelle structure de données arborescente, et est bien meilleur que d'autres formats de web sémantique. (incroyable simplicité + flexibilité !) Donc, ce vers quoi je pointe dans ces notes, c'est d'utiliser l'équivalent de @context mais dans la structure de données de lien IPFS (qui n'est pas JSON, c'est un format binaire compressé pour une recherche rapide à travers des objets -- protobuf aujourd'hui, mais peut aussi être auto-descriptif plus tard -- J'ai l'intention d'IPFS d'être assez rapide pour fonctionner comme une base de données. pas aujourd'hui, mais dans le futur :) ).

Exiger un @context dans chaque blob JSON sur le réseau n'est pas une exigence lourde.

Oui, j'ai soutenu la même chose :)

@jbenet re: https://github.com/dataprotocols/dataprotocols/issues/110#issuecomment -43430309 - oui, je pensais que vos arguments étaient très bons et bien informés.

Je suis vraiment intéressé par ce que vous faites, j'ai parcouru le papier et j'ai commencé à regarder votre vidéo. Malheureusement, j'ai des délais que je dois respecter aujourd'hui, mais j'ai lu votre article et regardé la vidéo entière sur ma liste de choses à faire. Je ne sais pas si vous le savez, mais je travaille sur la construction de standards pour le Web via le W3C. Nous avons actuellement un ensemble de problèmes qui nécessitent une solution similaire à celle que vous décrivez. Je veux voir si nous pouvons intégrer une partie de votre travail dans la solution de connexion standard W3C de prochaine génération sur laquelle nous travaillons pour le Web (le message auquel j'ai fait allusion ci-dessus). Nous utilisons actuellement Telehash, mais nous avons quelques inquiétudes à ce sujet et vous semblez avoir décomposé le problème d'une manière qui pourrait mieux correspondre à nos cas d'utilisation.

Dans tous les cas, laissez-moi entrer dans ce que vous avez créé, puis revenez vers vous. Si vous n'avez pas de nouvelles de moi dans la semaine, veuillez me contacter à nouveau.

Hey @jbenet , j'ai eu l'occasion de parcourir le livre blanc plus en détail au cours du week-end et de regarder votre présentation. Fixons un moment pour parler cette semaine à venir. Je suis sur la côte est, aux États-Unis. Disponible de 10h à 14h la plupart des jours sauf mar/mer. Mon email : [email protected] , Skype : msporny , SIP : sip:[email protected] Contactez-moi dès que possible.

J'aimerais discuter d'ipns et de ce wrt. connexion sur le Web, Identifiants et Paiements Web : https://manu.sporny.org/2014/identity-credentials/

@msporny génial ! ça ira. Envoyé un e-mail tout à l'heure pour toucher la base. Vous voudrez peut-être supprimer vos coordonnées de ce problème (car il est public, etc.).

Nous étions en train de réfléchir à la façon de répondre aux questions "quel genre d'objet est-ce" sur IRC aujourd'hui. @jbenet a mentionné les liens de style LSON-LD @type ou @context , mais je ne sais pas comment vous sortez de cette chaîne . S'agit-il de liens @context ? @ tv42 a également soulevé des inquiétudes concernant les collisions avec les noms de fichiers , puisque les nœuds de répertoire utilisent les noms de segments enfants comme clés. Vous pouvez contourner ce problème en préfixant ou en échappant les noms de segment, mais cela semble être plus de travail que de simplement ajouter un champ Type explicite pour contenir l' ID de hachage pour la description de type . Si nous nous attendons à plus de ce genre de choses, cela appelle peut-être simplement le partitionnement des liens en ensembles internes et externes. Vous pouvez le faire avec l' approche d'extension Link protobuf proposée par @jbenet (si cela devient une chose) en ajoutant un booléen "interne" pour séparer l'entrée de type @context de toutes les entrées de fichier @context ( par exemple).

désolé, le format ne change (presque certainement) pas à ce stade. J'ai passé des mois à résumer cela et à ne plus ouvrir les vannes à ce sujet. les questions restantes (comme les extensions de liens) sont connues depuis un certain temps et il suffit de trouver la bonne façon de le faire.

un objet ipfs est un arbre comme json ou autre chose. cela signifie que toutes les solutions disponibles pour JSON (y compris JSON-LD, JSON-schema, etc.) sont disponibles pour IPFS. de plus, il est trivial de représenter des triplets RDF comme des objets ipfs. par conséquent, vous pouvez faire tout et n'importe quoi.

les données réelles sont très désordonnées. personne au monde n'a réussi à forcer les gens à adopter un système de typage de données particulier - et je ne vais pas m'attarder sur ces arguments. La seule solution qui me semble viable à long terme est de créer un système suffisamment flexible pour que les gens fassent ce qu'ils veulent, et juste assez rigide pour que tout soit lié.

maintenant, la manière _préférée_ - la façon dont nous suggérerons aux gens de faire les choses - sera probablement le @context / @type du (incroyablement puissant et simple) JSON-LD.

mais je ne sais pas comment vous sortir de cette chaîne

je ne comprends pas la question. il n'y a pas de chaîne, vous résolvez le contexte une fois et c'est tout. c'est le fichier de contexte de l'objet. si ce n'est pas un contexte valide -- il y a une spécification -- vous l'ignorez. les applications ne doivent pas _dépendre_ de la validité de ces types, mais plutôt les exploiter lorsqu'ils le sont.

@ tv42 a également soulevé des inquiétudes concernant les collisions avec les noms de fichiers, car les nœuds de répertoire utilisent les noms de segments enfants comme clés.

si une structure de données dir a déjà un @context il ne permettrait pas la création d'un autre fichier-- (ou au pire, ajouter le lien après (tri stable)). c'est la même chose que d'essayer de créer deux fichiers avec le même nom.

Le ven. 01 mai 2015 à 03:51:22 -0700, Juan Batiz-Benet a écrit :

désolé, le format ne change (très probablement) pas à ce stade. je
passé des mois à résumer cela et à ne pas ouvrir le déluge
portes à nouveau. les questions restantes (comme les extensions de lien)
sont connus depuis un certain temps et trouvent juste la bonne façon de faire
ce.

Les extensions de liens devraient fonctionner correctement. Et en préfixant les clés de lien à
l'espace de noms n'est pas si mal non plus. Remplir les informations de type
into Data fonctionne aussi (c'est ainsi que les fichiers et les répertoires fonctionnent maintenant
[1,2,3,4,5]). L'énumération des types n'est pas une approche durable, mais
n'importe lequel de ces endroits fonctionnerait comme un endroit pour stocker un hachage de type.

maintenant, la manière _préférée_ -- la façon dont nous suggérons aux gens de faire les choses
-- va probablement être le @context / @type du
(étonnamment puissant et simple) JSON-LD.

JSON-LD est bien, mais l'écosystème qui l'entoure devra comprendre
que le préfixe @ est spécial. Je préférerais que la particularité soit stockée
explicitement en étendant les entrées Lien avec des données supplémentaires (par exemple, un
drapeau interne/externe) afin que nous n'ayons pas d'ambiguïté entre un @context
file et un lien de type @context . Mais si tous les liens de fichiers/sous-répertoires sont codés
avec un enfant/', alors vous pourriez avoir un 'contexte' pour le type
lien et 'enfant/contexte' pour le fichier (ou autre). ça va encore
doit être une convention définie en externe que les générateurs d'objets
et les consommateurs doivent se mettre d'accord par le biais d'un canal non auto-descriptif.

mais je ne sais pas comment vous sortir de cette chaîne

je ne comprends pas la question. il n'y a pas de chaîne, vous résolvez
contexte une fois et c'est tout. c'est le fichier de contexte pour le
objet. si ce n'est pas un contexte valide - il y a une spécification - vous
ignorez-le.

Ça marche pour moi. Je me demandais comment tu terminais une auto-description
chaîne:

De quel type est A ? Suivons simplement A/ @context vers B. Quel type est B ?
Suivons simplement B/ @context vers C…

Mais si vous distribuez la spécification B (C dans mon exemple), il n'y a pas
besoin d'un lien B/ @context . Mais si vous avez un canal pour
distribuant la spécification de type (C), pourquoi ne pas l'utiliser également pour distribuer le
schémas de type eux-mêmes (B) ? Il semble qu'il vaut mieux avoir juste un
place conventionnelle dans les objets qui contient un multihash décrivant leur
type (votre lien @context , ou autre). Ensuite, écartez-vous et
laisser aux communautés de producteurs/consommateurs le soin de décider s'il s'agit d'un
référence à une définition de type (peut-être sous la spécification C, ou Cv2, ou la
alternative CCv1.3, ou …) ou s'ils veulent juste utiliser le multihash comme
un identifiant opaque. Ensuite, vous pouvez toujours faire des choses comme :

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

c'est juste que GetType saisirait le hachage du lien @context (ou
partout), et TDirectory serait un multihash
(QmWellKnownDirectoryType).

les applications ne doivent pas _ dépendre _ de la validité de ces types, mais
utilisez-les plutôt quand ils le sont.

Cela ressemble à un identifiant opaque. Peut-être que nous disons la même chose
chose ;).

@ tv42 a également soulevé des inquiétudes concernant les collisions avec les noms de fichiers, car
les nœuds de répertoire utilisent des noms de segments enfants comme clés.

si une structure de données dir a déjà un @context il ne permettrait pas
la création d'un autre fichier-- (ou au pire, ajouter le lien après
(tri stable)). c'est la même chose que d'essayer de créer deux fichiers avec le
même nom.

C'est si vous voulez rendre les fichiers @context illégaux ;). Si tu veux
permettre aux gens de créer des fichiers @context , vous aurez besoin d'un moyen de
lever l'ambiguïté entre "ce lien pointe vers un type" et "ce lien
pointe sur un fichier/sous-répertoire/… ». Mais il y a plusieurs façons
autour de ce problème, donc tant que nous en choisissons un, je serai heureux
;).

J'ai eu une conversation avec @cryptix il y a plusieurs jours et nous avons brièvement parlé de l'utilisation de JSON-LD. Je voudrais juste souligner que la spécification de json-ld permet l'utilisation d'un "lien" pour décrire les mappages de json à json-ld. Personnellement, je préfère cette approche car elle permet aux métadonnées d'être conformes à json-ld sans les restructurer pour la saveur de RDF actuellement "branchée".

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

Le vendredi 01 mai 2015 à 21:24:27 -0700, W. Trevor King a écrit :

Les extensions de liens devraient fonctionner correctement. Et en préfixant les clés de lien à
l'espace de noms n'est pas si mal non plus. Remplir les informations de type
into Data fonctionne aussi (c'est ainsi que les fichiers et les répertoires fonctionnent maintenant
[1,2,3,4,5]). L'énumération des types n'est pas une approche durable, mais
n'importe lequel de ces endroits fonctionnerait comme un endroit pour stocker un hachage de type.

Sur une note connexe (distribution d'ID de type haché avec le
charge utile), @ tv42 vient d'attirer mon attention sur Ethos ETypes [1,2,3]. Alors
Je pense qu'avoir une sorte d'emplacement explicite pour ces choses serait
génial.

Je n'ai pas vu ETypes, merci d'avoir fait surface. lira au cours des prochains jours. Quelque chose de pertinent est le travail PADS de Kathleen Fisher + lié. La page du projet PADS semble avoir été modifiée récemment (si seulement il y avait un magasin immuable adressé au contenu du Web...). (Mais les archives Internet nous ont encore sauvé \o/ : http://web.archive.org/web/20130125041549/http://www.padsproj.org/ )

• PADS : un langage spécifique à un domaine pour le traitement de données ad hoc
• Le projet PADS : un aperçu
• PADS/T : un langage pour décrire et transformer des données ad hoc
• PADS/ML : un langage de description de données fonctionnel
• LearnPADS : génération automatique d'outils à partir de données ad-hoc
• plus d' articles : http://web.archive.org/web/20120205185831/http://www.padsproj.org/doc.html#papers

Quoi qu'il en soit, PADS a tout à fait la bonne idée. mais jusqu'à présent, je n'ai pas vu de mise en œuvre à grande échelle, à ma connaissance. peut-être y a-t-il quelque chose dans le style de JSON-LD qui peut résoudre ce problème ici.

JSON-LD ne consiste pas seulement à ajouter un lien @context . En particulier, chaque nom de lien (clé en JSON) doit appartenir à l'une de ces catégories :

• @context : lien de contexte ou nœud en ligne décrivant les données
• @id : l'URI du nœud courant
• scheme://full-uri : est reconnu comme un lien dont le prédicat est l'URI
• prefix:name : est reconnu comme un lien dont le prédicat est la concaténation du préfixe URI (défini en contexte) et du nom
• nom : est reconnu comme un lien uniquement s'il est défini dans le contexte

En particulier, JSON-LD ne semble pas prendre en charge les mappages clé/valeur arbitraires. Si la clé peut être interprétée comme un URI, elle sera considérée comme un prédicat utilisant cet URI. Par exemple, ce qui suit n'est pas valide :

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

comme http://xmlns.com/foaf/0.1/name fera toujours référence à un nom FOAF, et non à la version en cache d'une page Web.

Ce n'est pas nécessairement un problème mais doit être pris en compte si nous décidons d'interpréter les liens comme des données liées lors de la conception de formats d'objets. Par exemple, un répertoire pourrait être représenté de cette façon en utilisant 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>"
    }
  ]
}

Dans IPFS-LD, nous aurions un nœud pour le répertoire, lié à un contexte et à un nœud pour chaque entrée. Chaque entrée aurait alors des liens vers son propre contexte, un nœud contenant son nom et un nœud avec le contenu du fichier.

Cela ajoute plusieurs niveaux d'indirection, qui sont acceptables pour les documents JSON (car tout est emballé dans un seul fichier) mais peuvent ne pas être acceptables pour IPFS où chaque nœud a un hachage différent et doit être suivi séparément.

Peut-être que ce que nous voulons, ce n'est pas utiliser JSON-LD tel quel, mais définir notre propre format de contexte inspiré de JSON-LD. Ce serait mieux parce que notre format n'est pas JSON, et est très spécifique : nous voulons pouvoir décrire des mappages de touches arbitraires (pour unixfs) et nous voulons également utiliser la section de données de nos objets IPFS (JSON n'a pas cela ).

Comme la section lien des objets IPFS est très restrictive, les liens ont un nom et pointent vers un autre objet. Il ne peut pas contenir de valeurs littérales. Ce que nous devons spécifier dans le contexte est le nom complet du lien sous la forme URI. Comme nous avons également une section de données, nous devons définir ce qu'elle contient.

Pour unixfs, j'imaginerais les objets suivants :

• directory :
  
  
  
  • lien @context pointant vers le contexte du répertoire
  
  
  • lien entry:README.md pointant vers l'objet README.md
  
  
  • pas de données
  
  
• README.md :
  
  
  
  • lien @context pointant vers le contexte du fichier
  
  
  • section de données avec le contenu de README.md
  
  
• contexte-répertoire :

```
{
// @type : le type de l'objet 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"
}

}
```

• contexte de fichier :

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

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

}
```

Si nous voulions représenter cela en triplets, nous aurions :

# 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

Hey @mildred - excellente analyse. Curieusement, j'ai atteint les mêmes conclusions lors d'une conversation avec dlongley sur irc://irc.frennode.org#json -ld (peut vous envoyer des journaux si vous êtes intéressé)

J'ai expérimenté un peu avec un type de chose IPLD plus permissif ici - en particulier voir les exemples. ceux-ci ne sont pas définitifs (ou corrects ?), mais donnent une idée de l'orientation

• 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 (ignorez l'utilisation de @value , c'est incorrect)
• 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

Notes IMPORTANTES:

• liens relaxants pour _autoriser_ l'inclusion d'autres valeurs (très demandées), nous ne réservons que {"@type": "mlink", "hash": "<multihash>"}
• les utilisateurs peuvent définir des contextes pour leurs structures de données
• peut _imbriquer_ des liens, en utilisant la notation de chemin pour traverser, par exemple https://github.com/ipfs/go-ipld/blob/master/ipld.go#L122 -L141

Je pense que vous et moi sommes sur la bonne voie. Je pense aussi que nous pouvons probablement faire beaucoup de cela sans trop nous écarter de JSON-LD. simplement supprimer certaines restrictions

@mildred se connecte ici

devrait également dire que - d'après ma conversation avec dlongley - il devrait être possible de faire ce que nous voulons sans dévier techniquement de la norme JSON-LD, juste que _appeler les transformations (compactage/expansion)_ supprimerait tous les "non -clés définies par le contexte". (nous devons nous efforcer de ne pas dévier)

Je pense que vous élimineriez beaucoup de confusion en pensant à JSON-LD en termes de triplets générés, plutôt qu'à ce que fait l'analyseur json-ld.js lors de la transformation de JSON. L'étape de transformation JSON est spécifique à cet analyseur et vous pouvez imaginer facilement le transformer d'une autre manière sans problème.

Maintenant, si je comprends bien ce que vous faites avec go-ipld , cela peut remplacer la section Link dans les objets IPFS actuels, n'est-ce pas ? Ce truc : merkledag.proto

J'y vois un problème. Là où nous avions auparavant une structure simple qui permettait un traitement efficace (nom du lien, directement lié au chemin et hachage du lien), nous avons maintenant une structure un peu plus complexe. Pour accéder au hachage lié, vous devez résoudre la chaîne "mlink" dans une table de hachage. est-ce vraiment nécessaire?

Si vous voulez des données liées / RDF, pourquoi ne pas simplement définir votre propre format de fil (protobuf est génial en ce qui me concerne) et la façon dont il peut être traduit en JSON. Utilisez ensuite le contexte JSON-LD en plus de cela.

Maintenant, à propos des différentes structures de données auxquelles vous pensiez, je pense qu'elles sont excellentes, à l'exception des unixfs : nous ne pouvons pas avoir de noms de fichiers en tant que clés JSON-LD car les clés JSON-LD doivent en toutes circonstances faire référence à des prédicats RDF. Un nom de fichier est une valeur littérale.

Au lieu de:

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

Je modéliserais cela comme:

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

Encore une fois, la version binaire/sérialisée n'a pas besoin d'être comme ça. La façon de représenter cette dernière notation sous forme de tripes RDF serait :

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"

Je suis sur IRC, n'hésitez pas à m'y envoyer un ping.

Pour ceux qui ne connaissent pas RDF sur ce fil, voici une petite explication :

RDF est un moyen de structurer vos données. c'est le modèle de données derrière JSON-LD. En RDF, toutes les données doivent être encodées en triplets :

<subject> <predicate> <object>

• Le sujet est un nœud identifié par un URI
• Le prédicat est un URI comme <http://www.w3.org/1999/02/22-rdf-syntax-ns#name> . L'URI définit la relation de manière unique et devrait de préférence être bien défini dans une spécification ou un schéma.
• L'objet est la cible du lien/prédicat. Il peut s'agir d'une valeur littérale (une chaîne, qui peut éventuellement être typée, par exemple comme un entier ou une date, généralement dérivée du schéma xsd) ou il peut s'agir d'un autre nœud, identifié par son URI

La triple notation suppose que chaque nœud de sujet et d'objet a un URI qui l'identifie de manière unique. Il définit la structure de données complète en listant tous les triplets qu'il contient un par ligne.

Les clés JSON dans JSON-LD sont des prédicats qui relient le sujet (l'objet dans lequel la clé est présente) et l'objet : la valeur de la clé JSON-LD. Dans ce cas, les URI ne sont pas utilisées pour faire référence au sujet et à l'objet. Si vous souhaitez spécifier l'URI d'un objet qui peut être utilisé pour y faire référence, il existe la propriété @id .

Existe-t-il un article expliquant comment fonctionnent les données liées sur IPFS par rapport à leur fonctionnement sur HTTP ? (À quoi ressemblent les URI ? Quelles devraient être les meilleures pratiques pour les éditeurs et les consommateurs de données liées sur IPFS ?)

Voir:

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

IPLD vous donne le modèle de données json. vous pouvez superposer n'importe quel JSON-LD sur IPLD.

(pas encore atterri)

@jbenet vient de lire ce fil, l'utilisation de données liées est une excellente initiative à mon humble avis

Vous avez raison de dire que les données liées n'imposent aucune sérialisation. Il est possible d'utiliser JSON-LD, RDF/XML, RDFa, Turtle ou un tas d'autres formats

Ce que les données liées exigent, c'est que les clés dans JSON soient des URI. Cela pourrait être aussi simple que de les préfixer avec urn:string:<key> pour lequel, si l'utilisation de JSON-LD peut être effectuée comme une seule ligne dans le contexte, ou écrite explicitement.

Une autre façon (généralement préférée) serait de mettre les termes pour les clés dans un document http(s) ou ipfs: qui contient des descriptions lisibles par l'homme pour chaque terme.

Je pense que les métadonnées pour un hachage IPFS écrit dans Linked Data sont également intéressantes. J'ai fait une tentative rapide de cela aujourd'hui dans Turtle, en réutilisant le modèle décrit dans 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

L'idée des données liées est que les identifiants que vous donnez aux choses, si vous les recherchez, leur donnent des données utiles, y compris des données qui sont liées à des choses liées. Ainsi, un répertoire vous donne une liste des URI des éléments qu'il contient, un événement vous donne l'heure, les données et les liens vers les personnes invitées, les personnes vous donnent des liens vers des groupes et d'autres personnes, etc. Faire tout cela sur ipfs: au lieu de http: bien sûr fonctionne bien, et vous pouvez lier les deux espaces. Vous pouvez par exemple affirmer que quelque chose dans un espace est identique à quelque chose dans un autre. Vous pouvez documenter vos amis dans http: space et documenter vos publications dans ipfs: space ou tout ce que vous voulez.

(En tant que rdfhead, je préfère Turtle comme format car je le trouve simple et puissant mais vous pouvez utiliser JSONLD bien sûr)

/me ne peut pas se connecter à static.benet.ai pour lire http://static.benet.ai/t/ipfs.pdf

@timbl vous pouvez trouver une version plus à jour du document IPFS ici : https://github.com/ipfs/papers/blob/master/ipfs-cap2pfs/ipfs-p2p-file-system.pdf ou le même article via les passerelles IPFS publiques : https://ipfs.io/ipfs/QmV9tSDx9UiPeWExXEeH6aoDvmihvx6jD5eLb4jbTaKGps

Vous pouvez par exemple affirmer que quelque chose dans un espace est identique à quelque chose dans un autre.

Oui! Ce sont tous les mêmes :

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

Désolé, le schéma dweb: URI et https://dweb.link ne fonctionnent pas encore.

Pour l'instant, c'est fs:/ipfs/somehash pour les URI (dans l'addon IPFS Gateway Redirect) et https://ipfs.io/ipfs/somehash pour HTTP :

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

Au cas où les gens sur ce fil l'auraient manqué, c'est arrivé !

https://ipld.io/

continuons la conversation sur https://github.com/ipld/ipld

Sûr. N'hésitez pas à venir discuter des aspects des données liées à :

https://gitter.im/linkeddata/chat

@nicola Je suis sûr que ce canal n'est pas étranger

Nous discutions en fait de l'ajout d'ipfs : URI à notre système aujourd'hui. Bonne chance avec ipld !

Pourquoi utiliser le terme bien défini "Données liées" pour quelque chose qui n'est clairement pas LD ?
https://www.w3.org/standards/semanticweb/data

donc, je sais que c'est un vieux fil mais je m'ajoute au mix pour la postérité.

J'ai travaillé sur le modèle de données Verifiable Credentials (https://w3c.github.io/vc-data-model/) et j'ai rencontré quelques problèmes pour concilier les @context représentés dans JSON-LD vs IPLD. (voir : https://github.com/w3c/vc-data-model/pull/261 ). Je peux reconnaître que JSON-LD est complètement compatible avec IPLD, mais IPLD n'est pas complètement rétrocompatible avec JSON-LD, ce qui serait nécessaire pour l'interopérabilité avec les spécifications existantes. Selon moi, la solution serait d'ajouter ipld: comme schéma valide dans ietf (voir : https://github.com/ipld/specs/issues/98 ) puis d'autoriser { <attr> : ipld:<cid> } soit le même que ce que { "/" : <cid> } accomplit dans IPLD (voir : https://github.com/ipld/specs/issues/99). Enregistrez également/en plus le type de contenu MIME de application/ipld pour déclarer le type qui définit le protocole. Cela aggraverait pour permettre application/json+ipld vs application/cbor+ipld pour atténuer la confusion. ( @mildred Je n'aime pas ipfs:// pour cela car nous avons besoin d'un lien naturel et ` { "@context" : "/ipfs/" }' est un URI valide )

En ce qui concerne l'interopérabilité sémantique, j'ai superposé le contexte JSON-LD sur IPLD. Cependant, cela pose un problème d'enracinement, facilement résolu en incorporant des URI en tant que valeurs valides dans le JSON-LD.

En fin de compte, c'est Turtles tout le long :turtle: > :turtle: > :turtle: jusqu'à ce que vous arriviez au bas où vous trouvez @timbl , c'est pourquoi je pense qu'il préfère Turtle comme format : smiley:.

(En tant que rdfhead, je préfère Turtle comme format car je le trouve simple et puissant mais vous pouvez utiliser JSONLD bien sûr)

Un exemple parfait de ceci est la gestion de la date et de l'heure dans @context pour les informations d'identification vérifiables sur https://w3id.org/did/v1 qui renvoie à xsd:datetime qui fait référence à http://www.w3.org/ 2001/XMLSchema# , où l'explication en tant que source de documentation est en html .

Mon annotation préférée dans ce xml est :

D'abord les types de données primitifs intégrés. Ces définitions sont à titre indicatif uniquement, les véritables définitions intégrées sont magiques.

Je peux travailler avec cette magie, tant que nous acceptons qu'au bas de la pile de :turtle: > :turtle: > :turtle: nous convenons que c'est @timbl et ensuite nous pouvons réconcilier la rétrocompatibilité avec JSON-LD en utilisant ci-dessus avec ipld: .

@jonnycrunch Je soutiens vos idées. Turtle n'est pas le plus populaire, car JSON est assez bien implanté sur le web, d'autant plus que JSON est natif des navigateurs, et a une courbe d'apprentissage peu profonde.

Il y a un équilibre à trouver entre faire appel à une large communauté de développeurs et avoir un système interopérable (pas quelque chose d'aussi noir et blanc) et riche en fonctionnalités.

Le problème @context disparaît si vous tapez l'URL complète. Bien qu'il y ait plus de caractères, je commence à penser que c'est une meilleure pratique, sinon la meilleure, étant donné qu'elle évite un aller-retour et que vous n'avez pas besoin de vérifier l'intégrité du fichier distant.

En fin de compte, la confusion survient dans la mesure où les URI sont à la fois des noms (uuids) et des localisateurs (protocole) et le cerveau ne pense pas facilement aux deux à la fois. Si nous pouvons arriver au point où nous utilisons des URI ou des raccourcis pour les URI dans les clés de notre JSON, bon nombre de ces problèmes disparaissent. En effet, comme nommage ipfs: et http: devraient faire partie d'un réseau coopératif, avec des données liées comme une sorte de ciment.

J'ai mis à jour mon commentaire pour utiliser la syntaxe ipld:<cid> en réalisant qu'il ne fait pas autorité et donc pas digne de la double barre oblique $# ipld:// // . Étant donné que la charge utile est auto-descriptive, elle est sa propre autorité et doit être autonome. Mais c'est un argument pour les experts.

@jonnycrunch a écrit :

la solution serait d'ajouter ipld: comme schéma valide dans IETF

Je suis très favorable à cette approche et je pense que cela conduirait à une excellente histoire d'interopérabilité entre la communauté (plus traditionnelle) des données liées et la communauté IPFS / IPLD.