Minutes: XDI TC Telecon Thursday 2011-10-06

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

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

Date:  Thursday, 06 October 2011 USA

Time:  1:00PM - 2:00PM Pacific Time (20:00-21:30 UTC)

ATTENDING

Bill Barnhill

Giovanni Bartolomeo

Joseph Boyle

Drummond Reed

Mike Schwartz

THE GOTOMEETING FOR TODAY IS:

     https://www2.gotomeeting.com/join/969244355

THE IDEARPAD LINK FOR TODAY IS:

     http://xdi.idearpad.org/42

Please try to preface each of your comments with your name so the

transcription into the minutes is easier.

AGENDA

1) XDI DISCOVERY PRELIMINARY SPEC

We did a more in-depth review of the preliminary spec posted at:

  http://wiki.oasis-open.org/xdi/XdiDiscovery

Bill said that he read over and feels its very simple and clear and works. 

He asked a very good question, which is why all the concrete URI literals are expressed as values in the data: URI scheme, instead of as XRI cross-refernences containing an URI.

Drummond explained that this is fundamentally a reflection of the famous "HTTP Range 14" issue that the W3C TAG has been debating for at least five years. In a nutshell, there is a very fine (but important) distinction between when a URI identifies a resource and when it identifies the location of a representation of the resource. The former you could call abstract (since it is separate from any particular represention), and the latter you could call concrete (since it must be an actual representation).

Since all XRIs are abstract identifiers of a resource, the function of XDI discovery maps from an abstract XRI to a concrete URI that identifies the location of the network endpoint for interacting with that resource using the XDI protocol. So we keep the abstract/concrete distinction very clean by specifying that the concrete URI being discovered is an XDI literal, and thus is represented (in an XDI statement) as the value of a data: URI.

Based on this understanding, Bill agreed that keeping the separation clean is worth it. 

Giovanni asked if this rule also applied to other data "strings" that can be adapted into semantic "things", for example an email address string can be turned into a mailto: URI.

Drummond agreed that it did. Bll gave an example of representing "the number 3" versus the "the value 3". The former could be represented as an XRI that has the unambiguous semantics, e.g., $a$xsd$integer!3. The latter would be expressed using a data: URI, e.g., (data:,3).

 Bill's suggested that we specify that XRI cross-references to data: URIs MUST ONLY be used to express literal values and never treated as XRIs. There was consensus that this made sense and should be included in the XDI Graph Model spec.

Bill's next point was that we need to specify exactly what the URI encoding rules are. Drummond pointed out that these are already defined in the XRI specification, which has a section specifically on encoding of either an XRI or a URI as an XRI cross-reference.

Joseph expressed that he was more worried about complexity of parsing (which can grow more than linearly) then about computational effort of the decode operation.

He agreed with Bill that we should define what subset of URLs should be allowed. (e.g. do we allow queries? or only allow XRI resolution parameters as query arguments?) This is good both to prevent us from making unwanted semantic commitments and risking incompatibility between implementations, and controlling parsing complexity.

We also talked about support for other discovery protocols. Bill made the point that if we start down the road of supporting other discovery specs, then we could be doing that for a long time. He advocated that instead we define a method for creating profiles for building "bridges"  between XDI discovery and the other discovery protocol.

Bill suggests that, based on the completeness of the XDI graph model, our position should be that any discovery spec can be mapped to XDI discovery. This is the same model that the SSTC (SAML) has taken. Thus any TC member can contribute an XDI Discovery Profile document for building a bridge, but that we don't have to say anything more than that in the XDI Discovery spec.

There was consensus that this approach made sense.

# DRUMMOND to remove the references to other discovery spec sections and replace with a short section describing the profile/bridge approach.

2) OPENXDI UPDATE

Mike reported that they finished the persitence upgrade. They are working in parallel on the OAuth component. So by month's end, the goal is to have support for all the pieces: persistence, link contracts, discovery, authentication. He is confident that it will be able to scale.

Mike just gave a presentation on XDI at the STL Partners conference, and said he had some excellent discussions there.

3) INTERNET IDENTITY WORKSHOP PREP

Mike, Drummond, and Joseph plan to attend. We will discuss prep in more detail next week.

4) NEXT CALL

The next call is next week at the regular time.

------------

ONGOING ISSUES LIST

Each of these is a candidate for the agenda for future calls.

* DO WE NEED SEPARATE METAGRAPH WORDS FOR EQUIVALENCE AND INVERSION? (added 2011-06-30 - Giovanni)

This is an open issue because algorithmic inversion does not have a direct corallary in RDF.

* SYNONYM HANDLING (added 2011-06-30 - Giovanni)

This remains an open issue because it raises challenges with compatibility with RDF.

* TRANSACTIONAL INTEGRITY FOR XDI (added 2011-03-24)

Since  versioning, as one example, involves multiple transactions that must be  commited as a group, we will need to address transactional integrity.  Specifically, we need to define how this will be handled at the protocol  level, vs. the implementation level.

* PROPOSED CONSTRUCTS/OPERATORS FOR XDI

Discuss the following wiki page originally posted by Giovanni:

  http://wiki.oasis-open.org/xdi/XdiNewFoundation

* DICTIONARY STRUCTURE

Mike would like an example of the PDX dictionary as soon as we can do it.

*   EQUIVALENCE SEMANTICS

Close on whether we need an additional $ word that is the equivalent

of Higgins Personal Data Model (PDM)  semantics of h:correlation,

which is not as strong as $is.

      http://lists.oasis-open.org/archives/xdi/201006/msg00036.html

* COOL URIS

Continue previous discussion about the use of standard RDF URIs in XDI:

  http://lists.oasis-open.org/archives/xdi/201006/msg00023.html