Ipfs: IPFS-LD - Data Tertaut

Hai @jbenet , kerja bagus dengan IPFS, sangat tertarik dengan apa yang Anda lakukan saat kami mencari untuk menggunakan DHT (seperti Kademlia) + tanda tangan digital + jaringan kueri untuk mengganti penamaan di Internet (akhirnya ganti DNS). Pekerjaan dasar yang kami lakukan hampir sama dengan apa yang Anda lakukan dengan IPFS: https://manu.sporny.org/2014/identity-credentials/ . Kami menggunakan JSON-LD untuk inisiatif itu, apakah Anda mengetahui Telehash? Jika tidak, Anda harus melihat beberapa dari konsep tersebut yang mungkin memperkuat IPFS.

Bagaimanapun, jika Anda ingin metadata di jaringan dapat dibaca mesin dan diproses tetapi dengan cara yang dapat diperluas, Anda harus menggunakan JSON-LD. Jika Anda menggunakan JSON-LD, ada kemungkinan besar Anda dapat mengintegrasikan pekerjaan Pembayaran dan Kredensial Web yang terjadi di W3C karena kedua rangkaian pekerjaan tersebut juga dibuat di atas JSON-LD. Salah satu manfaat utama JSON-LD adalah Anda dapat menggabungkan data dari sumber yang berbeda. Lain adalah bahwa Anda dapat menentukan format data dasar dan memungkinkan orang untuk memperluas protokol tanpa koordinasi dengan Anda (yang penting jika Anda ingin sistem tumbuh pada tingkat eksponensial).

Hanya beberapa pemikiran, jika Anda memiliki pertanyaan, silakan bertanya. Membutuhkan @context di setiap gumpalan JSON di jaringan bukanlah persyaratan yang berat.

terima kasih atas pemikirannya!

kami sedang mencari cara untuk menggunakan DHT (seperti Kademlia) + tanda tangan digital + jaringan kueri untuk mengganti penamaan di Internet (akhirnya mengganti DNS).

Kemudian pastikan untuk melihat bagian IPNS di koran: http://static.benet.ai/t/ipfs.pdf (3.7). :)

apakah Anda mengetahui Telehash?

Ya, saya sangat menyetujui konsep umum + dorongan untuk membangunnya, tetapi saya tidak mendukung banyak keputusan proyek. Contoh kasus, taglinenya adalah "JSON + UDP + DHT = Freedom" tetapi saya pikir sistem semacam ini seharusnya (a) tidak memaksa format data, (b) tidak memaksa protokol transport, dan (c) tidak memaksa a sistem perutean. Tentu saja, ketiganya adalah pilihan yang bagus _today_, tetapi protokol ini harus dibuat agar sesuai dengan lapisan dan waktu. Dengan demikian IPFS memungkinkan pengguna untuk menggunakan format apa pun yang mereka inginkan, IPFS dapat melapisi semua transport, dan meskipun sistem Perutean pertama akan menjadi DHT, ada yang lain untuk dijelajahi.

Anda dapat melihat IPFS sebagai Telehash + (merkle) Web.

jika Anda ingin metadata di jaringan dapat dibaca dan diproses oleh mesin tetapi dengan cara yang dapat diperluas, Anda harus menggunakan JSON-LD.

Saya pikir kami dapat mengambil bagian -LD dari pekerjaan Anda tanpa memerlukan JSON sebagai transportasi. Yaitu saya pikir pekerjaan Anda (luar biasa) dapat digeneralisasikan ke struktur data pohon apa pun, dan jauh lebih baik daripada format web semantik lainnya. (kesederhanaan + fleksibilitas yang luar biasa!) Jadi yang saya maksudkan dalam catatan ini adalah menggunakan yang setara dengan @context tetapi dalam struktur data tautan IPFS (yang bukan JSON, ini adalah format paket biner untuk pencarian cepat melalui objek -- protobuf hari ini, tetapi mungkin juga akan menjelaskan sendiri nanti -- Saya bermaksud agar IPFS cukup cepat untuk bekerja sebagai database. tidak hari ini, tetapi di masa depan :) ).

Memerlukan @context di setiap gumpalan JSON di jaringan bukanlah persyaratan yang berat.

Yap, saya juga berpendapat sama :)

@jbenet re: https://github.com/dataprotocols/dataprotocols/issues/110#issuecomment -43430309 - ya, saya pikir argumen Anda di sana sangat bagus dan terinformasi dengan baik.

Saya sangat tertarik dengan apa yang Anda lakukan, saya membaca sekilas kertas dan mulai menonton video Anda. Sayangnya, saya memiliki tenggat waktu yang harus saya lewati hari ini, tetapi telah membaca makalah Anda dan menonton seluruh video di daftar tugas saya. Saya tidak tahu apakah Anda mengetahui hal ini, tetapi saya bekerja untuk membangun standar untuk Web melalui W3C. Kami memiliki serangkaian masalah saat ini yang membutuhkan solusi yang serupa dengan yang Anda uraikan. Saya ingin melihat apakah kami dapat mengintegrasikan beberapa pekerjaan Anda ke dalam solusi login standar W3C generasi berikutnya yang sedang kami kerjakan untuk Web (postingan yang saya singgung di atas). Kami saat ini menggunakan Telehash, tetapi memiliki beberapa kekhawatiran dengan itu dan Anda tampaknya telah menguraikan masalah dengan cara yang mungkin lebih sesuai dengan kasus penggunaan kami.

Bagaimanapun, biarkan saya masuk ke apa yang telah Anda buat dan kemudian kembali kepada Anda. Jika Anda tidak mendengar kabar dari saya dalam seminggu, silakan ping saya lagi.

Hai @jbenet , Saya berkesempatan untuk melihat whitepaper lebih detail selama akhir pekan serta menonton presentasi Anda. Mari kita siapkan waktu untuk berbicara minggu depan ini. Saya di pantai timur, AS. Tersedia 10:00-14:00 hampir setiap hari kecuali Sel/Rabu. Email saya: [email protected] , Skype: msporny , SIP: sip:[email protected] Hubungi saya sesegera mungkin.

Saya ingin membahas ipns dan wrt ini. login di Web, Kredensial, dan Pembayaran Web: https://manu.sporny.org/2014/identity-credentials/

@msporny bagus! akan melakukan. Mengirim email sekarang untuk menyentuh basis. Anda mungkin ingin menghapus detail kontak Anda dari masalah ini (karena bersifat publik, dll).

Kami sedang memikirkan bagaimana menjawab pertanyaan "objek macam apa ini" di IRC hari ini. @jbenet menyebutkan tautan gaya LSON-LD @type atau @context , tapi saya tidak yakin bagaimana Anda keluar dari rantai itu . Apakah tautan @context benar-benar turun? @tv42 juga mengangkat kekhawatiran tentang tabrakan dengan nama file , karena node direktori menggunakan nama segmen anak sebagai kuncinya. Anda dapat mengatasinya dengan mengawali atau menghilangkan nama segmen, tetapi itu sepertinya lebih berhasil daripada hanya menambahkan bidang Jenis eksplisit untuk menyimpan ID hash untuk deskripsi jenis . Jika kita mengharapkan lebih dari hal semacam ini, mungkin itu hanya panggilan untuk mempartisi Tautan ke dalam set internal dan eksternal. Anda dapat melakukannya dengan pendekatan ekstensi protobuf Tautan yang diusulkan @jbenet (jika itu menjadi sesuatu) dengan menambahkan boolean 'internal' untuk memisahkan entri tipe @context #$3$#$ dari entri file @context ( Misalnya).

maaf, formatnya (hampir pasti) tidak berubah saat ini. saya menghabiskan waktu berbulan-bulan untuk merebusnya hingga menjadi ini dan tidak akan membuka pintu air untuk itu lagi. pertanyaan yang tersisa (seperti ekstensi tautan) telah diketahui selama beberapa waktu dan hanya menemukan cara yang tepat untuk melakukannya.

objek ipfs adalah pohon seperti json atau apa pun. ini berarti bahwa semua solusi yang tersedia untuk JSON (termasuk JSON-LD, JSON-schema, dan seterusnya) tersedia untuk IPFS. apalagi, adalah sepele untuk mewakili tiga kali lipat RDF sebagai objek ipfs. karenanya, Anda dapat melakukan apa saja dan segalanya.

data nyata sangat berantakan. tidak ada seorang pun di dunia ini yang berhasil memaksa orang untuk mengadopsi sistem pengetikan data tertentu-- dan saya tidak akan membuang waktu ke dalam argumen itu. Satu-satunya solusi yang menurut saya layak dalam jangka panjang adalah membuat sistem yang cukup fleksibel bagi orang untuk melakukan apa pun yang mereka inginkan, dan cukup kaku sehingga semuanya saling terkait.

sekarang, cara _preferred_ -- cara kami menyarankan orang melakukan sesuatu -- kemungkinan adalah @context / @type dari JSON-LD (luar biasa kuat dan sederhana).

tapi saya tidak yakin bagaimana Anda keluar dari rantai itu

saya tidak mengerti pertanyaannya. tidak ada rantai, Anda menyelesaikan konteks sekali dan hanya itu. itu file konteks untuk objek. jika itu bukan konteks yang valid -- ada spesifikasi -- Anda mengabaikannya. aplikasi seharusnya tidak _tergantung_ pada jenis ini yang benar, melainkan memanfaatkannya ketika mereka benar.

@tv42 juga mengangkat kekhawatiran tentang tabrakan dengan nama file, karena node direktori menggunakan nama segmen anak sebagai kuncinya.

jika struktur data dir sudah memiliki @context itu tidak akan mengizinkan pembuatan file lain-- (atau paling buruk, tambahkan tautan setelahnya (sort stabil)). itu sama dengan mencoba membuat dua file dengan nama yang sama.

Pada Jumat, 01 Mei 2015 pukul 03:51:22AM -0700, Juan Batiz-Benet menulis:

maaf, formatnya (kemungkinan besar) tidak berubah saat ini. saya
menghabiskan waktu berbulan-bulan untuk merebusnya hingga menjadi seperti ini dan tidak akan membuka banjir
gerbang itu lagi. pertanyaan yang tersisa (seperti ekstensi tautan)
telah dikenal selama beberapa waktu dan baru saja menemukan cara yang tepat untuk melakukannya
dia.

Ekstensi tautan akan berfungsi dengan baik. Dan awalan kunci tautan ke
namespace mereka juga tidak terlalu buruk. Mengisi informasi jenis
ke Data juga berfungsi (begitulah cara kerja file dan direktori sekarang
[1,2,3,4,5]). Pencacahan jenis bukanlah pendekatan yang berkelanjutan, tetapi
salah satu tempat ini akan berfungsi sebagai tempat untuk menyimpan hash tipe.

sekarang, cara _pilihan_ -- cara yang kami sarankan agar orang melakukan sesuatu
-- kemungkinan akan menjadi @context / @type dari
(luar biasa kuat dan sederhana) JSON-LD.

JSON-LD baik-baik saja, tetapi ekosistem di sekitarnya perlu dipahami
bahwa @-prefix itu spesial. Saya lebih suka kekhususan itu disimpan
secara eksplisit dengan memperluas entri Tautan dengan data tambahan (mis
bendera internal/eksternal) jadi kami tidak memiliki ambiguitas antara @konteks
file dan tautan tipe @context . Tetapi jika semua tautan file/subdir dikunci
bersama anak/', maka Anda dapat memiliki 'konteks' untuk jenisnya
tautan dan 'anak/konteks' untuk file (atau apa pun). Ini masih berjalan
harus menjadi konvensi yang ditentukan secara eksternal bahwa generator objek
dan konsumen perlu menyepakatinya melalui saluran yang tidak menggambarkan diri sendiri.

tapi saya tidak yakin bagaimana Anda keluar dari rantai itu

saya tidak mengerti pertanyaannya. tidak ada rantai, Anda memutuskan
konteks sekali dan hanya itu. itu file konteks untuk
obyek. jika itu bukan konteks yang valid -- ada spesifikasi -- Anda
Abaikan saja.

Itu bekerja untuk saya. Saya bertanya-tanya bagaimana Anda mengakhiri penggambaran diri sendiri
rantai:

Apa tipe A? Mari kita ikuti A/ @context ke B. Apa tipe B itu?
Yuk ikuti saja B/ @context ke C…

Tetapi jika Anda mendistribusikan spesifikasi B (C dalam contoh saya), tidak ada
membutuhkan tautan B/ @context . Tetapi jika Anda memiliki saluran untuk
mendistribusikan tipe spec (C), mengapa tidak menggunakannya juga untuk mendistribusikan
ketik skema sendiri (B)? Sepertinya lebih baik memiliki
tempat konvensional di objek yang menyimpan multihash yang menggambarkan mereka
ketik (tautan @context Anda, atau apa pun). Kemudian menyingkir dan
serahkan pada komunitas produsen/konsumen untuk memutuskan apakah itu a
referensi ke definisi tipe (mungkin di bawah spesifikasi C, atau Cv2, atau
CCv1.3 alternatif, atau ...) atau jika mereka hanya ingin menggunakan multihash sebagai
pengenal buram. Kemudian Anda masih dapat melakukan hal-hal seperti:

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

hanya saja GetType akan mengambil hash @context Link (atau
dimanapun), dan TDirectory akan menjadi multihash
(QmWellKnownDirectoryType).

aplikasi seharusnya tidak _tergantung_ pada jenis ini yang benar, tetapi
lebih baik memanfaatkan mereka ketika mereka.

Ini terdengar seperti pengenal buram. Mungkin kita mengatakan hal yang sama
hal ;).

@tv42 juga mengangkat kekhawatiran tentang tabrakan dengan nama file, karena
node direktori menggunakan nama segmen anak sebagai kunci mereka.

jika struktur data dir sudah memiliki @context itu tidak akan mengizinkan
pembuatan file lain-- (atau paling buruk, tambahkan tautan setelah
(urutan stabil)). itu sama dengan mencoba membuat dua file dengan
nama yang sama.

Itu jika Anda ingin membuat file @context ilegal ;). Jika Anda menghendaki
izinkan orang untuk membuat file @context , Anda memerlukan beberapa cara untuk
membedakan antara "tautan ini menunjuk pada suatu jenis" dan "tautan ini"
menunjuk pada file/subdirektori/…”. Tapi ada beberapa cara
sekitar masalah itu, jadi selama kita memilih salah satunya, aku akan senang
;).

Saya melakukan percakapan dengan @cryptix beberapa hari yang lalu dan kami berbicara secara singkat tentang penggunaan JSON-LD. Saya hanya ingin menunjukkan bahwa spesifikasi untuk json-ld memungkinkan penggunaan "tautan" untuk menggambarkan pemetaan dari json ke json-ld. Saya pribadi lebih suka pendekatan ini karena memungkinkan metadata untuk mematuhi json-ld tanpa merestrukturisasinya untuk rasa apa pun dari RDF saat ini "hip".

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

Pada Jumat, 01 Mei 2015 pukul 09:24:27 PM -0700, W. Trevor King menulis:

Ekstensi tautan akan berfungsi dengan baik. Dan awalan kunci tautan ke
namespace mereka juga tidak terlalu buruk. Mengisi informasi jenis
ke Data juga berfungsi (begitulah cara kerja file dan direktori sekarang
[1,2,3,4,5]). Pencacahan jenis bukanlah pendekatan yang berkelanjutan, tetapi
salah satu tempat ini akan berfungsi sebagai tempat untuk menyimpan hash tipe.

Pada catatan terkait (mendistribusikan ID tipe hash bersama dengan
payload), @tv42 baru saja menarik perhatian saya ke Ethos ETypes [1,2,3]. Jadi
Saya pikir memiliki semacam slot eksplisit untuk hal-hal ini adalah
Bagus.

Belum melihat ETypes, terima kasih telah muncul. akan membaca selama beberapa hari ke depan. Sesuatu yang relevan adalah pekerjaan + terkait PADS Kathleen Fisher. Halaman proyek PADS tampaknya telah diubah baru-baru ini (jika saja ada beberapa toko web yang tidak dapat diubah dengan alamat konten...). (Tapi arsip internet menyelamatkan kita lagi \o/: http://web.archive.org/web/20130125041549/http://www.padsproj.org/ )

• PADS: Bahasa khusus domain untuk memproses data ad hoc
• Proyek PADS: gambaran umum
• PADS/T: Bahasa untuk Menggambarkan dan Mengubah Data Ad Hoc
• PADS/ML: Bahasa Deskripsi Data Fungsional
• LearnPADS: pembuatan alat otomatis dari data ad-hoc
• makalah lainnya: http://web.archive.org/web/20120205185831/http://www.padsproj.org/doc.html#papers

Bagaimanapun, PADS memiliki ide yang sangat tepat. tetapi sejauh ini belum melihat implementasi yang luas, yang saya sadari. mungkin ada sesuatu dalam gaya JSON-LD yang dapat memperbaikinya di sini.

JSON-LD bukan hanya tentang menambahkan tautan @context . Secara khusus, setiap nama tautan (kunci dalam JSON) harus termasuk dalam salah satu kategori berikut:

• @context : tautan konteks atau simpul sebaris yang menjelaskan data
• @id : URI dari node saat ini
• skema://full-uri : dikenali sebagai tautan yang berpredikat URI
• prefix:name : dikenali sebagai tautan yang predikatnya merupakan gabungan dari awalan URI (didefinisikan dalam konteks) dan nama
• name: dikenali sebagai tautan hanya jika didefinisikan dalam konteks

Secara khusus, JSON-LD tampaknya tidak mendukung peta kunci/nilai arbitrer. Jika kunci dapat ditafsirkan sebagai URI, itu akan dianggap sebagai predikat menggunakan URI ini. Misalnya, berikut ini tidak valid:

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

karena http://xmlns.com/foaf/0.1/name akan selalu merujuk ke nama FOAF, dan bukan versi cache dari halaman web.

Ini tidak selalu menjadi masalah tetapi harus dipertimbangkan jika kita memutuskan untuk menafsirkan tautan sebagai data yang ditautkan saat mendesain format objek. Misalnya, direktori dapat direpresentasikan dengan cara ini menggunakan 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>"
    }
  ]
}

Dalam IPFS-LD kita akan memiliki simpul untuk direktori, yang menghubungkan ke konteks dan ke simpul untuk setiap entri. Setiap entri kemudian akan memiliki tautan ke konteksnya sendiri, sebuah simpul yang berisi nama mereka dan sebuah simpul dengan konten file.

Ini menambahkan beberapa tingkat tipuan, yang dapat diterima untuk dokumen JSON (karena semuanya dikemas dalam satu file) tetapi mungkin tidak dapat diterima untuk IPFS di mana setiap node memiliki hash yang berbeda dan harus dilacak secara terpisah.

Mungkin, yang kita inginkan bukanlah menggunakan JSON-LD sebagaimana adanya, tetapi mendefinisikan format konteks kita sendiri yang terinspirasi dari JSON-LD. Ini akan lebih baik karena format kami bukan JSON, dan sangat spesifik: Kami ingin dapat mendeskripsikan peta kunci arbitrer (untuk unixfs) dan kami juga ingin menggunakan bagian data objek IPFS kami (JSON tidak memilikinya ).

Karena bagian tautan objek IPFS sangat terbatas, tautan memiliki nama dan menunjuk ke objek lain. Itu tidak bisa mengandung nilai literal. Yang perlu kami tentukan dalam konteks adalah nama tautan yang sepenuhnya memenuhi syarat dalam formulir URI. Karena kita juga memiliki bagian data, kita perlu mendefinisikan apa isinya.

Untuk unixfs, saya akan membayangkan objek berikut:

• directory :
  
  
  
  • tautan @context menunjuk ke direktori-konteks
  
  
  • tautan entry:README.md menunjuk ke objek README.md
  
  
  • tidak ada data
  
  
• README.md :
  
  
  
  • link @context menunjuk ke file-context
  
  
  • bagian data dengan konten README.md
  
  
• direktori-konteks:

```
{
// @type : tipe objek 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"
}

}
```

• konteks file:

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

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

}
```

Jika kami ingin mewakili ini dalam tiga kali lipat, kami akan memiliki:

# 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

Hai @mildred -- analisis yang bagus. Lucunya saya mencapai kesimpulan yang sama dalam percakapan dengan dlongley di irc://irc.frennode.org#json -ld (dapat mengirimi Anda log jika tertarik)

Saya telah bereksperimen sedikit dengan jenis IPLD yang lebih permisif di sini -- khususnya lihat contohnya. ini tidak final (atau benar?), tetapi memberikan arah

• 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 (abaikan penggunaan @value , itu salah)
• 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

Catatan penting:

• tautan santai ke _allow_ penyertaan nilai lain (banyak diminta), kami hanya memesan {"@type": "mlink", "hash": "<multihash>"}
• pengguna dapat menentukan konteks untuk struktur data mereka
• dapat _nest_ tautan, menggunakan notasi jalur untuk dilalui misalnya https://github.com/ipfs/go-ipld/blob/master/ipld.go#L122 -L141

Saya pikir Anda dan saya berada di jalur yang benar. Saya juga berpikir bahwa kita mungkin dapat melakukan banyak hal ini tanpa banyak menyimpang dari JSON-LD. hanya menjatuhkan beberapa batasan

@mildred log di sini

juga harus mengatakan bahwa -- dari percakapan saya dengan dlongley -- seharusnya dimungkinkan untuk melakukan apa yang kita inginkan tanpa secara teknis menyimpang dari standar JSON-LD, hanya saja _memanggil transformasi (pemadatan/ekspansi)_ akan menghapus semua "non -ditentukan konteks" kunci. (kita harus berusaha untuk tidak menyimpang)

Saya pikir Anda akan menghilangkan banyak kebingungan dengan memikirkan JSON-LD dalam hal tiga kali lipat yang dihasilkan, daripada apa yang dilakukan parser json-ld.js dalam mengubah JSON. Langkah transformasi JSON khusus untuk parser itu dan Anda dapat membayangkan dengan mudah mengubahnya dengan cara lain tanpa masalah.

Sekarang, jika saya mengerti dengan baik apa yang Anda lakukan dengan go-ipld , itu dapat menggantikan bagian Tautan di objek IPFS saat ini, bukan? Hal ini: merkledag.proto

Saya melihat ada masalah di sana. Di mana sebelumnya kami memiliki struktur sederhana yang memungkinkan pemrosesan yang efisien (nama tautan, terkait langsung dengan jalur, dan hash tautan), kami sekarang memiliki struktur yang sedikit lebih kompleks. Untuk mendapatkan hash yang ditautkan, Anda harus menyelesaikan string "mlink" di tabel hash. apakah itu benar-benar perlu?

Jika Anda ingin data tertaut/RDF, mengapa tidak menentukan format kabel Anda sendiri (protobuf sangat bagus sejauh yang saya ketahui) dan cara menerjemahkannya ke JSON. Kemudian gunakan konteks JSON-LD di atas itu.

Sekarang, tentang struktur data berbeda yang Anda pikirkan, saya pikir mereka hebat, dengan pengecualian unixfs: kami tidak dapat memiliki nama file sebagai kunci JSON-LD karena kunci JSON-LD harus dalam semua keadaan mengacu pada predikat RDF. Nama file adalah nilai literal.

Dari pada:

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

Saya akan memodelkan ini sebagai:

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

Sekali lagi, versi biner/serial tidak perlu seperti ini. Cara merepresentasikan notasi terakhir ini sebagai tripes RDF adalah:

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"

Saya di IRC, jangan ragu untuk ping saya di sana.

Bagi yang belum familiar dengan RDF di thread ini, berikut sedikit penjelasannya:

RDF adalah cara untuk menyusun data Anda. ini adalah model data di balik JSON-LD. Di RDF, semua data harus dikodekan dalam rangkap tiga:

<subject> <predicate> <object>

• Subjek adalah simpul yang diidentifikasi oleh URI
• Predikatnya adalah URI seperti <http://www.w3.org/1999/02/22-rdf-syntax-ns#name> . URI secara unik mendefinisikan hubungan, dan sebaiknya didefinisikan dengan baik dalam spesifikasi atau skema.
• Objek adalah target dari tautan/predikat. Ini dapat berupa nilai literal (string, yang dapat diketik secara opsional, misalnya sebagai bilangan bulat atau tanggal, umumnya berasal dari skema xsd) atau dapat berupa simpul lain, yang diidentifikasi oleh URI-nya

Notasi rangkap tiga mengandaikan bahwa setiap node subjek dan objek memiliki URI yang mengidentifikasinya secara unik. Ini mendefinisikan struktur data lengkap dengan mendaftar semua tiga kali lipat yang dikandungnya satu per baris.

Kunci JSON di JSON-LD adalah predikat yang menghubungkan subjek (objek tempat kunci ada) dan objek: nilai kunci JSON-LD. Dalam hal ini, URI tidak digunakan untuk merujuk ke subjek dan objek. Jika Anda ingin menentukan URI objek yang dapat digunakan untuk merujuknya, ada properti @id .

Apakah ada tulisan di mana saja yang menjelaskan cara kerja Data Tertaut melalui IPFS dibandingkan dengan cara kerjanya melalui HTTP? (Seperti apa URI itu? Bagaimana seharusnya praktik terbaik untuk penerbit dan konsumen Data Tertaut melalui IPFS?)

Melihat:

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

IPLD memberi Anda model data json. Anda dapat melapisi JSON-LD apa pun di atas IPLD.

(belum mendarat)

@jbenet baru saja membaca utas ini, menggunakan data tertaut adalah inisiatif yang bagus IMHO

Anda benar bahwa Data Tertaut tidak mengamanatkan satu serialisasi apa pun. Dimungkinkan untuk menggunakan JSON-LD, RDF/XML, RDFa, Turtle atau banyak format lainnya

Yang dibutuhkan Data Tertaut adalah bahwa kunci dalam JSON adalah URI. Ini bisa sesederhana awalan mereka dengan urn:string:<key> yang, jika menggunakan JSON-LD dapat dilakukan sebagai satu liner dalam konteks, atau ditulis secara eksplisit.

Cara lain (umumnya lebih disukai) adalah dengan menempatkan istilah-istilah tersebut untuk kunci-kunci dalam http(s) atau ipfs: dokumen yang berisi deskripsi yang dapat dibaca manusia untuk setiap istilah.

Saya pikir juga menarik adalah meta data untuk hash IPFS yang ditulis dalam Data Tertaut. Saya melakukan upaya cepat hari ini di Turtle, menggunakan kembali pola yang diuraikan dalam 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

Ide dari data tertaut adalah bahwa pengidentifikasi yang Anda berikan pada sesuatu, jika Anda mencarinya, memberi mereka data yang berguna, termasuk data yang tertaut ke hal-hal terkait. Jadi direktori memberi Anda daftar URI hal-hal yang dikandungnya, Acara memberi Anda waktu dan data serta tautan ke orang yang diundang, orang memberi Anda tautan ke grup dan orang lain, dan seterusnya. Melakukan semua ini melalui ipfs: alih-alih http: tentu saja berfungsi dengan baik, dan Anda dapat menautkan dua spasi. Misalnya, Anda dapat menyatakan bahwa sesuatu di satu ruang sama dengan sesuatu di ruang lain. Anda dapat mendokumentasikan teman Anda di http: space dan publikasi Anda didokumentasikan dalam ipfs: space atau apa pun yang Anda suka.

(Sebagai rdfhead, saya lebih suka Turtle sebagai format karena menurut saya sederhana dan kuat tetapi Anda pasti dapat menggunakan JSONLD)

/me tidak dapat terhubung ke static.benet.ai untuk membaca http://static.benet.ai/t/ipfs.pdf

@timbl Anda dapat menemukan versi terbaru dari makalah IPFS di sini: https://github.com/ipfs/papers/blob/master/ipfs-cap2pfs/ipfs-p2p-file-system.pdf atau kertas yang sama melalui gateway IPFS publik: https://ipfs.io/ipfs/QmV9tSDx9UiPeWExXEeH6aoDvmihvx6jD5eLb4jbTaKGps

Misalnya, Anda dapat menyatakan bahwa sesuatu di satu ruang sama dengan sesuatu di ruang lain.

Ya! Ini semua sama:

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

Maaf tentang itu, skema dweb: URI dan https://dweb.link sebenarnya belum berfungsi.

Untuk saat ini fs:/ipfs/somehash untuk URI (di addon IPFS Gateway Redirect) dan https://ipfs.io/ipfs/somehash untuk HTTP:

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

Jika orang-orang di utas ini melewatkannya, itu terjadi!

https://ipld.io/

mari lanjutkan obrolan di https://github.com/ipld/ipld

Tentu. Jangan ragu untuk mampir untuk membahas aspek-aspek data tertaut di:

https://gitter.im/linkeddata/chat

@nicola Saya yakin tidak asing dengan saluran itu

Kami sebenarnya mendiskusikan menambahkan ipfs: URI ke sistem kami hari ini. Semoga sukses dengan ipld!

Mengapa menggunakan istilah yang didefinisikan dengan baik "Data Tertaut" untuk sesuatu yang jelas-jelas bukan LD?
https://www.w3.org/standards/semanticweb/data

jadi, saya tahu ini adalah utas lama tetapi saya menambahkan diri saya sendiri untuk digabungkan untuk anak cucu.

Saya telah mengerjakan model data Kredensial yang Dapat Diverifikasi ( https://w3c.github.io/vc-data-model/ ) dan menemukan beberapa masalah dalam merekonsiliasi @context yang diwakili dalam JSON-LD vs IPLD. (lihat: https://github.com/w3c/vc-data-model/pull/261 ). Saya dapat mengenali bahwa JSON-LD sepenuhnya kompatibel dengan IPLD, tetapi IPLD tidak sepenuhnya kompatibel dengan JSON-LD, yang akan diperlukan untuk interoperabilitas dengan spesifikasi yang ada. Seperti yang saya lihat, solusinya adalah menambahkan ipld: sebagai skema yang valid di ietf (lihat: https://github.com/ipld/specs/issues/98 ) lalu izinkan { <attr> : ipld:<cid> } sama dengan apa yang dicapai { "/" : <cid> } di IPLD (lihat: https://github.com/ipld/specs/issues/99). Juga/tambahkan daftarkan MIME Content-type dari application/ipld untuk mendeklarasikan tipe yang mendefinisikan protokol. Ini akan bertambah untuk memungkinkan application/json+ipld vs application/cbor+ipld untuk mengurangi kebingungan. ( @mildred Saya tidak suka ipfs:// untuk ini karena kami membutuhkan tautan alami dan ` { "@context" : "/ipfs/" }' adalah URI yang valid )

Adapun interoperabilitas semantik, saya telah melapiskan konteks JSON-LD di atas IPLD. Namun, ini menimbulkan masalah rooting, mudah diselesaikan dengan menyematkan URI sebagai nilai yang valid di JSON-LD.

Pada akhirnya, itu adalah Turtles sepenuhnya :turtle: > :turtle: > :turtle: sampai Anda mencapai dasar di mana Anda menemukan @timbl , itulah sebabnya saya pikir dia lebih memilih Turtle sebagai format : smiley:.

(Sebagai rdfhead, saya lebih suka Turtle sebagai format karena menurut saya sederhana dan kuat tetapi Anda pasti dapat menggunakan JSONLD)

Contoh sempurna dari ini adalah penanganan datetime di @context untuk Kredensial yang Dapat Diverifikasi di https://w3id.org/did/v1 yang menautkan ke xsd:datetime yang merujuk ke http://www.w3.org/ 2001/XMLSchema# , di mana penjelasan sebagai sumber dokumentasi ada di html .

Anotasi favorit saya dalam xml ini adalah:

Pertama, tipe data primitif bawaan. Definisi ini hanya untuk informasi, definisi bawaan yang sebenarnya adalah ajaib.

Saya dapat bekerja dengan sihir ini, selama kami menerimanya di bagian bawah tumpukan :turtle: > :turtle: > :turtle: kami setuju itu adalah @timbl dan kemudian kami dapat merekonsiliasi kompatibilitas mundur dengan JSON-LD menggunakan di atas dengan ipld: .

@jonnycrunch Saya mendukung ide Anda. Turtle bukanlah yang paling populer, karena JSON cukup mapan di web, terutama karena JSON asli untuk browser, dan memiliki kurva belajar yang dangkal.

Ada keseimbangan yang bisa didapat antara menarik komunitas pengembang yang luas dan memiliki sistem yang dapat dioperasikan (bukan sesuatu yang hitam dan putih) dan kaya fitur.

Masalah @context hilang jika Anda mengetik url lengkap. Meskipun lebih banyak karakter, saya menatap untuk berpikir itu lebih baik, jika bukan praktik terbaik, mengingat itu menghindari perjalanan pulang pergi dan Anda tidak perlu memverifikasi integritas file jarak jauh.

Pada akhirnya kebingungan muncul karena URI adalah nama (uuids) dan pencari (protokol) dan otak tidak mudah memikirkan keduanya sekaligus. Jika kita bisa sampai pada titik di mana kita menggunakan URI atau singkatan untuk URI di kunci JSON kita, banyak dari masalah ini akan hilang. Memang seperti penamaan ipfs: dan http: harus menjadi bagian dari jaringan kerjasama, dengan data terkait sebagai semacam perekat.

saya memperbarui komentar saya untuk menggunakan sintaks ipld:<cid> menyadari itu tidak otoritatif dan karenanya tidak layak untuk ipld:// double slash // . Karena muatannya menggambarkan dirinya sendiri, itu adalah otoritasnya sendiri dan harus berdiri sendiri. Tapi itu adalah argumen bagi para ahli.

@jonnycrunch menulis:

solusinya adalah menambahkan ipld: sebagai skema yang valid di IETF

Saya sangat mendukung pendekatan ini dan berpikir itu akan mengarah pada cerita interop yang hebat antara komunitas Data Tertaut (yang lebih tradisional) dan komunitas IPFS/IPLD.