[sc34wg3] New TMCL slides

[Dmitry]

On Sunday, November 08, 2009, at 12:07PM, "Steve Newcomb" <srn at coolheads.com> wrote:
>Yes, Newcomb is howling in the distance, but not for the reasons Patrick 
>probably suspects. It will take a moment to get to my howl; please bear 
>with me.
>
>Dmitry and Lars have different views of what constitutes an association 
>type. For Dmitry, it's OK for an association type to have a more complex 
>model than Lars Marius would prefer to support. In Dmitry's model of 
>association modeling, an association type can be, for example,
>
>Association Type T == ( role A, ( role B | role C)) ## a 2-role 
>association model in which the second role is one of two role types.
>
>Lars Marius would prefer to see this as two association types:
>
>Association Type T1 == ( role A, role B)
>Association Type T2 == ( role A, role C)
>
>(Personally, I'm sympathetic to Lars Marius's view, because his 
>"signatures" formulation of association modeling, which I take to be 
>that an association type is neither more nor less than a set of role 
>types, is for me the best way to think about association types.)
>

Thank you Steve!

It is a great summary, and the rest of your post is a perfect explanation of what you mean by association types.


>Patrick says something akin to, "Let a hundred flowers bloom." OK, good 
>idea, but I'm not sure we have two distinct flowers here.
>
>Maybe Dmitry's requirements can be fulfilled without abandoning the 
>"signatures" approach (I like Lars's "signatures" term). If we say that:
>
>Association Type T3 == ( role A, role B, role C)
>
>and additionally provide that role A must always be played (must have a 
>role player), and that either role B or role C must be played, but not 
>both, then, for whatever reasons Dmitry needs a single association type 
>instead of two different ones, he can still have it, and for whatever 
>reasons Lars Marius wants to preserve the "signatures" doctrine, it is 
>still preserved.
>


No, this approach will not work for me. I saw examples like this in recent discussions related to GTM/TMCL and this is exactly what I do not like.

I think I can agree with Steve's general definition of association type/roles. I just try to find an efficient way to represent these concepts based on TMDM machinery.

Of course, I can replace my original example

works_for(Person,Company)
works_for(Person,Non-profit_organization)

with something like this:

works_for_Person_Company(Person_in_Person_works_for_Company,Company_in_Person_works_for_Company)
works_for_Person_Non-profit_organization(Person_in_Person_works_for_Non-profit_organization,Non-profit_organization_in_Person_works_for_Non-profit_organization)

It will be supported by current TMCL draft and I think it will satisfy  "exactly one subject per topic" rule. Is it easy to use?...

I think that current TMCL draft will force authors to create long (and often artificial identifiers) for association and role types if they care about exactly one subject per topic" rule.

In my suggestion,  works_for(Person,Company) - is a syntactic form that  defines a "real" association type "Person_works_for_Company"
"Person" in this case is not a "real" role. The real role is "Person_in_Person_works_for_Company". The same is true for "Company".
"Company" is not a "real" role, but "Company_in_Person_works_for_Company) is.

I think that syntactic form works_for(Person,Company) can  encode quite efficiently semantics described above.

I believe that this approach better supports "natural" development of ontologies. We can start with "natural" associations such as

works_for(Person,Company)
works_for(Person,Non-profit_organization)
works_for(Person,OtherPerson)

and generalize later (if/when we can/want to)

works_for(Employee :  $X ,Employer : $Y) :-  works_for(Person : $X ,Company : $Y).
works_for(Employee :  $X ,Employer : $Y) :-  works_for(Person : $X ,Non-profit_oraganization : $Y).
works_for(Employee :  $X ,Employer : $Y) :-  works_for(Person : $X ,OtherPerson : $Y).

Dmitry