Re: [orms] Defining relationship among <Subject>, <Assertion> and<Context>

[Tatsuki Sakushima <tatsuki@nri.com>]

Thank you, Mani.

(5/4/10 3:01 PM), Mani, Mahalingam (Mani) wrote:
> Tatsuki,
> 
> On 
> 1. the first two statements seem somewhat recursive - but I get the
> idea. this describes (identifies) the entity under assessment (for
> reputation).

The first line mentions the identifier to find and identify "this document" without regarding to any Subject(or entity). The second line says the identifier of the entity described by this document. I was wondering if there is a case to distinguish those two identifiers.

Do you think that the identifier of the document is always equal to the identifier of the entity? To minimize the number of elements, it is good if these are consolidated to one identifier, however, if there is a case that keeping them separately is reasonable, we have to come up a way to express two ids in the same document.

>    That seems acceptable rather than having an ID in the document that
> signifies...what...i am not sure. Then, <context> described in 3 becomes
> easier
>    Understand and accept.
> 2. an assertion is a quantitative representation of reputation of the
> Subject for that context. Unless their representation is modulated by
> the
>    context(rather, context-type), i.e., the scale of representation
> (e.g., 1-to-10 or 1* to 5* notation or 0-100) is a function of the
> nature of 
>    context. Of course, the context can allow for more than more
> representations (scales).
> 

Yes. I added the "type" attribute in <Score> which defines the context of score including how it represents, scale, format and so forth. The <Context> compiles all rules and schema. Usually it contains the URI which describe all the rules and schema. The rules and schema should be defined by the owner of the RMS (e.g. Amazon for book reviews).

If the assertion is a representation of reputation such as scale, it should be part of <score>. This way is easy to understand. 

To me, assertion is an attribute or set of attributes of <Subject> which is evaluated in a ORMS file. The subject usually has many aspects representing itself as attributes. Those aspect also change by context. But I just could not come up with good examples. I guess that <Assertion> will be used when describing <Subject> in detail or context-sensitive. Maybe I am wrong. I need more perspectives about <Assertion>.

>    Is the world of such scales finite or definable enough to document a
> list of known (if extensible) types?

IMHO, definition of scales are out of scope and should be. All this TC should define is the basic structure to form interoperable reputation data. I assume that many profiles will be made based on our spec. I think this should be our goal. The spec should be flexible and the detail of it should be definable by others in order to accommodate as many use cases as possible.

> 3. In the context of (2) above I generally agree with your statement on
> Context (3)
> 
> Regards,
> -mani
> -----Original Message-----
> From: Tatsuki Sakushima [mailto:tatsuki@nri.com] 
> Sent: Tuesday, May 04, 2010 1:49 PM
> To: orms@lists.oasis-open.org
> Subject: [orms] Defining relationship among <Subject>, <Assertion> and
> <Context>
> 
> I think that the relationship of those three elements defines the
> foundation of ORMS structure. Therefore, clear and concise definition of
> those are very important. I summarize my views of those below. Please
> provide yours to clarify what those elements mean. We can use common
> senses among us and put them into functional design of each elements.
> Thank you in advance.  
> 
> Tatsuki
> 
> -----
> 
> 1. The definition of <Subject>
> 
> I thought that <Subject> was an identifier of a reputation document. But
> I am considering it is an identifier of subject evaluated by this
> document. If the identifier in <Subject> is equal to the identifier of
> this document, we don't have to change the definition. But if we assume
> they are different, we should keep them separate by defining an "id"
> attribute in <Reputation> instead.
> 
> In some e-commerce cases, identifiers of reputation documents may not be
> so important. But <Subject> is important. The IDs may be optional. 
> 
> 2. The definition of <Assertion>
> 
> Does this element hold information what attributes of <Subject> is
> evaluated? I'd like TC members to share your image of <Assertion>. To
> me, it is functionally similar to <Context> (Its function is Namespace
> of reputation and score type definition. Assertion can be defined under
> <Context>). I am wondering they should be consolidated or keep
> separated. It can contain IDs imported from other documents like SAML.
> 
> 3. The definition of <Context>
> 
> I thought that having <Context> element is good idea. I am considering
> that it defines the namespace of reputation document and more detailed
> schema for <Score> elements. It can also define what information should
> be in <Assertion> as claims about <Subject>.
>