Fwd: [xdi] New XDI JSON serialization format that *does not require a se

Subject: Fwd: [xdi] New XDI JSON serialization format that *does not require a separate display format*

Forwarding Joseph's message to the TC list since apparently it didn't arrive there.

---------- Forwarded message ----------
From: Joseph Boyle <boyle.joseph@gmail.com>
Date: Fri, Jan 30, 2015 at 5:27 PM
Subject: Re: [xdi] New XDI JSON serialization format that *does not require a separate display format*
To: Drummond Reed <drummond.reed@xdi.org>, Markus Sabadello <markus.sabadello@xdi.org>, Peter Davis <Peter.Davis@neustar.biz>, Les Chasen <les.chasen@neustar.biz>
Cc: OASIS - XDI TC <xdi@lists.oasis-open.org>

Drummond, here are my thoughts so far:

Separating subject, predicate, and object instead of putting subject/predicate together is intuitive and a great idea and may simplify some code.

It doesn't cover inner root in subject, which is the hard case for any serialization format and which we use heavily in messaging.

The notation we’ve been using changes statement syntax radically when reified. I would much prefer to represent a statement that has inner root in subject as an explicit 5-tuple which would simplify this.

“Triples format” is not the most intuitive name - it makes you expect something like this with each triple in a distinct structure:

[

[subj1, pred1, obj1],

[subj2, pred2, obj2],

…

What you’re suggesting is more of a tree format. We’ve talked about a “tree serialization” previously, which is a tree in another sense, reproducing the context node tree. Your new proposal is a tree in the sense of consolidating same-subject and then same-predicate, which is also done in RDF/JSON.

RDF/JSON http://www.w3.org/TR/rdf-json/ has a very similar idea of nesting 3 levels for S/P/O, although below those 3 levels it parts company: the object of a triple is a key-value list, while we use a single string.

If it’s this close, we should consider feasibility of actual compatibility with RDF/JSON, especially if that format has some traction.

Your proposed value statement is “subject”: { “&”: “value”}. Note { “subject”: “value” } is what all JSON programmers are used to for value statements, which is a pair not a triple, but supporting this would boost compatibility with existing software.

I like that your proposal almost completely eliminates use of slash ‘/‘ as delimiter between subject / predicate / object, which gets rid of a syntax unintuitive for the uninitiated, since RDF doesn’t use slash, and filesystem or http addresses use it differently as a part separator within an address. It would also free up the slash for potential other use.

(The exception is it uses “/“ as serialization of the contextual predicate, which would now be an isolated usage. The contextual predicate has been empty string, and JSON actually does allow empty string as key. Also I think it is worth questioning whether contextual statements ever really need to be serialized - we have been including them mostly to maintain a formal equivalence between each context node and a corresponding statement. In my view simply stating an address implies that all of its intermediate context nodes exist.)

I think MUST is overused - it's for constraints between previously defined objects, not for primary definitions.

On Jan 27, 2015, at 12:17 AM, =Drummond Reed <drummond.reed@xdi.org> wrote:

While working on the "How XDI Builds on RDF" paper, I have been thinking about conventional RDF triples so much that a simple thought occurred to me: "Why does XDI flat serialization format need to repeat the XDI subject for every subject/predicate key?"

The answer, of course, is that in the flat serialization format, the subject/predicate combo provides the unique key for every XDI object. So for key/value stores, it makes sense to serialize it that way.

But I wondered what it would look like if we broke apart the XDI subject and XDI predicate so that each unique XDI subject appeared exactly once under any XDI root node—just like each predicate appears once under a subject and each object appears once under a predicate in the flat serialization format.

A hour of playing this weekend and voila, JSON triples format was born. What I didn't expect was that the result would make the triples so readable in the native JSON that IMHO we would no longer need a separate display format—except for special cases where you want to drop all the JSON delimiters and extra lines.

To be specific, if we adopt this as our default serialization format, then I would propose that all of the examples in the XDI 1.0 specs just use JSON triples format. No need to repeat them in a separate display format—it would just confuse readers.

Take a look yourself at these examples below. To make it easy, I've highlighted a first-level inner graph (a simple link contract) in blue and a second-level inner graph (a policy _expression_) in red.

See additional details and benefits in the writeup on this wiki page.

=Drummond

JSON TRIPLES FORMAT EXAMPLE

{
"=drummond[<#email>]!0": {
"&": "drummond@example.com"
},
"=drummond[<#email>]!1": {
"&": "dsr@example.net"
},
"=drummond<#email>": {
"$ref": [
"=drummond{<#email>]!0"
]
},
"=drummond<#home><#email>": {
"$ref": [
"=drummond{<#email>]!1"
]
},
"=drummond<#work><#email>": {
"$ref": [
"=drummond{<#email>]!1"
]
},
"=drummond": {
"#spouse": [
"=monique.reed"
],
"#friend": [
"=markus",
"=joseph.boyle",
{
"+respect#card$do": {
"$get": [
"=drummond<#home><#email>"
]
},
"+respect#card$do$if": {
"$true": [
{
"{from}": {
"$is#friend": [
"=drummond"
]
}
}
]
}
}
]
}
}

TRIPLES DISPLAY FORMAT EXAMPLE (same graph as above)

=drummond[<#email>]!0
&
"drummond@example.com"
=drummond[<#email>]!1
&
"dsr@example.net"
=drummond<#email>
$ref
=drummond{<#email>]!0
=drummond<#home><#email>
$ref
=drummond{<#email>]!1
=drummond<#work><#email>
$ref
=drummond{<#email>]!1
=drummond
#spouse
=monique.reed
#friend
=markus
=joseph.boyle
{
+respect#card$do
$get
=drummond<#home><#email>
+respect#card$do$if
$true
{
{from}
$is#friend
=drummond

xdi message