notes

[jbenet]

these are all equivalent.

(1) no context, direct linked data link.

{
  "author": { 
    "@type": "/ipfs/<hash-of-mlink-schema>/mlink", 
    "@value": "<hash-of-author>"
  },
  "committer": { 
    "@type": "/ipfs/<hash-of-mlink-schema>/mlink", 
    "@value": "<hash-of-committer>"
  },
  "object": { 
    "@type": "/ipfs/<hash-of-mlink-schema>/mlink", 
    "@value": "<hash-of-object>"
  },
  "comment": "hello there this is a comment."
}

(2) mdag general context, use mlink shortcut.

define general mdag context

{
  "@context": {
    "mlink": "/ipfs/<hash-of-mlink-schema>/mlink"
  },
}

use it in commits

{
  "@context": "/ipfs/<hash-of-mdag-schema>/mdag",
  "author": { 
    "@type": "mlink", 
    "@value": "<hash-of-author>"
  },
  "committer": { 
    "@type": "mlink", 
    "@value": "<hash-of-committer>"
  },
  "object": { 
    "@type": "mlink", 
    "@value": "<hash-of-object>"
  },
  "comment": "hello there this is a comment."
}

(3) specific commit context. well typed

define commit context

{
  "@context": [
    "/ipfs/<hash-of-mdag-schema>/mdag", // import mdag.
    {
      "author": { "@type": "mlink" },
      "committer": { "@type": "mlink" },
      "object": { "@type": "mlink" },
      "comment": { "@type": "string" }
    }
  ]
}

use it in commits

{
  "@context": "/ipfs/<hash-of-commit-schema>/commit",
  "author": "<hash-of-author>",
  "committer": "<hash-of-committer>",
  "object": "<hash-of-object>",
  "comment": "hello there this is a comment."
}

[jbenet]

(if we add:

{
  "type": "@type",
  "value": "@value",
}

to the mdag root context, people can use type instead of @type.)

[jbenet]

Hey @msporny -- would love your feedback here. is there anything special i need to do to define that "mlink" is a type? are there "type declarations" in json-ld? im not seeing it on the spec[0]

[0] http://www.w3.org/TR/json-ld-api/

[msporny]

Keep in mind that RDF has the concept of a "value type" aka literal type (like "2015-04-13" is a "http://www.w3.org/2001/XMLSchema#date"), which I think you're using above.

There is also an object type ( { "@type": "Person", name: "Juan Batiz-Benet" } is a "http://schema.org/Person"), which you might be interested in if the mlink is supposed to have other attributes associated with it. You can do some crazy RDF inference stuff with attributes and objects (for example, if you see "mlink" then the associated object is of type Foobar), but I suggest you stay away from stuff like that unless absolutely necessary. You don't want to have to write an inference engine for IPFS.

is there anything special i need to do to define that "mlink" is a type?

If you are trying to say "mlink" is a value type, then option #3 above is the cleanest and what I'd recommend (but be sure to also specify "@id" in the term declaration).

are there "type declarations" in json-ld?

Yes, and it depends on what you mean by "type". Some relevant sections in the JSON-LD spec on typing values and typing objects:

http://www.w3.org/TR/json-ld/#specifying-the-type

http://www.w3.org/TR/json-ld/#typed-values

http://www.w3.org/TR/json-ld/#type-coercion

If you have a link to what you're trying to model w/ 'mlink', I'll be able to provide more help.

[nicola]

Yes, I love this!
I hope to chat with you sometime soon about my work on ld+ipfs

[msporny]

@nicola happy to chat, just let me know what your availability is. My Skype: msporny - mobile: 540-641-1942 - and email: msporny@digitalbazaar.com

[jbenet]

@nicola @msporny me too! if relevant!

---

@msporny thanks very much.

If you are trying to say "mlink" is a value type, then option #3 above is the cleanest and what I'd recommend (but be sure to also specify "@id" in the term declaration).

So, like so:

{
  "@context": {
    "mlink": {
      "@id": "/ipfs/<hash-of-mlink-schema>/mlink"
    }
  },
}

? or elsewhere?

types

skimmed the spec links, but i think that's just assigning types to other objects (e.g. assigning a node type or a value type to a jsonld object)? What i want is to define a new node type. which i guess is done just with @id as you mentioned above? or is there something else to do? (sorry if this is obvious).

What i'm modeling with mlink is a kind of link -- a merkle-link -- that means special things: merkle links are immutable, content-addressed, and therefore can be cached, replicated, and so on.

We basically will have a few different kind of links (this json-ld formulation is very new, btw so we can adjust things):

• merkle-link (abbrev mlink or m-link) will be an immutable
• self-certfied-link (abbrev slink or s-link) will be a mutable, self-certified link (the link value includes the hash of the public key, which means fetching latest values can be verified securely without trusting other parties[0].

and possibly others.

[0] except for: censorship attacks, but those are circumvented with validites (e.g. cryptographic freshness)

[jbenet]

cc @mildred

[mildred]

Edit note: in this message, RDF does not represents the XML serialization format, but the data model it represents.

I think one issue of RDF and JSON-LD is that it does not allow efficient access of the data without some database, so I don't think a JSON-LD compatible format is then suitable for IPFS. We should instead find a format that could be converted to JSON-LD by ipfs, but that could also be efficient in data access.

The main issue is that RDF lack data structures like ordered lists or indexed maps. For instance, in a RDF world, to find the file name foo.txt in a directory, you have to iterate over the unordered list of child nodes of a directory, and compare the entry name.

Why not start from the current IPFS format and add RDF from here incrementally add:

• ability to specify the RDF predicate that links the current IPFS object to the linked object (equivalent of <a rel="..." in HTML).
• ability to specify which property the link name is the value of
• ability to link without specifying a name, just with a RDF predicate
• ability to specify other properties for linked objects, relative to link

This would be the following protocol buffer definition:

// An IPFS MerkleDAG Link
message PBLink {

  // multihash of the target object
  optional bytes Hash = 1;

  // utf string name. should be unique per object
  optional string Name = 2;

  // cumulative size of target object (I would remove this one)
  optional uint64 Tsize = 3;

  // Links about the target object
  repeated PBLinkRDF TargetLinks = 4;

  // RDF predicate corresponding to the link name
  // Corresponds to the triple <target object> <this predicate> <Name>
  optional string NamePredicateUri = 5;
}

message PBLinkRDF {

  // Predicate
  string PredicateUri = 1;

  // Object
  oneof {
    bytes Hash = 2;
    string Uri = 3;
    string Literal = 4;
    uint34 IntLiteral = 5;
  }

}

// An IPFS MerkleDAG Node
message PBNode {

  // refs to other objects
  repeated PBLink NamedLinks = 2;
  repeated PBLinkRDF RDFLinks = 3;

  // opaque user data
  optional bytes Data = 1;
}

This data structure can easily be transformed to any RDF format, including JSON-LD. You don't need a context, it can be generated from the data structure. The only issue with it is that it is a little verbose. In objects of the same type, you'll repeat information. But not to repeat information requires to define a context format (I don't think we can reuse the JSON-LD context format) generic enough for all your use cases (and you don't really know them ahead of time)

I'm on IRC freenode#ipfs, don't hesitate to ping me

[kazarena]

@jbenet, as discussed by email, I'm a maintainer of https://github.com/kazarena/json-gold - full JSON-LD API implementation for Golang. I'm also an active user of JSON-LD in Go and Python. Just dropping this message in case if I can be of any help with LD design/implementation related matters.