Next in thread →
Next in month →
Re: [xdi] XDI TC Notes Unofficial Telecon Monday 2016-09-12
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:
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.
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 <>
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:
Discuss
how to express context, peer roots, and inner
roots in JXD format
Discuss
any open issues with developing the JXD format
Decide
if it should be incorporated into XDI Core or a
separate spec
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/#friend/=drummond
{
"@xdi": {
"name":
"<#name>",
"email":
"<#email>",
"friend":
{
"@id": "#friend",
"@type": "@id"
}
},
"@id": "=markus",
"name": "Markus",
"email": "",
"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>/&/""
+danubetech=markus/#friend/=drummond
{
"@xdi": {
"name":
"<#name>",
"email":
"<#email>",
"friend":
{
"@id": "#friend",
"@type": "@id"
}
},
"@id":
"+danubetech",
"()": {
"@id":
"=markus",
"name":
"Markus",
"email":
"",
"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":
"",
"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>/&/""
+danubetech=markus<#name>/&/"Markus"
+danubetech=markus/#friend/=drummond
{
"@xdi": {
"name":
"<#name>",
"email":
"<#email>",
"friend":
{
"@id": "#friend",
"@type": "@id"
}
},
"@id":
"+danubetech=markus",
"name": "Markus",
"email": "",
"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/#friend/=drummond
{
"@xdi": {
"name":
"<#work><#name>",
"email":
"<#work><#email>",
"friend":
{
"@id": "#friend",
"@type": "@id"
}
},
"@id": "=markus",
"name": "Markus",
"email": "",
"friend": [ "=drummond" ]
}
Options
#1 + #3 combined:
+danubetech=markus<#work><#name>/&/"Markus"
+danubetech=markus<#work><#email>/&/""
+danubetech=markus/#friend/=drummond
{
"@xdi": {
"name":
"<#work><#name>",
"email":
"<#work><#email>",
"friend":
{
"@id":
"#friend",
"@type":
"@id"
}
},
"@id": "+danubetech",
"()": {
"@id":
"=markus",
"name":
"Markus",
"email":
"",
"friend":
[ "=drummond" ]
}
}
Options
#2 + #3 combined:
+danubetech=markus<#work><#name>/&/"Markus"
+danubetech=markus<#work><#email>/&/""
+danubetech=markus/#friend/=drummond
{
"@xdi": {
"name":
"<#work><#name>",
"email":
"<#work><#email>",
"friend":
{
"@id":
"#friend",
"@type":
"@id"
}
},
"@id": "+danubetech=markus",
"name": "Markus",
"email": "",
"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:
JXD
(JSON XDI Data)—the format we are defining
inspired by JSON-LD.
JXM
(JSON XDI Mapping)—a JXD file constrained to ONLY
containing an @xdi map.
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
Next in thread →
Next in month →