Re: [xdi] XDI TC Notes Unofficial Telecon Monday 2016-09-12

[Markus Sabadello <markus.sabadello@xdi.org>]

On 09/14/2016 10:26 AM, =Drummond Reed wrote:

Markus, I just want to commend you on a great set of minutes. I know your connection was having trouble during the telecon, but the examples you provided in the minutes do a superb job of illustrating the options we have for JXD.

I especially appreciate the highlighting you provided to make it clear what the differences are.

I have my own thoughts about which options I prefer, but before I say anything more, let me ask you two questions to test my understanding:

1. Would it be correct to say that all of the options you display, including the combinations, reproduce the same "raw" or underlying XDI graph?

Not in this specific set of examples, because I actually used slightly different XDI graphs to illustrate the different options.
But yes, it would be possible to come up with one example that could be serialized using any of the options, or various combinations of the options, and the underlying XDI graph would always be the same.

1. If so, would you agree that the primary decision we need to make about JXD is which of these mapping rules to support in the spec, including potentially all of them?

I thought all of them should be equally supported to give developers freedom to write the JXD in whichever way is most intuitive.
JSON-LD also supports many abbreviations and patterns (expanded, compacted, flattened, framed) to serialize the same graph.

On Tue, Sep 13, 2016 at 11:15 AM, Markus Sabadello <markus.sabadello@xdi.org> wrote:

XDI TC Notes

Following are the notes of the unofficial telecon of the XDI TC held on:

Date: Monday, 12 September 2016 USA
Time: 10:00AM - 11:30AM Pacific Time (17:00-18:30 UTC)

The TC operates under a standing rule approved 17 July 2008 under which the TC does not hold regular official meetings and conducts all business by electronic ballot only. Unofficial weekly meetings are held to enable discussion among members but no business is conducted nor actions taken.

ATTENDING

Drummond Reed
Markus Sabadello
Les Chasen
Joseph Boyle

REGRETS

Phil Windley

NOTES

Moving the Weekly Telecon to a Different Day

We moved the call to Mondays to avoid Markus having to do the call on a Friday night. However Mondays are proving to be challenging due to the start-of-week challenges. So we will discuss:

• Moving the call to a different day.

• Officially setting it to one hour (vs. the current 90 mins)

The decision was to move the call to 9AM PT on Tuesdays provided that time works for Phil.

# ACTION: DRUMMOND to move call after verifying with Phil.

JXD

For several reasons, developing a developer-friendly format for XDI graphs is now our highest priority. Per our earlier discussions on this topic, the goal of the proposed JXD format is to do for the XDI graph model what JSON-LD did for the RDF graph model.

https://wiki.oasis-open.org/xdi/JsonXdiMapping
https://wiki.oasis-open.org/xdi/JsonXdiMapping/Discussion

On this call the goal is to:

1. Discuss how to express context, peer roots, and inner roots in JXD format

2. Discuss any open issues with developing the JXD format

3. Decide if it should be incorporated into XDI Core or a separate spec

4. Agree on a workplan to produce the spec

We started with a simple JXD example that involves only one level of XDI entity and one level of XDI attributes:

=markus<#name>/&/"Markus"

=markus<#email>/&/"markus@danubetech.com"

=markus/#friend/=drummond

{

 "@xdi": {

    "name": "<#name>",

    "email": "<#email>",

    "friend": {

      "@id": "#friend",

      "@type": "@id"

    }

 },

 "@id": "=markus",

 "name": "Markus",

 "email": "markus@danubetech.com",

 "friend": [ "=drummond" ]

}

We then discussed different options to model XDI context in JXD. All options would be equally valid and supported by JXD. All options use the @id keyword to describe the XDI (sub-)context corresponding to the current JSON object.

Option #1: Nest JSON objects to mirror the XDI context tree

This option uses the special JSON object key () to express an XDI sub-context as a nested JSON object:

+danubetech=markus<#name>/&/"Markus"

+danubetech=markus<#email>/&/"markus@danubetech.com"    +danubetech=markus/#friend/=drummond

{

 "@xdi": {

    "name": "<#name>",

    "email": "<#email>",

    "friend": {

      "@id": "#friend",

      "@type": "@id"

    }

 },

 "@id": "+danubetech",

 "()": {

    "@id": "=markus",

    "name": "Markus",

    "email": "markus@danubetech.com",

    "friend": [ "=drummond" ]

 }

}

An alternative may also be to use the address of the XDI sub-context as the JSON object key instead of ():

{

 "@xdi": {

    "name": "<#name>",

    "email": "<#email>",

    "friend": {

      "@id": "#friend",

      "@type": "@id"

    }

 },

 "@id": "+danubetech",

 "=markus": {

    "name": "Markus",

    "email": "markus@danubetech.com",

    "friend": [ "=drummond" ]

 }

}

Pro: Avoids the () keyword. Has similarities to JSON-LD's "embedding" feature.
Con: Avoids the @id keyword. Also, XDI addresses may appear as both keys and values in JSON object, this may be confusing.

Option #2: Collapse multiple sub-contexts in the @id keyword

This option uses XDI addresses consisting of multiple sub-contexts in the @id keyword.

+danubetech=markus<#email>/&/"markus@danubetech.com"    +danubetech=markus<#name>/&/"Markus"

+danubetech=markus/#friend/=drummond

{

 "@xdi": {

    "name": "<#name>",

    "email": "<#email>",

    "friend": {

      "@id": "#friend",

      "@type": "@id"

    }

 },

 "@id": "+danubetech=markus",

 "name": "Markus",

 "email": "markus@danubetech.com",

 "friend": [ "=drummond" ]

}

Option #3: Collapse multiple sub-contexts in term definitions

This option uses XDI addresses consisting of multiple sub-contexts in the term definitions.

=markus<#work><#name>/&/"Markus"

=markus<#work><#email>/&/"markus@danubetech.com"

=markus/#friend/=drummond

{

 "@xdi": {

    "name": "<#work><#name>",

    "email": "<#work><#email>",

    "friend": {

      "@id": "#friend",

      "@type": "@id"

    }

 },

 "@id": "=markus",

 "name": "Markus",

 "email": "markus@danubetech.com",

 "friend": [ "=drummond" ]

}

Options #1 + #3 combined:

+danubetech=markus<#work><#name>/&/"Markus"

+danubetech=markus<#work><#email>/&/"markus@danubetech.com"

+danubetech=markus/#friend/=drummond

{

 "@xdi": {

    "name": "<#work><#name>",

    "email": "<#work><#email>",

    "friend": {

     "@id": "#friend",

     "@type": "@id"

    }

 },

 "@id": "+danubetech",

 "()": {

    "@id": "=markus",

    "name": "Markus",

    "email": "markus@danubetech.com",

    "friend": [ "=drummond" ]

 }

}

Options #2 + #3 combined:

+danubetech=markus<#work><#name>/&/"Markus"

+danubetech=markus<#work><#email>/&/"markus@danubetech.com"

+danubetech=markus/#friend/=drummond

{

 "@xdi": {

    "name": "<#work><#name>",

    "email": "<#work><#email>",

    "friend": {

     "@id": "#friend",

     "@type": "@id"

    }

 },

 "@id": "+danubetech=markus",

 "name": "Markus",

 "email": "markus@danubetech.com",

 "friend": [ "=drummond" ]

}

We then had a short discussion about how to map other key XDI constructs, e.g., peer graphs and inner graphs. Markus said he felt that peer roots could be treated like any other JXD context mapping. In theory, so can inner roots, but his sense was that inner roots could use a more intuitive mapping structure. Drummond agreed, and said he thought the structure should separate the subject and the predicate of the inner root into two JXD keywords.

His suggestion is @id for the subject of the inner root and @rel for the predicate (relation) of the inner root. Then the body is an array of JSON objects, each of which represents an XDI context within the inner graph.

#ACTION: MARKUS to document the different JXD mapping patterns he has been exploring on the Json XDI Mapping Discussions page.

Drummond then shared some thoughts he had about naming JSON serialization formats. In the XDI Core 1.0 spec, we define only one JSON serialization format, so there was no need to give it a special name (we also did not define a proposed file extension, though an obvious one would be .xdi).

However when we introduce the JXD format, it requires differentiation between the formats. Drummond suggested that we could use three format names:

1. JXD (JSON XDI Data)—the format we are defining inspired by JSON-LD.

2. JXM (JSON XDI Mapping)—a JXD file constrained to ONLY containing an @xdi map.

3. JXR (JSON XDI REAL or JSON XDI Raw)—the standard 4-level Root/Entity/Attribute/Literal serialization defined in XDI Core 1.0.

Note that the second one, JXM, is not strictly necessary, as it is actually a JXD file with a specific constraint. So we could also have just two formats, JXD and JXR.

NEXT REGULAR CALL

The next call will be the following week at the NEW time (Tuesday 9AM PT). The link to where agenda items can be posted for the next meeting is: https://docs.google.com/document/d/19oDl0lbb56Grehx2a5flZnhrgnua5l8cVvC_dJ8fTXk/edit?usp=sharing