[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes: XDI TC Telecon Friday 2013-12-20
Following are the minutes of the unofficial telecon of the XDI TC at:
Date: Friday, 20 December 2013 USA
Time: 09:00AM - 10:30AM Pacific Time (16:00-17:30 UTC)
Markus Sabadello
Drummond Reed
Joseph Boyle
Phil Windley
None scheduled.
Markus and Drummond said that they had reviewed updates to the link contract patterns to ensure that link contracts are authority-relative. These updates are now shown at:
https://wiki.oasis-open.org/xdi/LinkContractPattern
We discussed link contract terminology and agreed to use the term “authority” in place of “party”.
# DRUMMOND to update the terminology on the wiki page.
# DRUMMOND OR MARKUS: Update the examples at the end of the page.
We briefly discussed the additions/corrections we want to make to produce XDI Core 1.0 Working Draft 02, including:
MIME types for serialization formats.
Formatting improvements.
Adding missing sections, including:
XDI operators
Equivalence relations
Improved Github merging process.
One open issue is that we need to review the list of predicates.
# JOSEPH AND DRUMMOND AND MARKUS: Do a draft of the Predicate Grammar section.
# DRUMMOND AND JOSEPH: Review spec for additional sections and compose issues list on the TC wiki.
Joseph cited the following in an email to the list:
https://mail.mozilla.org/pipermail/es-discuss/2013-December/035126.html
He explains:
This provides the term "static semantic rule" to describe non-ABNF rules such as:
the subject and object of a contextual statement must yield a valid XDI address when concatenated by removing the // between them
a statement whose object is parentheses enclosing a syntactically valid XDI statement, is semantically equivalent to a rearranged statement using inner roots
The first does restrict the set of syntactically valid XDI statements, even though it is called a semantic rule. The second does not reduce the set of all valid XDI statements, or could be viewed as increasing it from a more basic smaller set not allowing triples in parentheses as objects.
The mail gives ignoring insignificant whitespace as another example of a static semantic rule, which could alternatively be implemented using syntax diagrams ("racetrack diagrams", which are equivalent to BNF). In the XDI case we have never attempted to add it to the ABNF, but have always had it as a static semantic rule external to the ABNF.
We agreed that this same approach can apply to rules we define in XDI Core 1.0.
Drummond ran across the question: what’s the best way to express membership of one entity in another entity (such as an individual being a member of an organization) in the XDI graph model?
He proposed the following two options to discuss on the call:
Note that the following examples use shortened UUIDs for readablity.
1A [=]!:uuid:1/$is+member/[@]!:uuid:2
1B [@]!:uuid:2/+member/[=]!:uuid:1
Note that 1B could also be represented as an inner graph:
([@]!:uuid:2/+member)[=]!:uuid:1
2A [=]!:uuid:1/$is()/[@]!:uuid:2
2B [@]!:uuid:2//[=]!:uuid:1
This second approach uses XDI contextual statement with the implication that a subcontext is a "member" of a supercontext. That results in a new XDI address:
[@]!:uuid:2[=]!:uuid:1
Markus said he would recommend the first one since it has a clean semantics that is not overloaded with other potential meanings.
Drummond then asked how to best model a membership number, i.e., an attribute of a membership relationship. As we discussed that challenge, we added a third option:
OPTION #3: Collection/Member statements
3A [@]!:uuid:2[+member]#0/$is/[=]!:uuid:1
This option reflects the use of our standard collection/member pattern to enumerate ordered members of a “+member” collection.
In this discussion, we realized that no single one of these patterns captures all the necessary semantics. In fact it takes a combination of several of them to do that. However this combination provides precises semantics for most typical queries about membership and membership numbers. We wrote up the following combination of patterns that make it possible to query the membership graph data in various ways:
IS 1111 A MEMBER OF 9999 ?
WHAT IS THE LIST OF MEMBERS OF 9999 ?
[=]!:uuid:1111/$is+member/[@]!:uuid:9999
[@]!:uuid:9999/+member/[=]!:uuid:1111
WHAT IS 1111's MEMBER NUMBER ?
[@]!:uuid:9999/+member/([=]!:uuid:1111<+member>&/&/0)
([@]!:uuid:9999/+member)[=]!:uuid:1111<+member>&/&/0
WHO IS THE MEMBER WITH MEMBER NUMBER 0 ?
[@]!:uuid:9999[+member]#0/$is/[=]!:uuid:1111
As a final note, we realized that we’ve never needed to diagram nested inner graphs, i.e., inner graphs that nest to more than one level. Drummond suggested that this would best be done by consecutive inner root nodes, i.e., drawing the diagram to correspond to this version of the XDI address:
(@a/+member)(@b/+member)=c<+member>&/&/0
None scheduled.
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
We will take a break for the holidays. Our next call with be Friday January 3 at the regular time (9AM PT).
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]