Ipfs: IPFS-LD - Linked Data

Hey @jbenet, great job w/ IPFS, very interested in what you're doing as we are looking into using DHTs (Kademlia-like) + digital signatures + query network to replace naming on the Internet (replace DNS eventually). The basic work we're doing is close to what you're doing w/ IPFS: https://manu.sporny.org/2014/identity-credentials/ . We are using JSON-LD for that initiative, are you aware of Telehash? If not, you should take a look as some of those concepts might strengthen IPFS.

In any case, if you want the metadata on the network to be machine-readable and processable but in an extensible way, you should use JSON-LD. If you use JSON-LD, there is a good chance that you could integrate the Web Payments and Credentials work happening at W3C because both of those sets of work are also built on top of JSON-LD. One of the primary benefits of JSON-LD is that you can merge data from disparate sources. Another is that you can specify the basic data format and allow people to extend the protocol w/o coordinating with you (which is important if you want the system to grow at an exponential rate).

Just some thoughts, if you have questions, please ask. Requiring a @context in each JSON blob on the network isn't a heavy requirement.

thanks for the thoughts!

we are looking into using DHTs (Kademlia-like) + digital signatures + query network to replace naming on the Internet (replace DNS eventually).

Then make sure to see the IPNS section in the paper: http://static.benet.ai/t/ipfs.pdf (3.7). :)

are you aware of Telehash?

Yes, I very much approve of the general concept + drive to build it, but am not in favor of many of the decisions of the project. Case in point, the tagline is "JSON + UDP + DHT = Freedom" but I think that these sorts of systems should (a) not force a data format, (b) not force a transport protocol, and (c) not force a routing system. Of course, these three are great choices _today_, but these protocols must be built to fit across layers and across time. IPFS thus allows users to use any format they desire, IPFS can layer on top of any transport, and though the first Routing system will be a DHT, there are others to explore.

You can see IPFS as Telehash + the (merkle) Web.

if you want the metadata on the network to be machine-readable and processable but in an extensible way, you should use JSON-LD.

I think we can take the -LD part of your work without requiring JSON as the transport. I.e. I think your (awesome) work is generalizable to any tree data structure, and is far better than other semantic web formats. (amazing simplicity + flexibility!) So what I'm pointing towards in these notes is use the equivalent of @context but in the IPFS link datastructure (which is not JSON, it's a binary packed format for quick seeking through objects -- protobuf today, but may also be self-describing later on -- I intend IPFS to be fast enough to work as a database. not today, but in the future :) ).

Requiring a @context in each JSON blob on the network isn't a heavy requirement.

Yep, I've argued the same :)

@jbenet re: https://github.com/dataprotocols/dataprotocols/issues/110#issuecomment-43430309 - yeah, I thought your arguments there were very good and well informed.

I'm really interested in what you're doing, I skimmed the paper and started watching your video. Unfortunately, I have deadlines that I need to get through today, but have reading your paper and watching the entire video on my to-do list. I don't know if you know this, but I work on building standards for the Web via the W3C. We have a set of problems right now that need a solution similar to the one you're outlining. I want to see if we can integrate some of your work into the next generation W3C standard login solution we're working on for the Web (the post I alluded to above). We're currently using Telehash, but do have some concerns w/ it and you seem to have decomposed the problem in a way that might fit our use cases better.

In any case, let me get into what you've created and then get back to you. If you don't hear from me within the week, please ping me again.

Hey @jbenet, I had a chance to look through the whitepaper in more detail over the weekend as well as watch your presentation. Let's setup a time to talk this coming week. I'm on the east coast, US. Available 10am-2pm most days except Tue/Wed. My email: [email protected] , Skype: msporny , SIP: sip:[email protected] Get in touch w/ me at your earliest convenience.

I'd like to discuss ipns and this wrt. login on the Web, Credentials, and Web Payments: https://manu.sporny.org/2014/identity-credentials/

@msporny great! will do. Sent an email just now to touch base. You might want to remove your contact details from this issue (as it's public, etc).

We were kicking around how to answer “what kind of object is this” questions on IRC today. @jbenet mentioned LSON-LD style @type or @context links, but I'm not sure how you break out of that chain. Is it @context links all the way down? @tv42 also raised concerns about collisions with filenames, since directory nodes use child segment names as their keys. You could work around this by prefixing or otherwise escaping the segment names, but that seems like more work than just adding an explicit Type field for holding the hash ID for the type description. If we expect more of this sort of thing, maybe it just calls for partitioning Links into interenal and external sets. You could do that with @jbenet's proposed Link protobuf extension approach (if that becomes a thing) by adding an ‘internal’ boolean to separate the @context type entry from any @context file entries (for example).

sorry, the format is (almost certainly) not changing at this point. i spent months boiling it down to this and not going to open the flood gates on that again. the remaining questions (like link extensions) have been known for some time and just finding the right way to do it.

an ipfs object is a tree like json or anything else. this means that all the solutions available to JSON (inc JSON-LD, JSON-schema, and so on) are available to IPFS. moreover, it is trivial to represent RDF triples as ipfs objects. hence, you can do anything and everything.

real data is very messy. nobody in the world has succeed in forcing people to adopt a particular data typing system-- and i'm not going to sink time into those arguments. The only solution i think is viable in the long term is to make a system flexible enough for people to do whatever they want, and just rigid enough so everything interlinks.

now, the _preferred_ way -- the way we'll suggest people do things -- is likely going to be the @context / @type from the (amazingly powerful and simple) JSON-LD.

but I'm not sure how you break out of that chain

i don't understand the question. there is no chain, you resolve context once and that's it. that's the context file for the object. if it is not a valid context -- there is a spec -- you ignore it. applications should not _depend_ on these types being correct, but rather leverage them when they are.

@tv42 also raised concerns about collisions with filenames, since directory nodes use child segment names as their keys.

if a dir datastructure already has a @context it would not allow the creation of another file-- (or at worst, append the link after (stable sort)). it's the same as trying to create two files with the same name.

On Fri, May 01, 2015 at 03:51:22AM -0700, Juan Batiz-Benet wrote:

sorry, the format is (most likely) not changing at this point. i
spent months boiling it down to this and not going to open the flood
gates on that again. the remaining questions (like link extensions)
have been known for some time and just finding the right way to do
it.

Link extensions should work fine. And prefixing link keys to
namespace them isn't that bad either. Stuffing the type information
into Data works too (that's how files and directories work now
[1,2,3,4,5]). Enumerating types is not a sustainable approach, but
any of these places would work as a place to store a type hash.

now, the _preferred_ way -- the way we'll suggest people do things
-- is likely going to be the @context / @type from the
(amazingly powerful and simple) JSON-LD.

JSON-LD is fine, but the ecosystem around it will need to understand
that the @-prefix is special. I'd prefer that special-ness be stored
explicitly by extending the Link entries with additional data (e.g. an
internal/external flag) so we don't have ambiguity between a @context
file and a @context type link. But if all file/subdir links are keyed
with ‘child/’, then you could have ‘context’ for the type
link and ‘child/context’ for the file (or whatever). It's still going
to have to be an externally-defined convention that object generators
and consumers need to agree on through a non-self-describing channel.

but I'm not sure how you break out of that chain

i don't understand the question. there is no chain, you resolve
context once and that's it. that's the context file for the
object. if it is not a valid context -- there is a spec -- you
ignore it.

That works for me. I was wondering how you end a self-describing
chain:

What type is A? Let's just follow A/@context to B. What type is B?
Let's just follow B/@context to C…

But if you're distributing the B spec (C in my example), there's no
need for a B/@context link. But if you have a channel for
distributing the type spec (C), why not also use it to distribute the
type schemas themselves (B)? It seems like it's better to just have a
conventional place in objects that holds a multihash describing their
type (your @context link, or whatever). Then get out of the way and
leave it up to producer/consumer communities to decide if that's a
reference to a type definition (maybe under spec C, or Cv2, or the
alternative CCv1.3, or …) or if they just want to use the multihash as
an opaque identifier. Then you can still do things like:

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

it's just that GetType would be grabbing the @context Link hash (or
wherever), and TDirectory would be a multihash
(QmWellKnownDirectoryType).

applications should not _depend_ on these types being correct, but
rather leverage them when they are.

This sounds like an opaque identifier. Maybe we're saying the same
thing ;).

@tv42 also raised concerns about collisions with filenames, since
directory nodes use child segment names as their keys.

if a dir datastructure already has a @context it would not allow
the creation of another file-- (or at worst, append the link after
(stable sort)). it's the same as trying to create two files with the
same name.

It is if you want to make @context files illegal ;). If you want to
allow folks to create @context files, you'll need some way to
disambiguate between “this link points at a type” and “this link
points at a file/subdirectory/…”. But there are a number of ways
around that problem, so as long as we pick one of them I'll be happy
;).

I had a conversation with @cryptix several days ago and we briefly talked about using JSON-LD. I would just like to point out that the spec for json-ld allows the use of a "link" to describe the mappings from the json to json-ld. I personally prefer this approach because it allows the metadata to be compliant with json-ld without restructuring it for whatever flavor of RDF is currently "hip".

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

On Fri, May 01, 2015 at 09:24:27PM -0700, W. Trevor King wrote:

Link extensions should work fine. And prefixing link keys to
namespace them isn't that bad either. Stuffing the type information
into Data works too (that's how files and directories work now
[1,2,3,4,5]). Enumerating types is not a sustainable approach, but
any of these places would work as a place to store a type hash.

On a related note (distributing hashed type IDs along with the
payload), @tv42 just brought my attention to Ethos ETypes [1,2,3]. So
I think having some sort of explicit slot for these things would be
great.

Haven't seen ETypes, thanks for surfacing. will read over next couple of days. Something relevant is Kathleen Fisher's PADS work + related. The PADS project page seems to have been changed recently (if only there was some content-addressed immutable store of the web...). (But the internet archive saved us again \o/: http://web.archive.org/web/20130125041549/http://www.padsproj.org/ )

• PADS: A domain-specific language for processing ad hoc data
• The PADS Project: an overview
• PADS/T: A Language for Describing and Transforming Ad Hoc Data
• PADS/ML: A Functional Data Description Language
• LearnPADS: automatic tool generation from ad-hoc data
• more papers: http://web.archive.org/web/20120205185831/http://www.padsproj.org/doc.html#papers

Anyway, PADS has very much the right idea. but so far hasn't seen wide implementation, that i'm aware of. perhaps there's something in the style of JSON-LD that can fix that here.

JSON-LD is not just about adding a @context link. In particular, each link name (key in JSON) must fall in one of these categories:

• @context: context link or inline node describing the data
• @id: the URI of the current node
• scheme://full-uri: is recognized as a link whose predicate is the URI
• prefix:name: is recognized as a link whose predicate is the concatenation of the prefix URI (defined in context) and name
• name: is recognized as a link only if defined in context

In particular, JSON-LD does not seem to support arbitrary key/values maps. If the key can be interpreted as an URI, it will be considered a predicate using this URI. For eample, the following is invalid:

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

as http://xmlns.com/foaf/0.1/name will always refer to a FOAF name, and not the cached version of a web page.

This is not necessarily a problem but must be considered if we decide to interpret links as linked data when designing object formats. For example, a directory could be represented this way using 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>"
    }
  ]
}

In IPFS-LD we would have a node for the directory, linking to a context and to a node for each entry. Each entry would then have links to their own context, a node containing their name and a node with the file content.

This add multiple levels of indirection, that are acceptable for JSON documents (because everything is packed in one file) but might not be acceptable for IPFS where each node has a different hash and must be tracked separately.

Perhaps, what we want is not to use JSON-LD as it is, but define our own context format that is inspired from JSON-LD. This would be better because our format is not JSON, and is very specific: We ant to be able to describe arbitrary key maps (for unixfs) and we also want to use the data section of our IPFS objects (JSON doesn't have that).

As the link section of IPFS objects is very restrictive, links have a name and points to another object. It cannot contain literal values. What we need to specify in the context is the fully qualified name of the link in URI form. As we also have a data section, we need to define what it contains.

For unixfs, I would imagine the following objects:

• directory:
  
  
  
  • link @context pointing to directory-context
  
  
  • link entry:README.md pointing to the README.md object
  
  
  • no data
  
  
• README.md:
  
  
  
  • link @context pointing to file-context
  
  
  • data section with the content of README.md
  
  
• directory-context:

```
{
// @type: the type of the IPFS object
"@type": "http://schema/unixfs#Directory"

// entry: declares the links starting with "entry:"
//   @id: the relationship with the pointed object
//   @key: the relationship with the link name suffix (after ':')
"entry": {
  "@id": "http://schema/unixfs#containsEntry",
  "@key": "http://schema/unixfs#hasFilename"
}

}
```

• file-context:

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

// @data: the relationship with the data section of the object
"@data": "http://schema/unixfs#content"

}
```

If we wanted to represent this in triples, we would have:

# 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 -- great analysis. Funnily i reached the same conclusions in a conversation with dlongley in irc://irc.frennode.org#json-ld (can send you logs if interested)

I've been experimenting a bit with a more permissive IPLD type of thing here -- in particular see the examples. these are not final (or correct?), but give a sense of direction

• https://github.com/ipfs/go-ipld
• https://github.com/ipfs/go-ipld/issues/1
• https://github.com/ipfs/go-ipld/blob/master/ipld.go#L57-L89
• https://github.com/ipfs/go-ipld/blob/master/examples/commit/commit.go#L10-L15 (ignore the use of @value, it's 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

Important notes:

• relaxing links to _allow_ inclusion of other values (much requested), we only reserve {"@type": "mlink", "hash": "<multihash>"}
• users can define contexts for their data structures
• can _nest_ links, using path notation to traverse e.g. https://github.com/ipfs/go-ipld/blob/master/ipld.go#L122-L141

I think you and i are very much on the right track. I think also that we can probably do a lot of this without deviating much from JSON-LD. merely dropping some restrictions

@mildred logs here

also should say that -- from my conversation with dlongley -- it should be possible to do what we want without technically deviating from the JSON-LD standard, just that _calling the transforms (compaction/expansion)_ would strip out all the "non-context-defined" keys. (we should endeavor not to deviate)

I think you would remove much confusion by thinking of JSON-LD in terms of triples generated, rather than what does the json-ld.js parser in transforming JSON. The JSON transformation step is specific to that parser and you could imagine easily transform it another way without problems.

Now, if I understand well what you're doing with go-ipld, it may replace the Link section in the current IPFS objects, right ? This thing: merkledag.proto

I see a problem there. Where previously we had a simple structure that allowed efficient processing (link name, directly related to path, and link hash), we now have a little more complex structure. To get to the linked hash, you have to resolve the string "mlink" in a hash table. is that really necessary?

If you want linked data / RDF, why not simply define your own wire format (protobuf is great as far as I'm concerned) and the way it can be translated to JSON. Then use the JSON-LD context on top of that.

Now, about the different data structure you were thinking of, I think they are great, with the exception of the unixfs: we can't have filenames as JSON-LD keys because JSON-LD keys must under all circumstances refer to RDF predicates. A filename is a literal value.

Instead of:

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

I would model this as:

{
  @context: {
    "ipfs":   "tag:ipfs.io,2015:ipfs:"
    "unixfs": "tag:ipfs.io,2015:unixfs:"
  }
  @type: "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"
    }
  ]
}

Again, the binary/serialized version needs not to be like this. The way of representing this last notation as RDF tripes would be:

DIRECTORY              <tag:ipfs.io,2015:unixfs:contains> <ipfs://Hash:foo>
DIRECTORY              <tag:ipfs.io,2015:unixfs:contains> <ipfs://Hash:bar.jpeg>
<ipfs://Hash:foo>      @type                              <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> @type                              <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"

I'm on IRC, don't hesitate to ping me there.

For those unfamiliar with RDF on this thread, here is a little explanation:

RDF is a way to structure your data. it is the data model behind JSON-LD. In RDF, all data must be encoded in triples:

<subject> <predicate> <object>

• The subject is a node that is identified by a URI
• The predicate is an URI like <http://www.w3.org/1999/02/22-rdf-syntax-ns#name>. The URI uniquely defines the relationship, and should preferably be well defined in a spec or schema.
• The object is the target of the link/predicate. It can be a literal value (a string, that can be optionally typed, for example as an integer or a date, generally derived from the xsd schema) or it can be another node, identified by its URI

The triple notation supposes that every subject and object node has a URI that uniquely identifies it. It defines the complete data structure by listing all the triples that it contains one per line.

JSON keys in JSON-LD are predicates that links the subject (the object in which the key is present) and the object: the value of the JSON-LD key. In this case, URI are not used to refer to the subject and object. If you want to specify the URI of an object that can be used to refer to it, there is the @id property.

Is there a write up anywhere explaining how Linked Data over IPFS works compared to how it works over HTTP? (What are the URIs like? What should the best practices for publishers and consumers of Linked Data over IPFS be?)

See:

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

IPLD give you the json data model. you can layer any JSON-LD on top of IPLD.

(not landed yet)

@jbenet just read through this thread, using linked data is a great initiative IMHO

You are correct in that Linked Data does not mandate any one serialization. It is possible to use JSON-LD, RDF/XML, RDFa, Turtle or a bunch of other formats

What Linked Data does require is that the keys in JSON are URIs. This could be as simple as prefixing them with urn:string:<key> for which, if using JSON-LD could be done as a one liner in the context, or written out explicitly.

Another (generally preferred) way would be to put they terms for the keys in an http(s) or ipfs: document that contains human readable descriptions for each term.

I think also interesting is meta data for an IPFS hash written in Linked Data. I made a quick attempt of this today in Turtle, reusing the pattern outlined in 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

The idea of linked data is that the identifiers you give to things, if you look them up give them useful data, including data which links to related things. So a directory gives you a list of the URIs of the things it contains, an Event gives you the time and data and links to people invited, people give you links to groups and other people, and so on. Doing all this over ipfs: instead of http: of course works fine, and you could link the two spaces. You can for example assert that something in one space is the same as something in another. You could your friends documented in http: space and your publications documented in ipfs: space or whatever you like.

(As an rdfhead, I prefer Turtle as a format as iI find it simple and powerful but you can use JSONLD sure)

/me can't connect to static.benet.ai to read http://static.benet.ai/t/ipfs.pdf

@timbl you can find a more up-to-date version of the IPFS paper here: https://github.com/ipfs/papers/blob/master/ipfs-cap2pfs/ipfs-p2p-file-system.pdf or the same paper via public IPFS gateways: https://ipfs.io/ipfs/QmV9tSDx9UiPeWExXEeH6aoDvmihvx6jD5eLb4jbTaKGps

You can for example assert that something in one space is the same as something in another.

Yes! These are all the same:

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

Sorry about that, the dweb: URI scheme and https://dweb.link don't actually work yet.

For now it's fs:/ipfs/somehash for URIs (in the IPFS Gateway Redirect addon) and https://ipfs.io/ipfs/somehash for HTTP:

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

In case people on this thread missed it, it happened!

https://ipld.io/

let's continue the convo on https://github.com/ipld/ipld

Sure. Feel free to drop in to discuss aspects of linked data at :

https://gitter.im/linkeddata/chat

@nicola Im sure is no stranger to that channel

We were actually discussing adding ipfs: URIs to our system today. Best of luck with ipld!

Why use the well-defined term "Linked Data" for something that clearly is not LD?
https://www.w3.org/standards/semanticweb/data

so, I know this is an old thread but I'm adding myself to mix for posterity.

I have been working the Verifiable Credentials data model (https://w3c.github.io/vc-data-model/) and came up with some problems reconciling the @context represented in JSON-LD vs IPLD. (see: https://github.com/w3c/vc-data-model/pull/261 ). I can recognize that JSON-LD is completely compatible with IPLD, but IPLD is not completely backwards compatible with JSON-LD, which would be necessary for interoperability with existing specs. As I see it, the solution would be to add ipld: as a valid scheme in ietf (see: https://github.com/ipld/specs/issues/98 ) then allow for { <attr> : ipld:<cid> } be the same as what { "/" : <cid> } accomplishes in IPLD (see : https://github.com/ipld/specs/issues/99). Also/additionally register the MIME Content-type of application/ipld to declare the type which defines the protocol. This would compound to allow for application/json+ipld vs application/cbor+ipld to alleviate confusion. (@mildred I don't like ipfs:// for this as we need natural linking and ` { "@context" : "/ipfs/" }' is a valid URI )

As for semantic interoperability, I have been layering JSON-LD context on top of IPLD. However, this gets to a rooting problem, easily solve with embedding URIs as valid values in the JSON-LD.

Ultimately, it is Turtles all the way down :turtle: > :turtle: > :turtle: until you get to the bottom where you find @timbl , which is why I think he prefers Turtle as a format :smiley:.

(As an rdfhead, I prefer Turtle as a format as iI find it simple and powerful but you can use JSONLD sure)

A perfect example of this is the handling of datetime in @context for Verifiable Credentials at https://w3id.org/did/v1 which links to xsd:datetime which references http://www.w3.org/2001/XMLSchema#, where the explanation as documentation source is in html.

My favorite annotation in this xml is:

First the built-in primitive datatypes. These definitions are for information only, the real built-in definitions are magic.

I can work with this magic, as long as we accept that at the bottom of the stack of :turtle: > :turtle: > :turtle: we agree it is @timbl and then we can reconcile the backwards compatibility with JSON-LD using the above with ipld:.

@jonnycrunch I support your ideas. Turtle is not the most popular, because JSON is quite well established on the web, especially as JSON is native to browsers, and has a shallow learning curve.

There's a balance to be had between appealing to a wide dev community and having a system that is interoperable (not something that black and white) and feature rich.

The @context problem goes away if you type out the full url. While it's more characters, Im staring to think it's a better, if not best practice, given it avoids a round trip and you need not verify the integrity of the remote file.

Ultimately confusion arises in that URIs are both names (uuids) and locators (protocol) and the brain does not easily think about both at once. If we can get to the point where we are using URIs or shorthand for URIs in the keys of our JSON, many of these problems go away. Indeed as naming ipfs: and http: should become part of a cooperative network, with linked data as a kind of glue.

i updated my comment to use the syntax ipld:<cid> realizing it is non-authoritative and thus not worthy of the ipld:// double slash // . Since the payload is self-describing it is its own authority and should stand on its own. But that is an argument for the experts.

@jonnycrunch wrote:

the solution would be to add ipld: as a valid scheme in IETF

I am very supportive of this approach and think it would lead to a great interop story between the (more traditional) Linked Data community and the IPFS/IPLD community.