Re: Agent Sub-Types

Reza,

it's worth trying to make progress on this as we are in the process of editing a document draft.

I can see the dilemma:
- the less you specify in the model, the more you risk incompatibilities as different implementations make their own choices to fill 
the gaps;
- but by adding specific extensions to the top-level concepts in the model, you risk to make those choices arbitrary.

But in this specific instance, I believe that "trusted" is one specific qualification of "Agent" that does not belong to the model, 
rather it belongs to applications that use the model (i.e., to /assess some measure of trust/).
   But I see your need for a "placeholder" where I can assert something about how trust for Agents. This is fine: let Trusted not be 
a sub-class of Agent, but let "Trust properties" can be properties of Agent. Would that be a problem?  Any application that knows 
about trust would fill in into those properties.

To repeat my proposal, I see Agent as a Role that any first-class entity in the model can take on when it is involved in relations 
that concern activities.

The general lesson I see from this thread is that we urgently need to discuss how principled extension mechanisms ("profiles") make 
it into our proposal.

atb -Paolo


On 7/14/11 10:06 PM, Reza B'Far wrote:
> Ok.  At this point, I'm resigning to the fact that I'm in the minority.  However, just look at HTML as a data point:
>
> They could have made <p></p> and <div></div> tags into the same generic tag with an attribute (or attributes).  I would argue that 
> they made the right decision(s) in the strong types they created, though not all were perfect decisions (e.g. <blink>).  That 
> "strongly encouraged" all the implementers of browsers to define rendering of a paragraph in a specific way (and different from 
> <div) which is more loose).  The core issue is compatibility.  If you make something generic and provide only soft guidelines for 
> extensions, you end up with compatibility issues when product implementers build their products because they will do whatever they 
> can within the specification to differentiate their products.  Ignoring that fact risks success of a standard once implemented.
>
> But, I end with my original statement that I'll drop the topic.
>
> On 7/14/11 1:57 PM, Daniel Garijo wrote:
>> Hi Reza, all,
>> I agree with you in that subtyping is very important from an implementer persepctive.
>> However I think that the model discussed in the model TF is supposed to be generic,
>> and once we have it, the test cases TF can develop some profiles subtyping all the
>> generic concepts, showing examples of how it would be extended in different domains.
>> Thus, developers could use these profiles as reference for other extensions.
>> Best,
>> Daniel
>>
>> 2011/7/14 Reza B'Far <reza.bfar@oracle.com <mailto:reza.bfar@oracle.com>>
>>
>>     I agree that it's the right thing to do to keep trust definition out of the scope of WG.  However, if the group is saying
>>     that defining touch points to the tangent layers, per your own references, is also out of scope, then I warn that there is a
>>     fundamental problem for product implementers.  If you want to exclude all aspects of trust including any think like the
>>     ability to embed something else via a URI or something like that to a trust mechanism, then you'll have compatibility issues
>>     from different product vendors.  If you want to do that knowingly, it's fine and I'll drop the thread, but if you disagree
>>     and think that exclusion of trust doesn't cause fundamental incompatibility, we can continue thread and I can provide more
>>     details on why this is the case.
>>
>>     So, my point from the beginning is that without subtyping, things are too generic to be able to import and export things
>>     about entities between different systems.  And I believe a primary use-case for usage of the model is import/export between
>>     different implementations.
>>