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

[Tatsuki Sakushima <tatsuki@nri.com>]

> 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.

If we think of the ReputationBundle case and <Subject> is has an identifier of an entity, <Subject> in a parent document and a child document could be the same. (How to make it not correlatable and transaction awareable is another issue and I guess that it is application specific.)

I start supporting the idea that <Subject> and this document id are not the same. But we need documents ids to find and identify documents in the bundle case.

Tatsuki

(5/4/10 4:42 PM), Tatsuki Sakushima wrote:
> 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>.
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php