Re: [xdi] XDI TC Telecon Friday 2014-01-10

[Drummond Reed <drummond.reed@xdi.org>]

Markus, given that I was not able to attend, I just want to commend you for an excellent set of minutes. They communicated a great deal of information and did it very economically.

I look forward to next Friday's call.

=Drummond 

On Fri, Jan 10, 2014 at 11:04 PM, Markus Sabadello <markus.sabadello@xdi.org> wrote:

XDI TC Minutes

Following are the minutes of the unofficial telecon of the XDI TC at:

Date:  Friday, 10 January 2014 USA
Time:  09:00AM - 10:30AM Pacific Time (16:00-17:30 UTC)

ATTENDING

Markus Sabadello
Dan Blum
Andy Dale
Les Chasen

REGRETS

Drummond Reed

AGENDA

NEWS & UPDATES

XDI Tutorial

Dan and Markus went over the XDI Tutorial Markus published earlier this week:

http://tutorial.xdi.org/

Dan commented that it was very helpful, and he offered some feedback. One improvement would be to add a cover slide in the beginning, and a few more introductory words about the high-level vision behind XDI, and about what problems it is intended to solve.

PRESENTATIONS/DISCUSSIONS

Next Steps on Working Drafts

We did not talk about this topic.

“Membership” Statements

Drummond and Markus have worked more on how to express membership of an individual with an organization, including information such as a membership number, membership expiration date, and premium memberships

EXAMPLE:

WHO IS A MEMBER OF 0000?

[@]!:uuid:0000/+member/[=]!:uuid:1111

[@]!:uuid:0000/+member/[=]!:uuid:2222

[@]!:uuid:0000/+member/[=]!:uuid:3333

[@]!:uuid:0000/+member/[=]!:uuid:4444

[@]!:uuid:0000/+member/[=]!:uuid:5555

WHAT ORGs IS 1111 A MEMBER OF?

IS 1111 A MEMBER OF 0000?

[=]!:uuid:1111/$is+member/[@]!:uuid:0000

WHAT IS 1111’s MEMBERSHIP NUMBER?

[@]!:uuid:0000/+member/([=]!:uuid:1111<+member>&/&/0)

WHO IS MEMBER NUMBER 0?

[@]!:uuid:0000[+member]#0/$is/[=]!:uuid:1111

WHAT IS THE MEMBERSHIP REGISTRATION TIME?

[@]!:uuid:0000/+member/([=]!:uuid:1111<+registration><$t>&/&/"2014-01-01T12:00:00Z")

WHAT IS THE MEMBERSHIP EXPIRATION TIME?

[@]!:uuid:0000/+member/([=]!:uuid:1111<+expiration><$t>&/&/"2015-01-01T12:00:00Z")

We agreed that there is a lot of redundancy in these statements. The reason for this is that it makes it possible to answer a range of different questions (see above). We agreed that if XDI had more advanced querying mechanisms than just the simple $get operation, then maybe some of the redundant statements would not be needed.

This resulted in a longer discussion about different conceptual approaches to storing data in an XDI graph so that it can be queried in a number of different ways.

Approach #1: Many statements. This is basically the above approach where multiple (partially redundant) statements are used to express a membership relation.

Approach #2: Few statements and query language. With this approach, only a minimal amount of statements would be included in the XDI graph, and a more advanced query language would be invented that can retrieve data in a number of different ways.

Approach #3: Automatic indices. This could be a variation of either approach #1 or approach #2, and the XDI server would automatically create indices of context nodes in the graph that might at some point become the target of a query.

The above example of membership information also reminded us of a use case Animesh had presented a few weeks ago, in which one may want to filter a large collection of e-mails in a graph in a number of different ways (e.g. to just retrieve “important” ones). This would again involve storing additional statements, in this case a collection of “important” e-mails which would link to the “main” collection using $ref  arcs:

 =markus[+email]!:uuid:1234<+subject>
 =markus[+email]!:uuid:1234<+body>
 =markus[+email]!:uuid:2345<+subject>
 =markus[+email]!:uuid:2345<+body>
 =markus[+email]!:uuid:5678<+subject>
 =markus[+email]!:uuid:5678<+body>
 =markus[+email]!:uuid:5678<+important>&/&/true
 =markus+important[+email]!:uuid:8746/$ref/=markus[+email]!:uuid:5678

Another insight we had was that with our current XDI operations, sequential numbering (e.g. of instances in a collection) is not trivial to do, since XDI servers do not have built-in support for sequences. Therefore the responsibility of maintaining a correct sequence number would lie within the responsibility of XDI clients, and race conditions and inconsistencies may occur.

In many use cases however it seems that instead of sequential numbering, one could add timestamps to instances of a collection, which would achieve a similar effect.

Boolean and Integer Results for $get Operations

We discussed a variation of the $get operation that would not return the actual results from the XDI graph, but instead:

• $get$boolean: Return either true or false, depending on whether there are any results or not

• $get$int: Return the number of result statements

Authority-Relative Link Contracts

We reviewed updates to the link contract patterns to ensure that link contracts are authority-relative:

  https://wiki.oasis-open.org/xdi/LinkContractPattern

We did a quick example of the “old” and “new” link contract patterns:

GENERIC LINK CONTRACT:

  =alice$to@acmebread$from+newsletter$do

ROOT LINK CONTRACT:

  OLD:  $do
  NEW:  =alice$to=alice$from$do

PUBLIC LINK CONTRACT:

  OLD:  $public$do
  NEW:  =alice$to$anon$from$public$do

The “Unauthorized $ref Problem” and “Unbounded $set Problem”

We again failed to clearly formulate a detailed solution to these two problems, but we recalled some of the earlier considerations and specifically had the following thoughts:

• With the introduction of authority-relative link contracts, these problems seem to be easier to solve, since there is now a notion of $ref arcs that “cross authorities” and $ref arcs that do not.

• We recalled that the solution to these problems probably in some way involves specializations of the $set permission such as $set{$ref}. Andy added that in previous generations of XDI, there also used to be specialized permissions such as $set$literal, which would allow the manipulation of literal values, but not any structural changes to the graph.

“Forwarding” of Messages by a Server

We did not discuss this topic.

DECISION POINTS FOR THIS CALL

None scheduled.

DECISION POINT QUEUE REVIEW

The decision queue stack is shown on the following three auto-generated Category pages:

  https://wiki.oasis-open.org/xdi/CategoryLastCall

  https://wiki.oasis-open.org/xdi/CategoryCurrent

  https://wiki.oasis-open.org/xdi/CategoryHighPriority

See also this list of proposals that need to be developed:

  https://wiki.oasis-open.org/xdi/XdiPendingIssues

NEXT CALL

The next call is next week at the regular time.