Ipfs: IPFS-LD – Verknüpfte Daten

Hey @jbenet , tolle Arbeit mit IPFS, sehr interessiert an dem, was Sie tun, da wir uns mit der Verwendung von DHTs (Kademlia-ähnlich) + digitalen Signaturen + Abfragenetzwerk befassen, um die Benennung im Internet zu ersetzen (ersetzen schließlich DNS). Die grundlegende Arbeit, die wir leisten, ähnelt der, die Sie mit IPFS machen: https://manu.sporny.org/2014/identity-credentials/ . Wir verwenden JSON-LD für diese Initiative, kennen Sie Telehash? Wenn nicht, sollten Sie einen Blick darauf werfen, da einige dieser Konzepte IPFS stärken könnten.

Wer möchte, dass die Metadaten im Netz maschinenlesbar und verarbeitbar, aber erweiterbar sind, sollte auf jeden Fall JSON-LD verwenden. Wenn Sie JSON-LD verwenden, besteht eine gute Chance, dass Sie die beim W3C stattfindenden Arbeiten zu Webzahlungen und Anmeldeinformationen integrieren können, da diese beiden Arbeitspakete ebenfalls auf JSON-LD aufbauen. Einer der Hauptvorteile von JSON-LD besteht darin, dass Sie Daten aus unterschiedlichen Quellen zusammenführen können. Ein weiterer Grund ist, dass Sie das grundlegende Datenformat spezifizieren und anderen erlauben können, das Protokoll ohne Abstimmung mit Ihnen zu erweitern (was wichtig ist, wenn Sie möchten, dass das System exponentiell wächst).

Nur einige Gedanken, wenn Sie Fragen haben, fragen Sie bitte. Das Erfordernis eines @context in jedem JSON-Blob im Netzwerk ist keine schwere Anforderung.

danke für die gedanken!

Wir prüfen die Verwendung von DHTs (Kademlia-ähnlich) + digitalen Signaturen + Abfragenetzwerk, um die Benennung im Internet zu ersetzen (ersetzen schließlich DNS).

Dann sehen Sie sich unbedingt den IPNS-Abschnitt im Papier an: http://static.benet.ai/t/ipfs.pdf (3.7). :)

Kennen Sie Telehash?

Ja, ich stimme dem Gesamtkonzept sehr zu + dem Antrieb, es zu bauen, aber ich bin nicht für viele Entscheidungen des Projekts. In diesem Fall lautet der Slogan „JSON + UDP + DHT = Freedom“, aber ich denke, dass diese Art von Systemen (a) kein Datenformat erzwingen, (b) kein Transportprotokoll erzwingen und (c) kein a erzwingen sollte Routing-System. Natürlich sind diese drei _heute_ eine gute Wahl, aber diese Protokolle müssen so aufgebaut sein, dass sie über Schichten und über die Zeit hinweg passen. IPFS ermöglicht es Benutzern daher, jedes gewünschte Format zu verwenden, IPFS kann jedem Transport überlagert werden, und obwohl das erste Routing-System ein DHT sein wird, gibt es noch andere zu erkunden.

Sie können IPFS als Telehash + das (merkle) Web sehen.

Wenn Sie möchten, dass die Metadaten im Netzwerk maschinenlesbar und verarbeitbar, aber erweiterbar sind, sollten Sie JSON-LD verwenden.

Ich denke, wir können den -LD-Teil Ihrer Arbeit übernehmen, ohne JSON als Transportmittel zu benötigen. Das heißt, ich denke, Ihre (großartige) Arbeit ist auf jede Baumdatenstruktur verallgemeinerbar und weitaus besser als andere semantische Webformate. (erstaunliche Einfachheit + Flexibilität!) Worauf ich in diesen Notizen hinweise, ist die Verwendung des Äquivalents von @context , aber in der IPFS-Link-Datenstruktur (die kein JSON ist, sondern ein binär gepacktes Format zum schnellen Durchsuchen von Objekten). -- protobuf heute, kann aber später auch selbstbeschreibend sein -- ich beabsichtige, dass IPFS schnell genug ist, um als Datenbank zu arbeiten. nicht heute, aber in der Zukunft :) ).

Das Erfordernis eines @context in jedem JSON-Blob im Netzwerk ist keine schwere Anforderung.

Ja, das habe ich auch behauptet :)

@jbenet re: https://github.com/dataprotocols/dataprotocols/issues/110#issuecomment -43430309 - ja, ich fand Ihre Argumente dort sehr gut und gut informiert.

Ich interessiere mich wirklich dafür, was Sie tun, ich habe die Zeitung überflogen und angefangen, mir Ihr Video anzusehen. Leider habe ich heute Fristen, die ich durchhalten muss, aber ich habe auf meiner To-Do-Liste das Lesen Ihres Aufsatzes und das Ansehen des gesamten Videos. Ich weiß nicht, ob Sie das wissen, aber ich arbeite über das W3C an der Entwicklung von Standards für das Web. Wir haben derzeit eine Reihe von Problemen, die eine ähnliche Lösung wie die von Ihnen skizzierte erfordern. Ich möchte sehen, ob wir einige Ihrer Arbeiten in die nächste Generation der W3C-Standard-Login-Lösung integrieren können, an der wir für das Web arbeiten (der Beitrag, auf den ich oben angespielt habe). Wir verwenden derzeit Telehash, haben aber einige Bedenken, und Sie scheinen das Problem auf eine Weise zerlegt zu haben, die besser zu unseren Anwendungsfällen passt.

Lassen Sie mich auf jeden Fall auf das eingehen, was Sie erstellt haben, und dann auf Sie zurückkommen. Wenn Sie innerhalb der Woche nichts von mir hören, pingen Sie mich bitte erneut an.

Hallo @jbenet , ich hatte am Wochenende Gelegenheit, das Whitepaper genauer durchzusehen und mir Ihre Präsentation anzusehen. Lassen Sie uns in der kommenden Woche einen Gesprächstermin vereinbaren. Ich bin an der Ostküste, USA. An den meisten Tagen von 10:00 bis 14:00 Uhr verfügbar, außer dienstags und mittwochs. Meine E-Mail: [email protected] , Skype: msporny , SIP: sip:[email protected] Setzen Sie sich so schnell wie möglich mit mir in Verbindung.

Ich möchte ipns und dieses wrt besprechen. Login im Web, Credentials und Web Payments: https://manu.sporny.org/2014/identity-credentials/

@msporny toll! Wird besorgt. Habe gerade eine E-Mail an Touch Base gesendet. Möglicherweise möchten Sie Ihre Kontaktdaten aus diesem Problem entfernen (da es öffentlich ist usw.).

Wir haben heute im IRC herumgespielt, wie man die Fragen „Was für ein Objekt ist das?“ beantworten kann. @jbenet erwähnte @type - oder @context -Links im LSON-LD-Stil, aber ich bin mir nicht sicher, wie Sie aus dieser Kette ausbrechen . Sind es @context Links bis ganz nach unten? @tv42 äußerte auch Bedenken hinsichtlich Kollisionen mit Dateinamen , da Verzeichnisknoten untergeordnete Segmentnamen als Schlüssel verwenden. Sie könnten dies umgehen, indem Sie den Segmentnamen ein Präfix voranstellen oder sie auf andere Weise mit Escapezeichen versehen, aber das scheint mehr Arbeit zu sein, als nur ein explizites Typfeld hinzuzufügen, das die Hash-ID für die Typbeschreibung enthält . Wenn wir mehr davon erwarten, ruft es vielleicht nur dazu auf, Links in interne und externe Sätze zu unterteilen. Sie könnten dies mit dem von @jbenet vorgeschlagenen Link protobuf-Erweiterungsansatz tun (falls das eine Sache wird), indem Sie einen „internen“ booleschen Wert hinzufügen, um den Eintrag vom Typ @context von allen @context -Dateieinträgen zu trennen ( zum Beispiel).

Entschuldigung, das Format ändert sich (mit ziemlicher Sicherheit) an dieser Stelle nicht. Ich habe Monate damit verbracht, es darauf zu reduzieren und werde die Schleusen dafür nicht wieder öffnen. Die restlichen Fragen (wie Linkerweiterungen) sind seit einiger Zeit bekannt und nur der richtige Weg, es zu tun.

Ein ipfs-Objekt ist ein Baum wie json oder irgendetwas anderes. Das bedeutet, dass alle für JSON verfügbaren Lösungen (einschließlich JSON-LD, JSON-Schema usw.) für IPFS verfügbar sind. außerdem ist es trivial, RDF-Tripel als ipfs-Objekte darzustellen. Daher können Sie alles und jedes tun.

reale Daten sind sehr chaotisch. Niemand auf der Welt hat es geschafft, Menschen dazu zu zwingen, ein bestimmtes Datentypisierungssystem zu übernehmen – und ich werde keine Zeit in diese Argumente verschwenden. Die einzige Lösung, die meiner Meinung nach langfristig tragfähig ist, besteht darin, ein System flexibel genug zu machen, damit die Menschen tun können, was sie wollen, und gerade so starr, dass alles miteinander verknüpft ist.

Jetzt ist die _bevorzugte_ Methode – die Art und Weise, wie wir Leuten vorschlagen, Dinge zu tun – wahrscheinlich die @context / @type aus dem (erstaunlich leistungsfähigen und einfachen) JSON-LD.

aber ich bin mir nicht sicher, wie du aus dieser Kette ausbrechen kannst

Ich verstehe die Frage nicht. Es gibt keine Kette, Sie lösen den Kontext einmal auf und das war's. das ist die Kontextdatei für das Objekt. Wenn es kein gültiger Kontext ist – es gibt eine Spezifikation – ignorieren Sie ihn. Anwendungen sollten nicht _abhängig_ davon sein, dass diese Typen korrekt sind, sondern sie nutzen, wenn sie es sind.

@tv42 hat auch Bedenken wegen Kollisionen mit Dateinamen geäußert, da Verzeichnisknoten untergeordnete Segmentnamen als Schlüssel verwenden.

Wenn eine dir-Datenstruktur bereits ein @context hat, würde es die Erstellung einer anderen Datei nicht zulassen -- (oder im schlimmsten Fall den Link danach anhängen (stabile Sortierung)). Es ist dasselbe wie der Versuch, zwei Dateien mit demselben Namen zu erstellen.

Am Freitag, den 1. Mai 2015 um 03:51:22 -0700 schrieb Juan Batiz-Benet:

Entschuldigung, das Format ändert sich (höchstwahrscheinlich) an dieser Stelle nicht. ich
verbrachte Monate damit, es darauf herunterzukochen und die Flut nicht zu öffnen
Tore darauf wieder. die verbleibenden Fragen (wie Linkerweiterungen)
sind seit einiger Zeit bekannt und finden gerade den richtigen Weg
es.

Link-Erweiterungen sollten gut funktionieren. Und Verknüpfungsschlüssel voranstellen
Namensraum sie ist auch nicht so schlimm. Füllen der Typinformationen
into Data funktioniert auch (so funktionieren jetzt Dateien und Verzeichnisse
[1,2,3,4,5]). Das Aufzählen von Typen ist kein nachhaltiger Ansatz, aber
Jeder dieser Orte würde als Ort zum Speichern eines Typ-Hashes funktionieren.

jetzt die _bevorzugte_ Art – die Art und Weise, wie wir Leuten vorschlagen, Dinge zu tun
-- wird wahrscheinlich @context / @type von sein
(erstaunlich leistungsstark und einfach) JSON-LD.

JSON-LD ist in Ordnung, aber das Ökosystem um ihn herum muss es verstehen
dass das @-Präfix etwas Besonderes ist. Ich würde es vorziehen, wenn das Besondere gespeichert wird
explizit durch das Erweitern der Link-Einträge um zusätzliche Daten (zB eine
internal/external flag), sodass wir keine Zweideutigkeit zwischen einem @context haben
Datei und einen Link vom Typ @context . Aber wenn alle Datei-/Unterverzeichnis-Links verschlüsselt sind
mit Kind/', dann könnten Sie 'context' für den Typ haben
link und 'child/context' für die Datei (oder was auch immer). Es geht noch
eine extern definierte Konvention sein müssen, die Objektgeneratoren
und die Verbraucher müssen sich über einen nicht selbstbeschreibenden Kanal einigen.

aber ich bin mir nicht sicher, wie du aus dieser Kette ausbrechen kannst

Ich verstehe die Frage nicht. es gibt keine Kette, beschließt du
Kontext einmal und das war's. das ist die Kontextdatei für die
Objekt. wenn es kein gültiger Kontext ist – es gibt eine Spezifikation – Sie
ignoriere es.

Das ist für mich in Ordnung. Ich habe mich gefragt, wie Sie eine Selbstbeschreibung beenden
Kette:

Welcher Typ ist A? Folgen wir einfach A/ @context zu B. Welcher Typ ist B?
Folgen wir einfach B/ @context zu C…

Aber wenn Sie die B-Spezifikation (C in meinem Beispiel) verteilen, gibt es keine
Notwendigkeit für einen B/ @context- Link. Aber wenn Sie einen Kanal für haben
Verteilen der Typspezifikation (C), warum nicht auch verwenden, um die zu verteilen
Typ Schemas selbst (B)? Es scheint, als wäre es besser, nur eine zu haben
herkömmlicher Platz in Objekten, die einen Multihash enthalten, der ihre beschreibt
type (Ihr @context -Link oder was auch immer). Dann aus dem Weg gehen und
Überlassen Sie es den Erzeuger-/Verbrauchergemeinschaften, zu entscheiden, ob das eine ist
Verweis auf eine Typdefinition (vielleicht unter Spezifikation C oder Cv2 oder der
alternativ CCv1.3, oder …) oder wenn sie nur den Multihash als verwenden wollen
eine undurchsichtige Kennung. Dann können Sie immer noch Dinge tun wie:

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

es ist nur so, dass GetType den @context Link-Hash (bzw
wo auch immer), und TDirectory wäre ein Multihash
(QmWellKnownDirectoryType).

Anwendungen sollten nicht _abhängig_ davon sein, dass diese Typen korrekt sind, aber
nutzen Sie sie lieber, wenn sie es sind.

Das klingt nach einer undurchsichtigen Kennung. Vielleicht meinen wir dasselbe
Ding ;).

@tv42 hat seither auch Bedenken wegen Kollisionen mit Dateinamen geäußert
Verzeichnisknoten verwenden untergeordnete Segmentnamen als ihre Schlüssel.

Wenn eine dir-Datenstruktur bereits ein @context hat, wäre dies nicht zulässig
die Erstellung einer anderen Datei -- (oder im schlimmsten Fall den Link danach anhängen
(stabile Sorte)). Es ist dasselbe wie der Versuch, zwei Dateien mit dem zu erstellen
gleicher Name.

Es ist, wenn Sie @context- Dateien illegal machen wollen ;). Wenn du möchtest
Erlauben Sie Leuten, @context- Dateien zu erstellen, Sie brauchen eine Möglichkeit dazu
unterscheiden zwischen „dieser Link zeigt auf einen Typ“ und „dieser Link“.
zeigt auf eine Datei/Unterverzeichnis/…“. Aber es gibt eine Reihe von Möglichkeiten
um dieses Problem, also bin ich glücklich, solange wir einen von ihnen auswählen
;).

Ich hatte vor einigen Tagen ein Gespräch mit @cryptix und wir sprachen kurz über die Verwendung von JSON-LD. Ich möchte nur darauf hinweisen, dass die Spezifikation für json-ld die Verwendung eines "Links" zulässt, um die Zuordnungen von json zu json-ld zu beschreiben. Ich persönlich bevorzuge diesen Ansatz, weil er ermöglicht, dass die Metadaten mit json-ld kompatibel sind, ohne sie für die derzeit "hipste" RDF-Variante umzustrukturieren.

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

Am Freitag, den 1. Mai 2015 um 21:24:27 -07:00 schrieb W. Trevor King:

Link-Erweiterungen sollten gut funktionieren. Und Verknüpfungsschlüssel voranstellen
Namensraum sie ist auch nicht so schlimm. Füllen der Typinformationen
into Data funktioniert auch (so funktionieren jetzt Dateien und Verzeichnisse
[1,2,3,4,5]). Das Aufzählen von Typen ist kein nachhaltiger Ansatz, aber
Jeder dieser Orte würde als Ort zum Speichern eines Typ-Hashes funktionieren.

In einer verwandten Anmerkung (Verteilen von gehashten Typ-IDs zusammen mit der
payload), @tv42 hat mich gerade auf Ethos ETypes [1,2,3] aufmerksam gemacht. Damit
Ich denke, es wäre eine Art expliziter Slot für diese Dinge
großartig.

Ich habe ETypes nicht gesehen, danke fürs Auftauchen. werde in den nächsten Tagen lesen. Etwas Relevantes ist Kathleen Fishers PADS-Arbeit + verwandt. Die PADS-Projektseite scheint kürzlich geändert worden zu sein (wenn es nur einen inhaltsadressierten unveränderlichen Speicher des Webs gäbe ...). (Aber das Internetarchiv hat uns wieder gerettet \o/: http://web.archive.org/web/20130125041549/http://www.padsproj.org/ )

• PADS: Eine domänenspezifische Sprache zur Verarbeitung von Ad-hoc-Daten
• Das PADS-Projekt: ein Überblick
• PADS/T: Eine Sprache zum Beschreiben und Transformieren von Ad-Hoc-Daten
• PADS/ML: Eine funktionale Datenbeschreibungssprache
• LearnPADS: automatische Werkzeuggenerierung aus Ad-hoc-Daten
• weitere Artikel : http://web.archive.org/web/20120205185831/http://www.padsproj.org/doc.html#papers

Wie auch immer, PADS hat sehr viel die richtige Idee. aber bisher wurde keine breite Implementierung gesehen, die mir bekannt ist. Vielleicht gibt es etwas im Stil von JSON-LD, das das hier beheben kann.

Bei JSON-LD geht es nicht nur darum, einen @context -Link hinzuzufügen. Insbesondere muss jeder Linkname (Schlüssel in JSON) in eine dieser Kategorien fallen:

• @context : Kontextlink oder Inline-Knoten, der die Daten beschreibt
• @id : der URI des aktuellen Knotens
• scheme://full-uri : wird als Link erkannt, dessen Prädikat der URI ist
• prefix:name : wird als Link erkannt, dessen Prädikat die Verkettung des Präfix-URI (definiert im Kontext) und des Namens ist
• Name: wird nur als Link erkannt, wenn er im Kontext definiert ist

Insbesondere scheint JSON-LD keine willkürlichen Schlüssel/Wert-Zuordnungen zu unterstützen. Wenn der Schlüssel als URI interpretiert werden kann, wird er als Prädikat betrachtet, das diesen URI verwendet. Folgendes ist beispielsweise ungültig:

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

da http://xmlns.com/foaf/0.1/name sich immer auf einen FOAF-Namen bezieht und nicht auf die zwischengespeicherte Version einer Webseite.

Dies ist nicht unbedingt ein Problem, muss aber berücksichtigt werden, wenn wir uns entscheiden, beim Entwerfen von Objektformaten Links als verknüpfte Daten zu interpretieren. Beispielsweise könnte ein Verzeichnis mit JSON-LD so dargestellt werden:

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

In IPFS-LD hätten wir einen Knoten für das Verzeichnis, der mit einem Kontext und einem Knoten für jeden Eintrag verknüpft wäre. Jeder Eintrag hätte dann Links zu seinem eigenen Kontext, einen Knoten mit seinem Namen und einen Knoten mit dem Dateiinhalt.

Dadurch werden mehrere Indirektionsebenen hinzugefügt, die für JSON-Dokumente akzeptabel sind (weil alles in eine Datei gepackt ist), aber möglicherweise nicht für IPFS akzeptabel sind, wo jeder Knoten einen anderen Hash hat und separat verfolgt werden muss.

Vielleicht möchten wir JSON-LD nicht so verwenden, wie es ist, sondern unser eigenes Kontextformat definieren, das von JSON-LD inspiriert ist. Dies wäre besser, da unser Format kein JSON ist und sehr spezifisch ist: Wir möchten beliebige Tastenbelegungen (für Unixfs) beschreiben können und wir möchten auch den Datenabschnitt unserer IPFS-Objekte verwenden (JSON hat das nicht ).

Da der Link-Bereich von IPFS-Objekten sehr restriktiv ist, haben Links einen Namen und zeigen auf ein anderes Objekt. Es darf keine Literalwerte enthalten. Was wir im Kontext angeben müssen, ist der vollständig qualifizierte Name des Links in URI-Form. Da wir auch einen Datenabschnitt haben, müssen wir definieren, was er enthält.

Für unixfs würde ich mir folgende Objekte vorstellen:

• directory :
  
  
  
  • Link @context zeigt auf den Verzeichniskontext
  
  
  • Link entry:README.md , der auf das README.md-Objekt zeigt
  
  
  • keine Daten
  
  
• README.md :
  
  
  
  • Link @context zeigt auf Dateikontext
  
  
  • Datenabschnitt mit dem Inhalt von README.md
  
  
• Verzeichniskontext:

```
{
// @type : der Typ des IPFS-Objekts
"@type": " http://schema/unixfs#Verzeichnis "

// 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"
}

}
```

• Dateikontext:

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

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

}
```

Wenn wir dies in Tripeln darstellen wollten, hätten wir:

# 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 – großartige Analyse. Lustigerweise bin ich in einem Gespräch mit dlongley in irc://irc.frennode.org#json -ld zu den gleichen Schlussfolgerungen gekommen (kann Ihnen bei Interesse Protokolle senden)

Ich habe hier ein bisschen mit einer freizügigeren IPLD-Art experimentiert – siehe insbesondere die Beispiele. diese sind nicht endgültig (oder korrekt?), geben aber eine Richtung vor

• 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 (ignoriere die Verwendung von @value , es ist falsch)
• 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

Wichtige Notizen:

• entspannende Links, um die Einbeziehung anderer Werte zu _erlauben_ (viel verlangt), wir reservieren nur {"@type": "mlink", "hash": "<multihash>"}
• Benutzer können Kontexte für ihre Datenstrukturen definieren
• kann Links _verschachteln_, wobei die Pfadnotation verwendet wird, um z. B. https://github.com/ipfs/go-ipld/blob/master/ipld.go#L122 -L141 zu durchlaufen

Ich denke, Sie und ich sind auf dem richtigen Weg. Ich denke auch, dass wir wahrscheinlich viel davon tun können, ohne viel von JSON-LD abzuweichen. nur einige Beschränkungen fallen lassen

@mildred loggt sich hier ein

sollte auch sagen, dass – aus meinem Gespräch mit dlongley – es möglich sein sollte, das zu tun, was wir wollen, ohne technisch vom JSON-LD-Standard abzuweichen, nur dass das _Aufrufen der Transformationen (Komprimierung/Expansion)_ alle "non -kontextdefinierte" Schlüssel. (wir sollten uns bemühen, nicht abzuweichen)

Ich denke, Sie würden viel Verwirrung beseitigen, indem Sie an JSON-LD in Bezug auf generierte Tripel denken, anstatt an das, was der json-ld.js-Parser bei der Transformation von JSON tut. Der JSON-Transformationsschritt ist spezifisch für diesen Parser und Sie können sich problemlos vorstellen, ihn auf andere Weise zu transformieren.

Nun, wenn ich gut verstehe, was Sie mit go-ipld machen , könnte es den Link-Abschnitt in den aktuellen IPFS-Objekten ersetzen, richtig? Dieses Ding: merkledag.proto

Da sehe ich ein Problem. Wo wir zuvor eine einfache Struktur hatten, die eine effiziente Verarbeitung ermöglichte (Linkname, direkt verbunden mit Pfad und Link-Hash), haben wir jetzt eine etwas komplexere Struktur. Um zum verknüpften Hash zu gelangen, müssen Sie den String „mlink“ in einer Hash-Tabelle auflösen. Ist das wirklich notwendig?

Wenn Sie verknüpfte Daten / RDF wollen, warum definieren Sie nicht einfach Ihr eigenes Wire-Format (protobuf ist großartig, soweit es mich betrifft) und die Art und Weise, wie es in JSON übersetzt werden kann. Verwenden Sie dann darüber hinaus den JSON-LD-Kontext.

Nun zu den unterschiedlichen Datenstrukturen, an die Sie gedacht haben, ich finde sie großartig, mit Ausnahme der unixfs: Wir können keine Dateinamen als JSON-LD-Schlüssel haben, weil JSON-LD-Schlüssel unter allen Umständen auf RDF-Prädikate verweisen müssen. Ein Dateiname ist ein Literalwert.

Anstatt:

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

Ich würde dies modellieren als:

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

Auch hier muss die binäre/serialisierte Version nicht so sein. Die Art, diese letzte Notation als RDF-Trips darzustellen, wäre:

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"

Ich bin im IRC, zögern Sie nicht, mich dort anzupingen.

Für diejenigen, die mit RDF in diesem Thread nicht vertraut sind, hier eine kleine Erklärung:

RDF ist eine Möglichkeit, Ihre Daten zu strukturieren. es ist das Datenmodell hinter JSON-LD. In RDF müssen alle Daten dreifach kodiert werden:

<subject> <predicate> <object>

• Das Subjekt ist ein Knoten, der durch einen URI identifiziert wird
• Das Prädikat ist ein URI wie <http://www.w3.org/1999/02/22-rdf-syntax-ns#name> . Der URI definiert die Beziehung eindeutig und sollte vorzugsweise in einer Spezifikation oder einem Schema gut definiert sein.
• Das Objekt ist das Ziel des Links/Prädikats. Es kann ein Literalwert sein (eine Zeichenfolge, die optional eingegeben werden kann, z. B. als Ganzzahl oder Datum, im Allgemeinen vom xsd-Schema abgeleitet) oder es kann sich um einen anderen Knoten handeln, der durch seinen URI identifiziert wird

Die Dreifachnotation geht davon aus, dass jeder Subjekt- und Objektknoten einen URI hat, der ihn eindeutig identifiziert. Es definiert die vollständige Datenstruktur, indem es alle Tripel auflistet, die es enthält, eines pro Zeile.

JSON-Schlüssel in JSON-LD sind Prädikate, die das Subjekt (das Objekt, in dem der Schlüssel vorhanden ist) und das Objekt verknüpfen: den Wert des JSON-LD-Schlüssels. In diesem Fall werden URIs nicht verwendet, um auf Subjekt und Objekt zu verweisen. Wenn Sie den URI eines Objekts angeben möchten, mit dem darauf verwiesen werden kann, gibt es die Eigenschaft @id .

Gibt es irgendwo einen Artikel, der erklärt, wie Linked Data über IPFS im Vergleich zur Funktionsweise über HTTP funktioniert? (Wie sehen die URIs aus? Wie sollten die Best Practices für Herausgeber und Verbraucher von Linked Data over IPFS aussehen?)

Sehen:

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

IPLD gibt Ihnen das JSON-Datenmodell. Sie können jede JSON-LD auf IPLD legen.

(noch nicht gelandet)

@jbenet habe gerade diesen Thread durchgelesen, die Verwendung verknüpfter Daten ist meiner Meinung nach eine großartige Initiative

Sie haben Recht damit, dass Linked Data keine einzige Serialisierung vorschreibt. Es ist möglich, JSON-LD, RDF/XML, RDFa, Turtle oder eine Reihe anderer Formate zu verwenden

Was Linked Data erfordert, ist, dass die Schlüssel in JSON URIs sind. Dies könnte so einfach sein, wie ihnen urn:string:<key> voranzustellen, was bei Verwendung von JSON-LD als Einzeiler im Kontext erfolgen oder explizit ausgeschrieben werden könnte.

Ein anderer (allgemein bevorzugter) Weg wäre, die Begriffe für die Schlüssel in ein http(s)- oder ipfs:-Dokument zu schreiben, das menschenlesbare Beschreibungen für jeden Begriff enthält.

Interessant finde ich auch Metadaten für einen in Linked Data geschriebenen IPFS-Hash. Ich habe dies heute in Turtle schnell versucht und dabei das in RFC6920 beschriebene Muster wiederverwendet:

<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

Die Idee von verknüpften Daten ist, dass die Identifikatoren, die Sie Dingen geben, wenn Sie sie nachschlagen, ihnen nützliche Daten liefern, einschließlich Daten, die auf verwandte Dinge verlinken. Ein Verzeichnis gibt Ihnen also eine Liste der URIs der darin enthaltenen Dinge, ein Ereignis gibt Ihnen die Zeit und Daten und Links zu eingeladenen Personen, Personen geben Ihnen Links zu Gruppen und anderen Personen und so weiter. All dies über ipfs: anstelle von http: zu tun, funktioniert natürlich gut, und Sie könnten die beiden Leerzeichen verknüpfen. Sie können zum Beispiel behaupten, dass etwas in einem Raum dasselbe ist wie etwas in einem anderen. Sie könnten Ihre Freunde in http:space dokumentieren und Ihre Veröffentlichungen in ipfs:space oder was auch immer Sie möchten.

(Als rdfhead bevorzuge ich Turtle als Format, da ich es einfach und leistungsstark finde, aber Sie können sicher JSONLD verwenden.)

/me kann keine Verbindung zu static.benet.ai herstellen, um http://static.benet.ai/t/ipfs.pdf zu lesen

@timbl finden Sie eine aktuellere Version des IPFS-Papiers hier: https://github.com/ipfs/papers/blob/master/ipfs-cap2pfs/ipfs-p2p-file-system.pdf oder das dasselbe Papier über öffentliche IPFS-Gateways: https://ipfs.io/ipfs/QmV9tSDx9UiPeWExXEeH6aoDvmihvx6jD5eLb4jbTaKGps

Sie können zum Beispiel behaupten, dass etwas in einem Raum dasselbe ist wie etwas in einem anderen.

Jawohl! Das sind alle gleich:

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

Tut mir leid, das dweb: URI-Schema und https://dweb.link funktionieren noch nicht wirklich.

Im Moment ist es fs:/ipfs/somehash für URIs (im IPFS Gateway Redirect Addon) und https://ipfs.io/ipfs/somehash für HTTP:

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

Falls die Leute in diesem Thread es verpasst haben, ist es passiert!

https://ipld.io/

Lassen Sie uns die Unterhaltung auf https://github.com/ipld/ipld fortsetzen

Sicher. Zögern Sie nicht, vorbeizuschauen, um Aspekte von verknüpften Daten zu diskutieren unter:

https://gitter.im/linkeddata/chat

@nicola Ich bin mir sicher, dass dieser Kanal kein Unbekannter ist

Wir haben heute tatsächlich über das Hinzufügen von ipfs: URIs zu unserem System gesprochen. Viel Glück mit ipld!

Warum den wohldefinierten Begriff „Linked Data“ für etwas verwenden, das eindeutig nicht LD ist?
https://www.w3.org/standards/semanticweb/data

Also, ich weiß, das ist ein alter Thread, aber ich füge mich hinzu, um ihn für die Nachwelt zu mischen.

Ich habe das Verifiable Credentials-Datenmodell (https://w3c.github.io/vc-data-model/) bearbeitet und bin auf einige Probleme gestoßen, als ich die in JSON-LD und IPLD dargestellten @context abgeglichen habe. (siehe: https://github.com/w3c/vc-data-model/pull/261 ). Ich kann erkennen, dass JSON-LD vollständig kompatibel mit IPLD ist, aber IPLD ist nicht vollständig rückwärtskompatibel mit JSON-LD, was für die Interoperabilität mit bestehenden Spezifikationen erforderlich wäre. Aus meiner Sicht wäre die Lösung, ipld: als gültiges Schema in ietf hinzuzufügen (siehe: https://github.com/ipld/specs/issues/98 ) und dann { <attr> : ipld:<cid> } zuzulassen { "/" : <cid> } in IPLD leistet (siehe: https://github.com/ipld/specs/issues/99). Registrieren Sie außerdem/zusätzlich den MIME-Inhaltstyp von application/ipld , um den Typ zu deklarieren, der das Protokoll definiert. Dies würde sich zusammensetzen, um application/json+ipld gegenüber application/cbor+ipld zu ermöglichen, um Verwirrung zu vermeiden. ( @mildred Ich mag dafür ipfs:// nicht, da wir natürliches Linken brauchen und ` { "@context" : "/ipfs/" }' ist ein gültiger URI )

Was die semantische Interoperabilität betrifft, habe ich den JSON-LD-Kontext auf IPLD gelegt. Dies führt jedoch zu einem Rooting-Problem, das sich leicht durch Einbetten von URIs als gültige Werte in das JSON-LD lösen lässt.

Letztendlich sind es Schildkröten ganz unten :turtle: > :turtle: > :turtle: bis Sie ganz unten sind, wo Sie @timbl finden, weshalb ich denke, dass er Turtle als Format bevorzugt : smiley:.

(Als rdfhead bevorzuge ich Turtle als Format, da ich es einfach und leistungsstark finde, aber Sie können sicher JSONLD verwenden.)

Ein perfektes Beispiel dafür ist die Handhabung von datetime in @context for Verifiable Credentials unter https://w3id.org/did/v1 , das auf xsd:datetime verweist , das auf http://www.w3.org/ verweist. html ist.

Meine Lieblingsanmerkung in diesem XML ist:

Zuerst die eingebauten primitiven Datentypen. Diese Definitionen dienen nur zur Information, die echten eingebauten Definitionen sind magisch.

Ich kann mit dieser Magie arbeiten, solange wir akzeptieren, dass am Ende des Stapels von :turtle: > :turtle: > :turtle: wir uns einig sind, dass es @timbl ist, und dann können wir die Abwärtskompatibilität mit JSON-LD in Einklang bringen das obige mit ipld: .

@jonnycrunch Ich unterstütze deine Ideen. Turtle ist nicht das beliebteste, da JSON im Web ziemlich gut etabliert ist, zumal JSON in Browsern nativ ist und eine flache Lernkurve hat.

Es muss ein Gleichgewicht gefunden werden zwischen dem Ansprechen einer breiten Entwickler-Community und einem System, das interoperabel (nicht so schwarz-weiß) und reich an Funktionen ist.

Das @context -Problem verschwindet, wenn Sie die vollständige URL eingeben. Obwohl es sich um mehr Zeichen handelt, halte ich es für eine bessere, wenn nicht sogar bewährte Methode, da es einen Roundtrip vermeidet und Sie die Integrität der Remote-Datei nicht überprüfen müssen.

Letztendlich entsteht Verwirrung, da URIs sowohl Namen (uuids) als auch Lokatoren (Protokoll) sind und das Gehirn nicht einfach an beide gleichzeitig denkt. Wenn wir an den Punkt kommen, an dem wir URIs oder Abkürzungen für URIs in den Schlüsseln unseres JSON verwenden, verschwinden viele dieser Probleme. Tatsächlich sollten die Namen ipfs: und http: Teil eines kooperativen Netzwerks werden, mit verknüpften Daten als eine Art Klebstoff.

Ich habe meinen Kommentar aktualisiert, um die Syntax ipld:<cid> zu verwenden, da ich erkannt habe, dass sie nicht maßgeblich ist und daher den doppelten Schrägstrich $# ipld:// // nicht verdient. Da die Payload selbstbeschreibend ist, ist sie ihre eigene Autorität und sollte für sich allein stehen. Aber das ist ein Argument für die Experten.

@jonnycrunch schrieb:

Die Lösung wäre, ipld: als gültiges Schema in IETF hinzuzufügen

Ich unterstütze diesen Ansatz sehr und denke, dass er zu einer großartigen Interop-Story zwischen der (traditionelleren) Linked-Data-Community und der IPFS/IPLD-Community führen würde.