Minutes: XDI TC Telecon Thursday 1-2PM PT 2010-06-24

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

Following are the minutes of the unofficial telecon of the XDI TC at: 
 
Date:  Thursday, 24 June 2010 USA
Time:  1:00PM - 2:00PM Pacific Time (21:00-22:00 UTC)

ATTENDING

Joe Johnston 
Bill Barnhill 
Joseph Boyle
Drummond Reed 
Giovanni Bartolomeo 
Markus Sabadello

 
NOTE: THE IDEARPAD LINK IS:
 
      http://xdi.idearpad.org/2
 
The password is:
 
      turtle
 
Please try to preface each of your comments with your name so the transcription into the minutes is easier.
 
(Note: the link to last week is http://xdi.idearpad.org/1 - password was ‚Äúturtles‚Äů.)


1) UPDATES

Bill and Drummond reported that they were together giving a full-day deep-dive intensive on XDI and personal data stores for Booz Allen Hamilton leadership.

Drummond is at SemTech to be on a panel on personal data lockers hosted by an author named David Siegel, whose book "Pull", which is all about what a semantically-enabled world will look like, and has an entire chapter (and in fact section) on personal data lockers.
 
Markus said he's been talking to 2 students at a German university (Unversity of Erlangen) who are very interested in implementing personal data stores with XDI.
 
 
2) XDI JSON SCHEMA 
 
  http://lists.oasis-open.org/archives/xdi/201006/msg00022.html
 
We reviewed the status of the JSON schema format Bill has proposed. Drummond explained that he and Bill discussed it at their dinner earlier this week and the idea that all serialization formats could carry inline data typing information
 
Bill: 
Example in X3 native for a literal : "true"^^xsd:boolean
Example in RDF XML:
<rdf:Description rdf:about="http://example.org/item01">
    <ex:size rdf:datatype="http://www.w3.org/2001/XMLSchema#int">123</ex:size>
  </rdf:Description>
  
Bill is planning to put about an example of the PDX Example document in the JSON serialization format.

The challenge he's run into is using the PDX Example link contract format - he's not sure how to represent some of the semantics that he's like to express.

3) DEEP-DIVE TOPIC LIST

Bill: We also discussed the growing number of issues that need to be queued for discussion on the weekly calls. Bill took, and executed during the call, an action item to query Mary on use/existance of our portion of the issue tracker.

Drummond noted the following topic are already on the list:

* Semantics of $
** This includes semantics of $digit extensions, which are how personas are currently being done in the PDX example document (http://wiki.oasis-open.org/xdi/PdxExample).
* Link contract structure


4) QUESTIONS AROUND $IS SEMANTICS
 
Giovanni sent a message asking to put $is semantics on the agenda and Paul Trevithick posted a response with a clarification of comparing $is with Higgins Personal Data Model (PDM) semantics of h:correlation.
 
      http://lists.oasis-open.org/archives/xdi/201006/msg00036.html
 
A link to the specific paper on the RDF SameAs topic: http://www.w3.org/2009/12/rdf-ws/papers/ws21

This led to a discussion of contextualization of identity in XDI. For example:

=drummond <!-- drummond as a member of community of individuals
@golfclub+member=drummond <!-- drummond as a member of a golf club

Giovanni explained that the two XRIs above explicitly declare the same resource (=drummond) in two different contexts - in a global context, and in a specific context (@golfclub+member). He believes that this use of non-opaque identifiers can solve the problem of contextual representation of a resource (called in the paper "Same Thing But Different Context" and resolved by authors using named graph).

Drummond strongly agrees.

Bill: I agree that the opaqueness resolves much (ie the contextuality), don't agree totally though with above because I don't believe it solves synonym problem consider this:   Drummond is a member of the golf course above, but for various reasons (he doesnt want his wife to know :), he wants that information private, like so:

=drummond
@golfclub+member!23

Bill: This means we CANNOT use $is or we violate this privacy. Also the identity @golfclub+member!23 is not equivalent to the identity =Drummond, but is a subset of that identity. 

Giovanni: I think we have here two different issues: 1) is relate to who can know that =drummond id @golfclub+member!23 disclosure of this information should be controlled for privacy issues of course, so for example link contracts on statements describing this identitity {@golfclub+member!23/$is/@golfclub+member=drummond} could be used I think;

Giovanni: 2) issue is related to the attributes; right to say that it is a subset of attributes; those who know that =drummond is @golfclub+member!23 can correctly identify =drummond as that member, and then discover other attributes. So they and only they can infer @golfclub+member!23/$is/@golfclub+member=drummond.

Bill: I think that would be right if $is wasn't symmetric.The example below is a better example of that problem I think. The relationship to me seems very much a one-way, a subset relationship.

Bill: Another example from my email earlier:
I was thinking about this and think we may need a new $ word. 
 
Bill: The use case is this: 
Say we have =Alice whose doctor is @bobmed+doctor=Bob. Let's also say there is a global community of patients at @patient and Alice's identity as a patient is @patient!45. Alice as a patient {@patient!45} and Alice as an individual {=Alice} map to the same entity {her i-number} but they aren't synonyms because there are clear contexts where Alice's patient identity is not interchangeable with Alice's identity as an individual or as an entity, and vice versa, due to privacy, compliance, or other reasons. 
That means we cannot use $is. 

Giovanni: as said before I think you can apply here the fact that only legitimate individuals are able to access this information, i.e. a statement {@patient!45/$is/@patient=Alice} is protected through link contracts in a given knowledge base which can be accessed only by authorized people (e.g. her doctor)

Markus: To me $is is pretty much like <EquivID> (or <LocalID>) in XRI.

Bill: Given the semantics of $has and is I don't believe this maps to $is$has as that means =Alice has a member of her set that is @patient!45, whereas $partOf would mean that the set of members of @patient!45 are a subset of the members of =Alice, in the same way that the one identity is a subset of the other, but I'm interested in what others on the TC think on that.
 
Bill: I'd like to queue for discussion on a later call the topic of adopting $partOf for situations where identities are not interchangable but that one is a subset of the other, i.e. @patient!45/$partOf/=Alice ?  This would map to/from h:partOf and skos:partOf.

Bill: $part would be probably be better than $partOf, for the purpose of $is$part.
=drummond/$part/@golfclub+member=drummond
@golfclub+member=drummond/$is$part/=drummond

Drummond brings up another example of how subtle and powerful $is relationships can be:

If an XDI document contains the XDI statement...

=drummond/$is/@golfclub+member=drummond

...then I believe the full $is semantics apply, i.e., the author of this statement is asserting that these are logically the same resource, and thus that you can perform a union of these two graphs and they should be logically consistent.

My questions are:

1) Is in fact a $is statement is even needed to make this assertion, or does the fact that the global XRI =drummond is used in both XDI addresses already make that assertion? (My gut is that the latter is true 

[Giovanni:I agree, probably you don't need =drummond/$is/@golfclub+member=drummond rather what you need is to get control over the disclosure of this fact {@golfclub+member!23/$is/@golfclub+member=drummond} ]

2) Does the fact that the same absolute XRI =drummond is used in two different contexts automatically mean that the XDI graphs in both contexts MUST (SHOULD) be logically consistent, or no?

 
5) NEXT CALL

The next call is next week at the regular time.