OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xdi message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: XDI TC Unofficial Telecon Notes: Tuesday 2016-12-06


XDI TC Notes


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

Date: Tuesday, 06 December 2016 USA
Time: 9:00AM - 10:00AM 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

Markus Sabadello
Drummond Reed
Joseph Boyle
Phil Windley
Les Chasen

NOTES

XDI Link Contracts

Drummond explained that he has been involved in discussions revealing a certain technological tension between the JSON tree data model and the the JSON-LD (RDF) graph data model. In the Verifiable Claims Task Force (VCTF) and the associated Linked Data Signatures work, there is a need to canonicalize RDF data independently of any particular serialization. This is a complex procedure in a graph data model that doesn't have hierarchies.


Drummond also explained that there is increasing interest in link contracts (e.g. by participants in the Sovrin Foundation), and that link contracts take full advantage of the XDI semantic tree structure.


Markus agreed that certain parts of XDI may have more applicability early on than other parts, and that that advantages of the semantic tree model become especially clear when it gets into the requirements of link contracts.  


Markus said that the XDI Link Contract spec is largely dependent just on Core, so we should be able to advance it quickly.


Markus explained the potential interest of Æternum (a French "association") and Ævatar (a French "cooperative") working on self-sovereign identity and privacy-protected data exchange. They are very interested in XDI as a protocol for interoperability. They are interested in both the messaging piece and the link contract piece. And they are interested in joining the TC.


Drummond proposed that, particularly if these new members join for this purpose, we should begin to prioritize the link contract spec. Markus pointed out that the link contract spec has not been published yet, and agreed to push it forward.


# ALL - Review the current draft of the Link Contract spec at http://xdi.org/xdi-spec-docbook/xdi/xdi-link-contracts-1.0/xdi-link-contracts-1.0-wd01.xml.


# MARKUS will publish the first draft of the Link Contract spec before next week’s call.

Adding a Fifth Instance Type: “Undefined”

XDI Core 1.0 Committee Draft 01 currently defines four entity instance types (section 4.2):

  1. Person

  2. Group

  3. Thing

  4. Ordinal (number)


Note that these four categories of entities are completely disjoint, i.e., it is semantically invalid for an XDI entity of one of these types to have an equivalence relation to an XDI entity of a different type.


As Drummond has studied new use cases in connecting XDI to legacy systems as well as to entities identified in RDF graphs, it has emerged that there are many cases where the XDI type of an entity is unknown or undefined, at least at the time of initial integration. Yet such an XDI entity still needs to be identified with an XDI address.


In addition, the entity type may emerge over time, and thus a node established prior to the knowing the type needs to be able to have an equivalence statement to a node created before the type was known.


Therefore Drummond proposed to create a fifth entity type, “Unknown” or “Undefined”:


Markus explained that he has encountered the same issue in terms of modeling how a DID (decentralized identifier) that does not yet have a known type should be translated into an XDI address. We partially discussed this topic on a recent XDI TC call, see the notes here:
https://lists.oasis-open.org/archives/xdi/201611/msg00002.html


Markus said that he’s been intuitively treating an unknown entity type as a “thing” with a * context symbol. He pointed out in RDF OWL that every resource is an instance of “owl:Thing”. Every class is also a subclass of "owl:Thing". Drummond explained that an XDI "thing" is different from an "owl:Thing", insofar as the latter includes every resource of any type, whereas the former e.g. does not include individuals and organizations.


Phil suggested that the best semantic defintion for this new entity type is actually “Any”. He said that mixing set theory and type theory can be tricky, and that it is best to treat this as type theory. Using that approach, all the other XDI entity types (person, group, thing, ordinal) would be subtypes of the supertype “any”.


Markus asked how a DID (Decentralized Identifier) would be cast as an XDI address. Drummond proposed that DIDs should become an XDI scheme, and that any DID could then be semantically typed with an XDI context symbol. If the type is not known, then the context symbol would be ^ for Any.


did:sov:38hoa8349hahdfakdf9

^!:did:sov:38hoa8349hahdfakdf9


Markus brought up the issue that it complicates the implementations of XDI graphs if you have to establish an equivalence relation between an Any DID and a DID for a particular entity type, e.g. if you establish a link contract using an Any DID, and later learn the actual type of that DID is a person.

Example:

^!:did:sov:38hoa8349hahdfakdf9/$ref/=!:did:sov:38hoa8349hahdfakdf9


Drummond agreed that it would better to never need the Any node in the XDI graph if you don’t have to have it. However Markus pointed out that if you already have a typed DID in an XDI address (which should be the case most of the time), you will not need a node with the Any type.

Les agreed that there are many reasons that a XDI author may not want to share what type an entity is. He said he would prefer to be able to have the Any type not require any context symbol at all, but that does create a syntax parsing issue, so he supports this proposal.


NEXT REGULAR CALL

The next call will be the following week at the usual 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





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]