[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes: XDI TC Telecon Friday 2013-04-12
Following are the minutes of the unofficial telecon of the XDI TC at:
Date: Friday, 12 April 2013 USA
Time: 09:00AM - 10:30AM Pacific Time (16:00-17:30 UTC)
Drummond noted that more XDI-related sessions are planned for the upcoming Internet Identity Workshop May 7-9 in Mountain View than ever before. It remains a priority of the TC to prepare as much documentation as we can -- whether on the wiki or on posted Kavi docs -- before the workshop.
This week's decision queue is the following set of proposals:
This complete parse tree of the XDI graph model was developed by Drummond and Markus this week to fully separate the questions of semantic modelling requirements and syntax assignments:
Drummond has also prepared (but not fully debugged) an ABNF that reflects this model:
https://wiki.oasis-open.org/xdi/XdiAbnf/Discussion (see 2013-04-11 comment)
We reviewed the model on the call in order to make sure there was consensus as it provides the framework we need to close on syntax assigment.
First, Markus pointed out that subsections of the model are actually multi-dimensional and there are several ways to arrange the dimension. He illustrated these on:
We then discussed the two most frequently asked questions about the model:
Why does it need to distinguish between a Singleton and a Class/instance?
Why does it need to distinguish between an Entity and an Attribute?
On the first question, Drummond explained that the difference between a Singleton and a Class/Instance pair is:
A singleton is both a class and an instance.
A singleton requires only one graph node; a class/instance pair requires two.
Because a singleton does not have instances, instance identification and ordering rules do not apply.
On the second question, the “bright line” difference between an Entity and Attribute is that the latter MAY have a value but the former MUST NOT have a value. This distinction is best understood by reference to the Entity-Attribute-Value model:
Drummond explained that this distinction is important for two reasons:
Different sets of definitional rules apply to entities and attributes in a dictionary context.
A single semantic identifier representing a single concept can be defined to serve as both an entity and an attribute, a pattern very common in natural language. For example, “email” can be both an attribute (“Drummond’s email”) and an entity (send me an email, email server). This promotes interoperability.
It was agreed that these distinctions are so important that we need to explain them both on the wiki and in the XDI Graph Model spec.
# DRUMMOND to work on a wiki FAQ answering common questions about the XDI Graph Model.
Les asked about why instances needed separate identification from classes in the model. This is for addressability—although any class can have an instance, in the XDI graph instances to be both addressable and semantically distinct. Thus we need a class of instance identifiers that serve that purpose.
Phil shared the view that while the model is very important, the only requirement in actually imposes on syntax is that the syntax enable expressions to be unambiguously translated into the model. It does not require that the syntax of the language directly follow the structure of the model.
Drummond created a wiki page for posting and comparing syntax examples:
Since, as Phil said, any syntax that can be losslessly mapped to the graph model will work, the purpose of this page is just to compare different options so TC members can reach consensus on what is ultimately a subjective choice about readability.
We reviewed the three assumptions made on the page:
We don't want to change any of the six base context symbols that we have been using since 2004 (=, @, $, +, *, !).
We don't want to use a special context symbol for entities (the equivalent of English language nouns).
Parsing and serialization will be easier if we use single symbol characters to indicate node types (vs. bracketed delimiters).
Joseph reinforced that using single characters will make parsing easier. He also raised the possibility that characters could postpend identifiers, however this may make parsing more difficult.
We then discussed TC member preferences for symbol characters and symbol ordering.
With regard to characters, there was concensus among those still on the call (Phil had to leave the call before this discussion) on three of the five choices, all of which came out of the email dialog with Joseph:
Colon for literal contexts.
Hash for ordered instances (array index).
Percent for dictionary contexts.
That leaves two more: attribute contexts and singleton contexts.
Discussion narrowed down the choices to:
Ampersand for attributes and pipe for singletons.
Semicolon for attributes and comma for singletons.
Markus has a medium strong preference for the first option because he feels comma and semicolon read more like separators, and also because although comma and semicolon are related grammatically, attributes and singletons are not.
Animesh, Joseph, and Drummond had a preference for the second option. Les did not have a preference yet.
With regard to symbol ordering:
Animesh likes the order of major concept symbol first, then minor ones (major being the six base context symbols).
Joseph has a weak preference for the major context symbol coming last.
Markus has a strong preference for the major context symbol coming first, singleton coming second, and attribute third.
Drummond has a strong preference for minor-to-major, i.e., singleton first, attribute second, major context symbol last.
Les does not have a preference in terms of order.
All TC members agreed that in the case of dictionary definitions, % should come first.
At that point we ran out of time. Since we don’t have consensus yet, Drummond took the following action item:
# DRUMMOND to post the remaining choices to the wiki and the list with the goal of arriving at a consensus by Monday.
The decision queue stack is shown on the following three auto-generated Category pages:
See also this list of proposals that need to be developed:
The next call is next week at the regular time.