Ipfs: IPFS-LD - 연결된 데이터

@jbenet님 , IPFS를 사용하여 수고하셨습니다. DHT(Kademlia 유사) + 디지털 서명 + 쿼리 네트워크를 사용하여 인터넷에서 이름 지정을 대체(결국 DNS 대체)하는 방법을 조사하고 있으므로 귀하가 하고 있는 일에 매우 관심이 많습니다. 우리가 하고 있는 기본 작업은 IPFS( https://manu.sporny.org/2014/identity-credentials/ )를 사용하여 수행 중인 작업에 가깝습니다. 우리는 그 이니셔티브에 JSON-LD를 사용하고 있습니다. Telehash를 알고 있습니까? 그렇지 않은 경우 이러한 개념 중 일부가 IPFS를 강화할 수 있는지 살펴봐야 합니다.

어떤 경우든 네트워크의 메타데이터를 기계가 읽을 수 있고 처리할 수 있지만 확장 가능한 방식으로 만들고 싶다면 JSON-LD를 사용해야 합니다. JSON-LD를 사용하는 경우 W3C에서 발생하는 Web Payments 및 Credentials 작업을 통합할 수 있는 좋은 기회가 있습니다. 두 작업 세트도 JSON-LD 위에 구축되기 때문입니다. JSON-LD의 주요 이점 중 하나는 서로 다른 소스의 데이터를 병합할 수 있다는 것입니다. 또 다른 하나는 기본 데이터 형식을 지정하고 사람들이 귀하와 협력하지 않고 프로토콜을 확장할 수 있도록 허용할 수 있다는 것입니다(시스템이 기하급수적으로 성장하기를 원하는 경우 중요함).

질문이 있으면 질문하십시오. 네트워크의 각 JSON blob에 @context 를 요구하는 것은 무거운 요구 사항이 아닙니다.

생각에 감사드립니다!

DHT(Kademlia 유사) + 디지털 서명 + 쿼리 네트워크를 사용하여 인터넷에서 이름 지정을 대체하는 방법을 찾고 있습니다(결국 DNS 대체).

그런 다음 문서의 IPNS 섹션을 확인하십시오. http://static.benet.ai/t/ipfs.pdf (3.7). :)

텔레해시를 아시나요?

예, 나는 일반적인 개념 + 그것을 구축하려는 추진력을 매우 찬성하지만 프로젝트의 많은 결정에 찬성하지 않습니다. 예를 들어, 태그 라인은 "JSON + UDP + DHT = Freedom"이지만 이러한 종류의 시스템은 (a) 데이터 형식을 강제하지 않아야 하고, (b) 전송 프로토콜을 강제하지 않아야 하며, (c) 강제로 전송해서는 안 된다고 생각합니다. 라우팅 시스템. 물론 이 세 가지가 _오늘날_ 훌륭한 선택이지만 이러한 프로토콜은 계층과 시간에 맞게 구축되어야 합니다. 따라서 IPFS는 사용자가 원하는 형식을 사용할 수 있도록 하고 IPFS는 모든 전송 위에 계층화할 수 있으며 첫 번째 라우팅 시스템은 DHT이지만 탐색할 다른 시스템이 있습니다.

IPFS는 Telehash + (merkle) Web으로 볼 수 있습니다.

네트워크의 메타데이터를 기계가 읽을 수 있고 처리할 수 있지만 확장 가능한 방식으로 원한다면 JSON-LD를 사용해야 합니다.

JSON을 전송으로 요구하지 않고 작업의 -LD 부분을 취할 수 있다고 생각합니다. 즉, 귀하의 (훌륭한) 작업은 모든 트리 데이터 구조로 일반화할 수 있으며 다른 시맨틱 웹 형식보다 훨씬 우수하다고 생각합니다. (놀라운 단순성 + 유연성!) 따라서 이 노트에서 내가 가리키는 것은 @context 와 동일하지만 IPFS 링크 데이터 구조(JSON이 아니라 객체를 빠르게 탐색하기 위한 바이너리 압축 형식입니다. -- protobuf는 현재이지만 나중에 자체 설명될 수도 있습니다. -- 저는 IPFS가 데이터베이스로 작동할 만큼 충분히 빠르기를 원합니다. 오늘이 아니라 미래에 :) ).

네트워크의 각 JSON blob에 @context 를 요구하는 것은 큰 요구 사항이 아닙니다.

네, 저도 똑같이 주장했습니다 :)

@jbenet re: https://github.com/dataprotocols/dataprotocols/issues/110#issuecomment -43430309 - 네, 거기에 대한 귀하의 주장은 매우 훌륭하고 잘 알려져 있다고 생각했습니다.

나는 당신이하는 일에 정말 관심이 있습니다. 나는 신문을 훑어보고 당신의 비디오를 보기 시작했습니다. 불행히도 오늘 마감해야 하는 기한이 있지만 당신의 논문을 읽고 내 할일 목록에 있는 전체 비디오를 시청해야 합니다. 아시는지 모르겠지만 저는 W3C를 통해 웹 표준을 구축하는 일을 하고 있습니다. 현재 귀하가 설명하고 있는 것과 유사한 솔루션이 필요한 일련의 문제가 있습니다. 귀하의 작업 중 일부를 웹용으로 작업 중인 차세대 W3C 표준 로그인 솔루션에 통합할 수 있는지 확인하고 싶습니다(위에서 언급한 게시물). 우리는 현재 Telehash를 사용하고 있지만 이에 대한 몇 가지 우려가 있으며 귀하는 우리의 사용 사례에 더 잘 맞을 수 있는 방식으로 문제를 분해한 것 같습니다.

어쨌든 당신이 만든 것에 대해 알아본 다음 다시 연락드리겠습니다. 일주일 안에 연락이 없으면 다시 핑을 보내주세요.

@jbenet님 , 주말에 백서를 자세히 살펴보고 프레젠테이션을 볼 기회가 있었습니다. 이번 주에 이야기할 시간을 정합시다. 저는 미국 동부 해안에 있습니다. 화/수를 제외한 대부분의 날 오전 10시~오후 2시 이용 가능. 내 이메일: [email protected] , Skype: msporny , SIP: sip:[email protected] 최대한 빨리 저에게 연락하세요.

ipns와 이 wrt에 대해 논의하고 싶습니다. 웹 로그인, 자격 ​​증명 및 웹 결제: https://manu.sporny.org/2014/identity-credentials/

@msporny 대단해! 할 것이다. 지금 터치베이스에 이메일을 보냈습니다. 이 문제에서 연락처 세부 정보를 제거할 수 있습니다(공개 등).

우리는 오늘 IRC에서 "이것이 어떤 종류의 물건입니까?" 질문에 답하는 방법을 둘러보고 있었습니다. @jbenet 은 LSON-LD 스타일 @type 또는 @context 링크를 언급했지만 해당 체인에서 어떻게 빠져나왔는지 모르겠습니다. @context 링크가 맨 아래로 내려가나요? @tv42 는 또한 디렉토리 노드가 키로 자식 세그먼트 이름을 사용하기 때문에 파일 이름과의 충돌에 대한 우려를 제기 했습니다. 세그먼트 이름에 접두사를 붙이거나 이스케이프 처리하여 이 문제를 해결할 수 있지만 유형 설명에 대한 해시 ID를 보유하기 위해 명시적 유형 필드를 추가하는 것보다 더 많은 작업처럼 보입니다. 우리가 이런 종류의 일을 더 많이 기대한다면 아마도 링크를 내부 및 외부 세트로 분할해야 할 것입니다. $ @context 유형 항목을 @context 파일 항목 ( 예를 들어).

죄송합니다. 형식은 (거의 확실히) 이 시점에서 변경되지 않습니다. 나는 몇 달을 이것으로 끓이고 다시 홍수 문을 열지 않을 것입니다. 링크 확장과 같은 나머지 질문은 얼마 동안 알려졌으며 올바른 방법을 찾는 것입니다.

ipfs 객체는 json 또는 다른 것과 같은 트리입니다. 이는 JSON(JSON-LD, JSON-스키마 등 포함)에서 사용할 수 있는 모든 솔루션을 IPFS에서 사용할 수 있음을 의미합니다. 게다가 RDF 트리플을 ipfs 객체로 표현하는 것은 간단합니다. 따라서 무엇이든 할 수 있습니다.

실제 데이터는 매우 지저분합니다. 세계 어느 누구도 사람들에게 특정 데이터 유형 지정 시스템을 채택하도록 강요하는 데 성공하지 못했습니다. 그리고 저는 이러한 주장에 시간을 투자하지 않을 것입니다. 장기적으로 실행 가능하다고 생각하는 유일한 솔루션은 사람들이 원하는 것은 무엇이든 할 수 있을 만큼 충분히 유연하고 모든 것이 서로 연결될 만큼 충분히 단단하게 시스템을 만드는 것입니다.

이제 _preferred_ 방식(사람들이 일을 하도록 제안하는 방식)은 (놀라울 정도로 강력하고 간단한) JSON-LD의 @context / @type 가 될 것입니다.

하지만 나는 당신이 어떻게 그 사슬에서 벗어날 수 있는지 잘 모르겠습니다.

질문을 이해하지 못합니다. 체인이 없으므로 컨텍스트를 한 번만 해결하면 됩니다. 그것은 개체에 대한 컨텍스트 파일입니다. 유효한 컨텍스트가 아닌 경우(사양이 있음) 무시합니다. 응용 프로그램은 이러한 유형이 올바른지 _의존해서는 안 되며, 그럴 때 활용해야 합니다.

@tv42 는 또한 디렉토리 노드가 자식 세그먼트 이름을 키로 사용하기 때문에 파일 이름과의 충돌에 대한 우려를 제기했습니다.

dir 데이터 구조에 이미 @context 가 있으면 다른 파일 생성을 허용하지 않습니다. (또는 최악의 경우 (안정된 정렬) 뒤에 링크를 추가). 같은 이름으로 두 개의 파일을 만들려는 것과 같습니다.

2015년 5월 1일 금요일 03:51:22AM -0700에 Juan Batiz-Benet은 다음과 같이 썼습니다.

죄송합니다. 형식은 현재 (대부분) 변경되지 않습니다. 나
몇 달 동안 그것을 끓이고 홍수를 열지 않을 것입니다.
다시 게이트. 나머지 질문(예: 링크 확장)
얼마 동안 알려졌으며 올바른 방법을 찾고 있습니다.
그것.

링크 확장이 제대로 작동해야 합니다. 링크 키 접두사
네임스페이스도 그렇게 나쁘지 않습니다. 유형 정보 채우기
into Data도 작동합니다(이것이 파일과 디렉토리가 작동하는 방식입니다.
[1,2,3,4,5]). 유형을 열거하는 것은 지속 가능한 접근 방식이 아니지만
이러한 장소 중 하나는 유형 해시를 저장하는 장소로 작동합니다.

이제 _선호하는_ 방식 -- 사람들이 일을 하도록 제안하는 방식
-- @context / @type 가 될 가능성이 높습니다.
(놀라울 정도로 강력하고 간단한) JSON-LD.

JSON-LD는 괜찮지만 주변 생태계가 이해해야 합니다.
@-접두사는 특별합니다. 나는 그 특별함이 저장되는 것을 선호한다
추가 데이터(예:
내부/외부 플래그) 따라서 @context 사이에 모호성이 없습니다.
파일 및 @context 유형 링크. 그러나 모든 파일/하위 디렉토리 링크에 키가 있는 경우
'아이/와', 그러면 유형에 대한 '컨텍스트'가 있을 수 있습니다.
파일(또는 무엇이든)에 대한 링크 및 '하위/컨텍스트'. 아직 진행 중이야
객체 생성기가 외부에서 정의한 규칙이어야 합니다.
소비자는 자기 설명이 없는 채널을 통해 동의해야 합니다.

하지만 나는 당신이 어떻게 그 사슬에서 벗어날 수 있는지 잘 모르겠습니다.

질문을 이해하지 못합니다. 사슬이 없다, 당신은 해결
컨텍스트 한 번만 하면 됩니다. 에 대한 컨텍스트 파일입니다.
물체. 유효한 컨텍스트가 아닌 경우 -- 사양이 있습니다 -- 당신은
무시해.

그것은 나를 위해 작동합니다. 자기소개서를 어떻게 끝내는지 궁금하다
체인:

A는 어떤 유형인가요? A/ @context 를 따라 B로 가봅시다. B는 어떤 유형인가요?
B/ @context 를 따라 C로 가자…

그러나 B 사양(내 예에서는 C)을 배포하는 경우에는
B/ @context 링크가 필요합니다. 하지만 채널이 있는 경우
유형 사양(C)을 배포하는 경우 배포하는 데도 사용하지 않겠습니까?
유형 스키마 자체(B)? 그냥 있는게 나을듯.
객체를 설명하는 다중 해시를 보유하는 객체의 일반적인 위치
유형( @context 링크 등). 그런 다음 길을 벗어나
그것이 무엇인지 결정하기 위해 생산자/소비자 커뮤니티에 맡기십시오.
유형 정의에 대한 참조(사양 C, Cv2 또는
대안 CCv1.3, 또는 ...) 또는 멀티 해시를 다음과 같이 사용하려는 경우
불투명한 식별자. 그런 다음 여전히 다음과 같은 작업을 수행할 수 있습니다.

스위치 pbn.GetType() {
case ft.T디렉토리:
root.val = NewDirectory(pointsTo.String(), mnode, 루트, fs)

GetType이 @context Link 해시(또는
어디에서나), TDirectory는 다중 해시가 됩니다.
(QmWellKnownDirectoryType).

응용 프로그램은 이러한 유형이 올바른지 _의존해서는 안되지만
있을 때 활용하십시오.

이것은 불투명한 식별자처럼 들립니다. 어쩌면 우리는 같은 말을 하고 있을지도 몰라
물건 ;).

@tv42 는 또한 파일 이름과의 충돌에 대한 우려를 제기했습니다.
디렉토리 노드는 자식 세그먼트 이름을 키로 사용합니다.

dir 데이터 구조에 이미 @context 가 있으면 허용하지 않습니다.
다른 파일 생성--(또는 최악의 경우 링크를 뒤에 추가합니다.
(안정된 정렬)). 두 개의 파일을 만들려는 것과 같습니다.
같은 이름.

@context 파일을 불법으로 만들려는 경우 ;). 원하는 경우
사람들이 @context 파일을 만들 수 있도록 하려면 다음을 수행할 방법이 필요합니다.
"이 링크는 유형을 가리킵니다"와 "이 링크는
파일/하위 디렉토리/…를 가리킵니다. 그러나 여러 가지 방법이 있습니다
그 문제와 관련하여 우리가 그들 중 하나를 선택하는 한 나는 행복할 것입니다
;).

며칠 전에 @cryptix 와 대화를 나누었고 JSON-LD 사용에 대해 간략하게 이야기했습니다. json-ld에 대한 사양에서는 "링크"를 사용하여 json에서 json-ld로의 매핑을 설명할 수 있다는 점을 지적하고 싶습니다. 저는 개인적으로 이 접근 방식을 선호합니다. 메타데이터가 현재 "힙"한 RDF에 대해 재구성하지 않고도 json-ld를 준수할 수 있기 때문입니다.

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

2015년 5월 1일 금요일 09:24:27 PM -0700에 W. Trevor King은 다음과 같이 썼습니다.

링크 확장이 제대로 작동해야 합니다. 링크 키 접두사
네임스페이스도 그렇게 나쁘지 않습니다. 유형 정보 채우기
into Data도 작동합니다(이것이 파일과 디렉토리가 작동하는 방식입니다.
[1,2,3,4,5]). 유형을 열거하는 것은 지속 가능한 접근 방식이 아니지만
이러한 장소 중 하나는 유형 해시를 저장하는 장소로 작동합니다.

관련 참고 사항(해시된 유형 ID 배포
페이로드), @tv42 에서 Ethos ETypes [1,2,3]에 관심을 갖게 되었습니다. 그래서
나는 이러한 것들에 대한 일종의 명시적인 슬롯이 있을 것이라고 생각합니다.
엄청난.

EType을 본 적이 없습니다. 표면화해주셔서 감사합니다. 앞으로 며칠 동안 읽을 것입니다. 관련된 것은 Kathleen Fisher의 PADS 작업 + 관련입니다. PADS 프로젝트 페이지 가 최근에 변경된 것 같습니다. (그러나 인터넷 아카이브는 우리를 다시 구했습니다 \o/: http://web.archive.org/web/20130125041549/http://www.padsproj.org/ )

• PADS: 임시 데이터 처리를 위한 도메인별 언어
• PADS 프로젝트: 개요
• PADS/T: Ad Hoc 데이터를 기술하고 변환하기 위한 언어
• PADS/ML: 기능적 데이터 설명 언어
• LearnPADS: 임시 데이터에서 자동 도구 생성
• 더 많은 논문 : http://web.archive.org/web/20120205185831/http://www.padsproj.org/doc.html#papers

어쨌든, PADS는 매우 옳은 생각을 가지고 있습니다. 그러나 지금까지 내가 알고 있는 광범위한 구현을 보지 못했습니다. 아마도 여기에서 수정할 수 있는 JSON-LD 스타일이 있을 것입니다.

JSON-LD는 @context 링크를 추가하는 것만이 아닙니다. 특히 각 링크 이름(JSON의 키)은 다음 범주 중 하나에 속해야 합니다.

• @context : 데이터를 설명하는 컨텍스트 링크 또는 인라인 노드
• @id : 현재 노드의 URI
• schema://full-uri : 술어가 URI인 링크로 인식
• prefix:name : 술어가 접두어 URI(컨텍스트에 정의됨)와 이름의 연결인 링크로 인식됩니다.
• name: 컨텍스트에 정의된 경우에만 링크로 인식됩니다.

특히 JSON-LD는 임의의 키/값 맵을 지원하지 않는 것 같습니다. 키가 URI로 해석될 수 있는 경우 이 URI를 사용하는 술어로 간주됩니다. 예를 들어 다음은 유효하지 않습니다.

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

http://xmlns.com/foaf/0.1/name 는 웹 페이지의 캐시된 버전이 아니라 항상 FOAF 이름을 참조하기 때문입니다.

이것이 반드시 문제는 아니지만 개체 형식을 디자인할 때 링크를 연결된 데이터로 해석하기로 결정했다면 반드시 고려해야 합니다. 예를 들어 디렉토리는 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>"
    }
  ]
}

IPFS-LD에서 우리는 각 항목에 대한 컨텍스트와 노드에 연결되는 디렉토리에 대한 노드를 가질 것입니다. 그러면 각 항목에는 고유한 컨텍스트, 이름이 포함된 노드 및 파일 내용이 있는 노드에 대한 링크가 있습니다.

이렇게 하면 JSON 문서에 허용되는 여러 수준의 간접 참조가 추가되지만(모든 것이 하나의 파일에 압축되기 때문에) 각 노드에 다른 해시가 있고 개별적으로 추적해야 하는 IPFS에는 허용되지 않을 수 있습니다.

아마도 우리가 원하는 것은 JSON-LD를 그대로 사용하는 것이 아니라 JSON-LD에서 영감을 얻은 자체 컨텍스트 형식을 정의하는 것입니다. 이것은 형식이 JSON이 아니고 매우 구체적이기 때문에 더 좋을 것입니다. 임의의 키 맵(unixfs용)을 설명할 수 있고 IPFS 개체의 데이터 섹션도 사용하려고 합니다(JSON에는 해당 항목이 없습니다. ).

IPFS 개체의 링크 섹션은 매우 제한적이므로 링크에는 이름이 있고 다른 개체를 가리킵니다. 리터럴 값을 포함할 수 없습니다. 컨텍스트에서 지정해야 하는 것은 URI 형식의 링크의 완전한 이름입니다. 데이터 섹션도 있으므로 포함할 내용을 정의해야 합니다.

unixfs의 경우 다음 객체를 상상할 수 있습니다.

• directory :
  
  
  
  • 디렉토리 컨텍스트를 가리키는 @context 링크
  
  
  • README.md 개체를 가리키는 entry:README.md 링크
  
  
  • 데이터 없음
  
  
• README.md :
  
  
  
  • 파일 컨텍스트를 가리키는 @context 링크
  
  
  • README.md 내용이 있는 데이터 섹션
  
  
• 디렉토리 컨텍스트:

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

}
```

• 파일 컨텍스트:

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

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

}
```

이것을 삼중으로 나타내려면 다음과 같이 해야 합니다.

# 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

안녕하세요 @mildred -- 훌륭한 분석입니다. 재미있게도 irc://irc.frennode.org#json -ld에서 dlongley와의 대화에서 동일한 결론에 도달했습니다(관심 있는 경우 로그를 보낼 수 있음)

나는 여기에서 좀 더 관대한 IPLD 유형을 실험해 왔습니다. 특히 예를 참조하십시오. 이것은 최종(또는 정확한가?)가 아니지만 방향 감각을 제공합니다.

• 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 ( @value 의 사용을 무시하면 잘못된 것입니다)
• 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

중요 참고 사항:

• 다른 값의 포함 _허용_에 대한 편안한 링크(많은 요청), 우리는 {"@type": "mlink", "hash": "<multihash>"} 만 예약합니다.
• 사용자는 데이터 구조에 대한 컨텍스트를 정의할 수 있습니다.
• 경로 표기법을 사용하여 _nest_ 링크할 수 있습니다(예: https://github.com/ipfs/go-ipld/blob/master/ipld.go#L122 -L141).

나는 당신과 내가 옳은 길을 가고 있다고 생각합니다. 또한 JSON-LD에서 많이 벗어나지 않고도 많은 작업을 수행할 수 있다고 생각합니다. 단지 몇 가지 제한을 버리고

@mildred는 여기에 기록합니다.

또한 -- dlongley와의 대화에서 -- 기술적으로 JSON-LD 표준에서 벗어나지 않고 원하는 것을 수행할 수 있어야 합니다. 다만 _변환(압축/확장)을 호출하면 모든 "비 -컨텍스트 정의" 키. (일탈하지 않도록 노력해야 함)

JSON을 변환할 때 json-ld.js 파서가 하는 것이 아니라 생성된 트리플의 관점에서 JSON-LD를 생각하면 많은 혼란을 제거할 수 있다고 생각합니다. JSON 변환 단계는 해당 파서에만 해당되며 문제 없이 다른 방식으로 쉽게 변환하는 것을 상상할 수 있습니다.

이제 go-ipld 로 무엇을 하고 있는지 잘 이해한다면 현재 IPFS 개체의 Link 섹션을 대체할 수 있습니다. 맞습니까? 이 것: merkledag.proto

문제가 있습니다. 이전에는 효율적인 처리(경로와 직접 관련된 링크 이름 및 링크 해시)를 허용하는 간단한 구조가 있었지만 이제는 조금 더 복잡한 구조를 갖게 되었습니다. 연결된 해시를 얻으려면 해시 테이블에서 "mlink" 문자열을 확인해야 합니다. 그게 정말 필요한가요?

연결된 데이터/RDF를 원한다면 단순히 자신의 와이어 형식(protobuf는 내가 생각하는 한 훌륭함)과 JSON으로 변환할 수 있는 방법을 정의하지 않는 것이 좋습니다. 그런 다음 그 위에 JSON-LD 컨텍스트를 사용합니다.

이제 생각하고 있던 다른 데이터 구조에 대해 Unixfs를 제외하고는 훌륭하다고 생각합니다. JSON-LD 키는 모든 상황에서 RDF 술어를 참조해야 하기 때문에 파일 이름을 JSON-LD 키로 가질 수 없습니다. 파일 이름은 리터럴 값입니다.

대신에:

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

나는 이것을 다음과 같이 모델링 할 것입니다 :

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

다시 말하지만, 바이너리/직렬화된 버전은 이와 같을 필요가 없습니다. 이 마지막 표기법을 RDF 트립으로 나타내는 방법은 다음과 같습니다.

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"

저는 IRC에 있습니다. 주저하지 말고 저에게 핑을 보내주십시오.

이 스레드에 대한 RDF에 익숙하지 않은 사람들을 위해 여기에 약간의 설명이 있습니다.

RDF는 데이터를 구조화하는 방법입니다. JSON-LD 뒤에 있는 데이터 모델입니다. RDF에서 모든 데이터는 트리플로 인코딩되어야 합니다.

<subject> <predicate> <object>

• 주체는 URI로 식별되는 노드입니다.
• 술어는 <http://www.w3.org/1999/02/22-rdf-syntax-ns#name> 와 같은 URI입니다. URI는 관계를 고유하게 정의하며 사양이나 스키마에 잘 정의되어야 합니다.
• 개체는 링크/술어의 대상입니다. 리터럴 값(선택적으로 입력할 수 있는 문자열, 예를 들어 정수 또는 날짜, 일반적으로 xsd 스키마에서 파생됨)이거나 URI로 식별되는 다른 노드일 수 있습니다.

삼중 표기법은 모든 주제 및 개체 노드에 고유하게 식별하는 URI가 있다고 가정합니다. 한 줄에 하나씩 포함하는 모든 트리플을 나열하여 완전한 데이터 구조를 정의합니다.

JSON-LD의 JSON 키는 주체(키가 있는 객체)와 객체(JSON-LD 키의 값)를 연결하는 술어입니다. 이 경우 URI는 주체와 객체를 참조하는 데 사용되지 않습니다. 참조하는 데 사용할 수 있는 개체의 URI를 지정하려면 @id 속성이 있습니다.

HTTP를 통해 작동하는 방식과 비교하여 IPFS를 통한 연결된 데이터의 작동 방식을 설명하는 글이 있습니까? (URI는 무엇입니까? IPFS를 통한 연결된 데이터의 게시자와 소비자를 위한 모범 사례는 무엇입니까?)

보다:

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

IPLD는 json 데이터 모델을 제공합니다. IPLD 위에 모든 JSON-LD를 계층화할 수 있습니다.

(아직 착륙하지 않음)

@jbenet 은 이 스레드를 읽고 링크된 데이터를 사용하는 것은 훌륭한 이니셔티브입니다. IMHO

Linked Data가 하나의 직렬화를 요구하지 않는다는 점에서 정확합니다. JSON-LD, RDF/XML, RDFa, Turtle 또는 기타 여러 형식을 사용할 수 있습니다.

Linked Data에 필요한 것은 JSON의 키가 URI라는 것입니다. 이것은 JSON-LD를 사용하는 경우 컨텍스트에서 하나의 라이너로 수행하거나 명시적으로 작성할 수 있는 urn:string:<key> 접두사로 간단할 수 있습니다.

또 다른 (일반적으로 선호되는) 방법은 각 용어에 대해 사람이 읽을 수 있는 설명이 포함된 http(s) 또는 ipfs: 문서에 키에 대한 용어를 넣는 것입니다.

Linked Data로 작성된 IPFS 해시에 대한 메타 데이터도 흥미롭다고 생각합니다. 저는 오늘 Turtle에서 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

연결된 데이터의 개념은 사물에 부여한 식별자가 관련 사물에 연결되는 데이터를 포함하여 유용한 데이터를 제공한다는 것입니다. 따라서 디렉토리는 포함된 항목의 URI 목록을 제공하고 이벤트는 시간과 데이터 및 초대된 사람들에 대한 링크를 제공하고 사람들은 그룹 및 다른 사람들에 대한 링크를 제공하는 등의 방식으로 진행됩니다. http: 대신 ipfs:를 통해 이 모든 작업을 수행하면 물론 제대로 작동하며 두 공간을 연결할 수 있습니다. 예를 들어 한 공간에 있는 것이 다른 공간에 있는 것과 같다고 주장할 수 있습니다. 친구는 http: space에 문서화하고 귀하의 출판물은 ipfs: space에 문서화할 수 있습니다.

(rdfhead로서 저는 Turtle을 형식으로 선호합니다. iI는 간단하고 강력하지만 JSONLD를 사용할 수 있기 때문입니다.)

/me는 http://static.benet.ai/t/ipfs.pdf 를 읽기 위해 static.benet.ai에 연결할 수 없습니다.

@timbl https://github.com/ipfs/papers/blob/master/ipfs-cap2pfs/ipfs-p2p-file-system.pdf 에서 IPFS 문서의 최신 버전을 찾을 수 있습니다. 공용 IPFS 게이트웨이를 통한 동일한 문서: https://ipfs.io/ipfs/QmV9tSDx9UiPeWExXEeH6aoDvmihvx6jD5eLb4jbTaKGps

예를 들어 한 공간에 있는 것이 다른 공간에 있는 것과 같다고 주장할 수 있습니다.

네! 다음은 모두 동일합니다.

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

죄송합니다. dweb: URI 체계와 https://dweb.link 는 아직 실제로 작동하지 않습니다.

지금은 URI의 경우 fs:/ipfs/somehash 이고(IPFS 게이트웨이 리디렉션 애드온에서) HTTP의 경우 https://ipfs.io/ipfs/somehash 입니다.

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

이 스레드의 사람들이 그것을 놓친 경우에 발생했습니다!

https://ipld.io/

https://github.com/ipld/ipld 에서 대화를 계속합시다.

확신하는. 링크된 데이터의 측면에 대해 논의하려면 언제든지 다음을 방문하십시오.

https://gitter.im/linkeddata/chat

@nicola 나는 그 채널에 대해 낯설지 않다.

우리는 실제로 오늘 시스템에 ipfs: URI를 추가하는 것에 대해 논의했습니다. ipld의 행운을 빕니다!

분명히 LD가 아닌 것에 대해 잘 정의된 용어 "연결된 데이터"를 사용하는 이유는 무엇입니까?
https://www.w3.org/standards/semanticweb/data

그래서, 나는 이것이 오래된 실이라는 것을 알고 있지만 후손을 위해 믹스하기 위해 나 자신을 추가하고 있습니다.

저는 검증 가능한 자격 증명 데이터 모델(https://w3c.github.io/vc-data-model/)을 작업해 왔으며 JSON-LD 대 IPLD로 표시되는 @context 를 조정하는 데 몇 가지 문제가 발생했습니다. (참조: https://github.com/w3c/vc-data-model/pull/261 ). JSON-LD는 IPLD와 완벽하게 호환되지만 IPLD는 기존 사양과의 상호 운용성을 위해 필요한 JSON-LD와 완전히 하위 호환되지 않는다는 것을 알 수 있습니다. 내가 볼 때 해결책은 ipld: 를 ietf에서 유효한 체계로 추가한 다음(참조: https://github.com/ipld/specs/issues/98) { <attr> : ipld:<cid> } 를 허용하는 것입니다. { "/" : <cid> } 가 IPLD에서 수행하는 것과 동일해야 합니다(참조: https://github.com/ipld/specs/issues/99). 또한/추가로 application/ipld 의 MIME Content-type을 등록하여 프로토콜을 정의하는 유형을 선언합니다. 이것은 혼동을 완화하기 위해 application/json+ipld 대 application/cbor+ipld 를 허용하도록 합성됩니다. ( @mildred 저는 ipfs://를 좋아하지 않습니다. 왜냐하면 우리는 자연스러운 연결과 ` { "@context" : "/ipfs/" }'은(는) 유효한 URI입니다.

의미론적 상호 운용성에 관해서는 IPLD 위에 JSON-LD 컨텍스트를 계층화했습니다. 그러나 이것은 루팅 문제에 도달하고 URI를 JSON-LD에 유효한 값으로 포함하여 쉽게 해결할 수 있습니다.

궁극적 으로 그것은 Turtles 입니다 .

(rdfhead로서 저는 Turtle을 형식으로 선호합니다. iI는 간단하고 강력하지만 JSONLD를 사용할 수 있기 때문입니다.)

이에 대한 완벽한 예는 http://www.w3.org/ 를 참조하는 xsd:datetime 에 연결되는 https://w3id.org/did/v1 에서 검증 가능한 자격 증명에 대한 @context 의 datetime 처리입니다. 2001/XMLSchema# , 문서 소스에 대한 설명이 html 에 있습니다.

이 xml에서 내가 가장 좋아하는 주석은 다음과 같습니다.

먼저 기본 제공 기본 데이터 유형입니다. 이러한 정의는 정보용이며 실제 기본 제공 정의는 마법입니다.

:turtle: > :turtle: > :turtle: 스택의 맨 아래에서 @timbl 에 동의하고 다음을 사용하여 JSON-LD와의 하위 호환성을 조정할 수 있는 한 이 마법으로 작업할 수 있습니다. 위의 ipld: .

@jonnycrunch 당신의 아이디어를 지지합니다. Turtle은 가장 인기가 없습니다. JSON이 웹에서 잘 확립되어 있기 때문입니다. 특히 JSON이 브라우저에 기본적으로 제공되고 학습 곡선이 얕기 때문입니다.

광범위한 개발자 커뮤니티에 호소하는 것과 상호 운용 가능하고 기능이 풍부한 시스템(흑백이 아님)을 갖는 것 사이에는 균형이 있어야 합니다.

전체 URL을 입력하면 @context 문제가 사라집니다. 더 많은 문자가 있지만 왕복을 피하고 원격 파일의 무결성을 확인할 필요가 없다는 점을 감안할 때 모범 사례는 아니지만 더 낫다고 생각하고 있습니다.

궁극적으로 URI는 이름(uuid)과 로케이터(프로토콜) 모두이며 두뇌가 두 가지를 동시에 쉽게 생각하지 않는다는 점에서 혼란이 발생합니다. JSON 키에서 URI를 사용하거나 URI에 대한 약칭을 사용하는 지점에 도달할 수 있다면 이러한 문제 중 많은 부분이 사라집니다. 실제로 ipfs: 및 http: 이름을 지정하면 연결된 데이터가 일종의 접착제로 사용되는 협력 네트워크의 일부가 되어야 합니다.

ipld:<cid> 구문을 사용하도록 내 의견을 업데이트했습니다. 이는 신뢰할 수 없고 따라서 ipld:// 이중 슬래시 // 가치가 없다는 것을 깨달았습니다. 페이로드는 자체 설명적이므로 자체 권한이며 자체적으로 있어야 합니다. 그러나 그것은 전문가들의 주장입니다.

@jonnycrunch 는 다음과 같이 썼습니다.

해결책은 ipld:를 IETF의 유효한 체계로 추가하는 것입니다.

저는 이 접근 방식을 매우 지지하며 (보다 전통적인) Linked Data 커뮤니티와 IPFS/IPLD 커뮤니티 간의 훌륭한 interop 스토리로 이어질 것이라고 생각합니다.