Minute 3/24 - ORMS TC Bi-weekly telecon

[Tatsuki Sakushima <tatsuki@nri.com>]

ORMS TC Bi-weekly telecon has been modified by Mr. Nat Sakimura
 
Date:  Thursday, 25 March 2010
Time:  07:00am - 08:00am JST

Attending:

Henrik Biering
Corey Leong
Mani Mahalingam
Nat Sakimura
Tatsuki Sakushima

Dee Schur (Special guest from OASIS)

Selection of a Secretary for this meeting:

Tatsuki volunteered for this call. 

Approval of the minute from the last meeting:

Approved.

Discussions:

1. Link element in the reputation format:

Nat explains the motivation for adding multiple "link" elements to express multiple reputations. On Working draft wiki page, 5.2 Reputaton Response section, we have only one single reputaiton response but we can in concept have multipule reputation outputs. For example, Grading a camera can be split into one overall grade (A+) and sub grades (size, style, image clarity etc).

Mani asks that link elements are in the same reputation context and expresses about the same entity. Nat continues to explain and the answer is yes. Mani also raises the point that splitting reputation data to multiple files would help access control of certain data.

Mani asks an example of use cases for multi-vector/context.
(Probably we need discuss about definition of "context" and "vector".)

Nat also advocates link structure to aggregate multiple reputation data in one file and emphasizes this way will simplify signature processing. Tatsuki raises the point that this case it will need to use some kind of type URL to express what kind of data is in the link. And Nat suggests relationship (at least child and parent) types.

Corey asks an example of markup language does similar. Tatsuki thinks that XRD has a similar structure. Nat thinks HTML5 Link structure is also the same.

Mani thinks that the link structure might bring some complexity in implementation and interoperability issues.
Tatsuki thinks that making the link element optional in syntax would solve complexity and interoperability issues.

Bill is an original advocate for multiple-reputation, so TC decides to differ a final decision until he comes back.

Nat will come up with an example of how the "link" element will be use aggregate multiple reputation data in the ML for further discussion.

2. Applying signature matters

Nat considers to use XMLSig with exclusive-c14n.


3. What data should be in the reputation XML(format)

Nat thinks that this is not finalized and needs further discussion.
Nat comes up new ideas, the "link" structure discussed above and "rank" and he encourages other members to add.
Nat thinks that ranking data would be useful for popularity of products and so forth. Mani asks that ranking is output of some normalization or sort of function of score. Nat brings rank as an idea. Tatsuki thinks that ranking is a type of score and can be express it as a type of score not has to be separate data element. Nat points out that definition of "score" in the current WG is a statistical value. It is not covering data like ranking. Tatsuki concerns that adding data elements this way would result blown up to too many of them. Tatsuki suggests making score as "class" or "model" so it can be instantiate with specific type information which express what the score stands for.

TC probably needs further discussion about how to express score in the format. One overall data in the format and multiples with links. Score and Rank in the same format? Look at use cases individually and figure out the best way to accommodate all use cases.

Tatsuki thinks that how we design the format depends on design principles. Simplicity v.s. Extendability. Tatsuki leans to simplicity over extendability because he thinks interoperability is a key for adoption. More extendability usually brings more issues on interoperability. If the score is more conceptualized, score needs meta data for "scale" and how to express (in numbers) For example, 5 stars (5 scales) for products in Amazon. 6?0 to 830 (range) for FICO score etc.

Nat asks Tatsuki to elaborate his idea further and post is in ML.

4. Outreach

Dee asks TC members to give her more information (especially use cases) so she can use them to outreach 
other members who should join this TC.