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: RE: [xdi] Re: Agenda: XDI TC Telecon Thursday 1-2:30PM PT 2011-03-03


Just a quick note and a quick typo fix. I added an outstanding issue for discussion on the messaging protocol in the Idearpad minutes. For convenience it's below.  In that I also had a typo - I left out the $msg that is in =Bill.Barnhill$msg!2345.  That is corrected below. I also appended some text to the discussion item below.
 
* Bill would like to discuss on a subsequent call a different messaging approach.
First segment is an arc path that uniquely addresses the message. This path is rooted in the i-name of the sender of the message and goes through an i-number that is the request id,  e.g., =Bill.Barnhill$msg!2345.
Operation description extends the path, e.g., =Bill.Barnhill$msg!2345$do$get.
Operation parameters are defined by the XDI dictionary for the op, for example $do defines std params applicable to any op, $get defines additional parameters. These parameters are defined by something along the lines of a XDI graph template.  Furthermore I am not convinced that allowing multiple operations in one XDI message is a good thing. Are there benefits to multiple operations per message that outweigh the following advantages of one op per message, i.e., the message is the op
 
.. msg XRI's that are more meaningful and higher level, meaning significant ease in parsing needed to route message.  =Bill.Barnhill$msg!2345 and  =Bill.Barnhill$msg!2345$do$get now become =Bill.Barnhill$get!2345
 
.. 1op1msg makes handling messages easier, especially when it comes to pipelining (something near and dear to me). If I have a message with two ops, a $get and a $add, then my pipelining options are (a) pipe output of $get to another XDI endpoint;(b) pipe 'output' (the resulting context) of $add to another XDI endpoint; (c) pipeline params on the msg, which pipe the output of both ops to another XDI endpoint; (d) a combination of the above.  Conversely, 1op1msg eliminates (b), and makes (a) and (c) the same, eliminating (d) - resulting in one meaning for pipelining in the message.

.. 1op1msg feels cleaner, closer to REST, which is subjective, but to me is an advantage.

 

.. On the subject of closer to REST..If we have the message XRI being =Bill.Barnhill$get!2345 we have almost defined the main characteristics of the op. If this is to the endpoint @example then we could change message XRI to =Bill.Barnhill$get(@example)!2345 and then the op data is the graph underneath. For $get this doesn't matter much, signing etc. can go in the metadata about the graph, but for $add this means that you could have something along the lines of

=Bill.Barnhill$add(@bookshelf+bid)!2345
      $this+book$new
            +title
                  (data:,The%20Grapes%20of%20Wrath)
            +author
                  (data:,John%20Steinbeck)
            +currency+dollar
                  (data:.3.99)
 
          

From: drummond.reed@gmail.com [drummond.reed@gmail.com] On Behalf Of Drummond Reed [drummond.reed@xdi.org]
Sent: Friday, March 04, 2011 2:24 AM
To: OASIS - XDI TC
Cc: Henrik Sandell
Subject: [xdi] Re: Agenda: XDI TC Telecon Thursday 1-2:30PM PT 2011-03-03

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

Date:  Thursday, 03 March 2011 USA
Time:  1:00PM - 2:30PM Pacific Time (21:00-22:30 UTC)

ATTENDING

Bill Barnhill 
Drummond Reed 
Joseph Boyle 
Michael Schwartz 
Giovanni Bartolomeo 

GUEST

Henrik Sandell


THE GOTOMEETING FOR TODAY IS:
     https://www2.gotomeeting.com/join/969244355

THE IDEARPAD LINK FOR TODAY IS:
     http://xdi.idearpad.org/24

Please try to preface each of your comments with your name so the
transcription into the minutes is easier.


AGENDA


1) WELCOME TO GUEST HENRIK SANDELL

Henrik is an engineer by training. He first worked with John Clippinger at Context Media in the late 1990s. He is again working with John on implementing trust frameworks for data sharing among personal data stores. In his current project with John, they are very interested in link contracts as a way to control data sharing.

Henrik and his group did a demo for the World Economic Forum at Davos in January. They showed a mobile data gathering app that was overlayed by a trust framework in order to contribute informationt to a shared traffic analysis. It was very well received. They are now looking to implement a reference architecture. They are now looking at an XDI implementation for this project. They are also looking into establishing a new project called the Mustard Seed Project. They would like to work with others to develop this platform into a working system by mid-summer.

Drummond provided some background about the evolution of the XDI specs and the current status that the TC is getting very close to the XDI 1.0 spec set, but wanting to make sure that they are proved out by multiple impelmentations.

TC members then explained to Henrik the status of different impelmentations. Bill went first, explaining that he's looking at implementations focused in two different areas: personal data and "big data". In the first area, Bill is working on using the TeleHash protocol (http://www.telehash.org/) to implement a version of XDI which does not require a server.  The goals would be somewhat similar to those of the Locker project by Jeremie Miller, but would be built top to bottom to make use of the benefits provided by the XDI graph model.  The "Big Data" version would not use TeleHash but would also be based on a Key-Value store.  The "Big Data" version would use a server built on top of Riak or Redis (experiments are underway to decide which).  The personal data version will be written in Node.js. The "Big Data" version will be written in Erlang.

Mike then explained Gluu's perspective. Gluu has an application that helps organizations manage their Shibboleth infrastructure. They would like to add support for XDI data sharing so organizations can support both identity federation and data federation. Mike said that interorganizational data sharing is difficult with LDAP since they are not set up for that kind of data sharing and authorization.

Mike said that his use cases are based on authorization at the organizational level, less so the personal level. Gluu has started an open source project called the OpenXDI project for which they are just setting up the Jira, wiki, and other accounts.

Joseph explained that he would like to do an implementation in Scala, noted that Ian Kallen recently tweeted that Scala was the ideal language for network servers. Joseph is hoping to use some of David Pollack's ideas and frameworks for that code base. Scala is interoperable with Java, so it can be compatible with other Java implementations and code such as the XDI4J project from Markus Sabadello (who is not on today's call).


2)  NEW XDI GRAPH PATTERN DOCUMENT

Drummond  uploaded a new version with the new XDI synonym pattern (that was the  only change vs. the last one, plus one addressing error correction):

  PDF: http://www.oasis-open.org/committees/download.php/41305/xdi-graph-patterns-2011-03-02.pdf 
  PPT: http://www.oasis-open.org/committees/download.php/41304/xdi-graph-patterns-2011-03-02.pptx
 
Drummond gave Henrik a quick overview of the XDI graph model and the differences with the RDF graph model.

Giovanni then explained that in the last 3 weeks, he's been studying the differences between the two graph models, and believes that there is a way of XDI graphs being fully compatible with the RDF graph model.

Bill agrees with Giovanni about this. He observed that one RDF format, Notation 3 (N3), is more powerful than the others. It is an "evolutionary step beyond RDF" that fixes some of the problems with RDF. Bill sees the XDI graph model as another step in the next direction.


3) NEW SYNONYM PATTERN IN GRAPH NOTATION

We reviewed the new synonym pattern in the graph notation. Note that all XDI synonym statements take the form:

  xri1/$/xri2

So all synonym statements have $ as the predicate.

Giovanni had a question about the use of cross-reference syntax in the root context node examples in each of the seven patterns in the XDI Graph Patterns PDF). Bill also asked about it, saying he has been using cross-reference syntax to represent what in RDF is reification.

Drummond explained that his view of the XDI semantics of XRI cross-references has simplified back down to the original XRI semantics, which is simply that a graph statement from one context is being used in another context. Giovanni said he agrees with keeping the semantics of cross-references as simple as possible.

Giovanni would like to make a proposal about XDI root node (endpoint) addressing and how to do XDI resolution. He broke it into two requirements:

  a) to address the root node of an XDI graph from any node underneath it in the graph.
  b) to address the root node of an XDI graph from any other XDI graph.

Giovanni pointed out that RDF named graphs fulfill the second requirement by assigning a URI to the graph, which from an XDI perspective is essentially the address of the root node of the graph. In RDF this is the endpoint from which a copy of the graph can be downloaded.

Giovanni proposes that this URI be considered the resolution context from an XRI resolution standpoint. Drummond then went through the semantics of the root context node example in the XDI Graph Patterns diagram to show how he completely agreed with Giovanni. The only difference is that the URI would be inside the cross-reference parentheses instead of an XRI, i.e., instead of:

  (=abc)
 
...you would have

  (http://example.com/some-XDI-endpoint)

Bill and Drummond also explained that we established some time ago tha ta standard address for the root node of the graph is just $. Bill went along with this as it was consensus, but still has reservations.  Giovanni does not agree with this, he thinks that $ is a synonym for owl:sameAs property and should be used ONLY as such. He thinks that we can use any other $word (e.g., $super, $context, $thisContext....) for this purpose, but not just $!

Drummond disagrees with this and will take the action item to publish a matrix that shows clearly defined semantics for all the metagraph symbols as XDI subjects, predicates, and objects, and also as prefixes and suffixes.

Bill's question: Given an XDI document rooted in =Bill.Barnhill, what is the semantic difference between (=Bill.Barnhill) and =Bill.Barnhill$  ?

Giovanni asked a question: is =Bill.Barnhill *under* the root node or *outside*?

Bill answered: =Bill.Barnhill is the XRI for my personal data. =Bill.Barnhill would also be *under* the root node in the document that describes that data.

Giovanni thinks that this is not a good approach, they should be different identifiers (a discussion on this is ongoing in the linked data community, how to distinguish between the URI where the document can be retrieved and the URI for a given referent - non informative resource - ref. Cool URI for the semantic Web by Saueman et al.)

Bill agreed about that being necessary, but believes that having them be different identifiers is a problem.  Cool URIs is something by TimBL that's been around for a while.  Cool URIs don't change, means you shouldn't change URIs, once you have one it should always be usable.

Bill is using the following to do that kind of integration, in part:

=Drummond/$/(http://equalsdrummond.name)

Denoting root of document I have been using $ for that.
$
   1 thing at this level =Bill.Barnhill

What Bill has been thinking:
$
    $d
        "2011/03/02"
        =Bill.Barnhill
        +age!
                    "42"
        +friend
          +Giovanni
                /
                    +age!
                        "33"
                                 

What Giovanni is thinking:
$this
    $d
        "2011/03/02"
$this
    $
       (http://example.org/resource/Bill.Barnhill)
=Bill.Barnhill
   +age!
        "42"
   +friend
        =Giovanni
=Giovanni
    +age!
         "33"
         
Bill's comment: That works, I don't see a problem with it. Cleaner than mine. Only nit is I like $self better than $this, but thats trivial.

Bill requested that Drummond, who had to leave the call, write up his examples of the same graphs above when he has time.


4) NEXT CALL

The next call is next week at the regular time. Drummond mentioned he may have a conflict due to potentially flying to SXSW next week, but will try to schedule it around the call.


------------
ONGOING ISSUES LIST

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

* 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

* Bill would like to discuss on a subsequent call a different messaging approach.
First segment is an arc path that uniquely addresses the message. This path is rooted in the i-name of the sender of the message and goes through an i-number that is the request id,  e.g., =Bill.Barnhill!2345.
Operation description extends the path, e.g., =Bill.Barnhill!2345$do$get.
Operation parameters are defined by the XDI dictionary for the op, for example $do defines std params applicable to any op, $get defines additional parameters. These parameters are defined by something along the lines of a XDI graph template.






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