← Prev in month ← Prev in thread
Next in thread → Next in month →

Minutes: XDI TC Telecon Thursday 2011-10-06

From
Drummond Reed <>
Date
2011-10-07T08:13:48+00:00
ID
Thread
Minutes: XDI TC Telecon Thursday 2011-10-06
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
← Prev in month ← Prev in thread
Next in thread → Next in month →