[sc34wg3] New syntax for (binary) associations

[Dmitry]

On 2-Feb-08, at 5:15 AM, Robert Barta wrote:

> On Fri, Feb 01, 2008 at 01:52:19PM -0500, Dmitry wrote:
>> More I think about it, more I see value to have these standard roles.
>> From my perspective, it is  more important to think about the nature
>> of association type and to put association type in the "right" name
>> space/domain and
>> to have  well defined interpretation of type-subtype for  
>> associations.
>>
>> blogging:has_post
>>      ako  dc:has_part
>>
>> I always  can define user friendly names for roles for  specific
>> association types:
>>
>> tm: subject
>>      - "Blog" @ blogging:has_post
>
>> - interoperability with RDF (almost without any annotations)
>>
>> Should I call this thing TM-Lite :)
>
> You should call this thing "RDF heavy" :-)
>

I have a problem with understanding  logical meaning of  traditional  
associations, specifically
type-subtype relationship between association types and roles. It  
became clear to me after TMQL discussions.

This example, I think,  represents the original "need" that was  
implemented through specialized roles.

john
    isa o:Employee
    o:works-for   [ The-Beatles  isa   o:Employer]


> But you're definitely correct that the "role-business" has to be
> (better) addressed in CTM/TMQL/TMCL. In CTM this can be largely
> covered with templates, but it takes the effort to define them and
> then they create a "context":
>
> [ modulo the syntax of the day ]
>
>    works-for ($e, $o) :-
>      is-employed (employee: $e, employer: $o)
>    .
>
>    # further down
>    rho works-for arcs .


This would work for me, if we have a default mapping to tm:subject  
and tm:object.

something like this:

   o:works-for($e, $o) =>  o:works-for(tm:subject: $e, tm:object :$o)

If someone wants to spend time defining templates for each  
association type, I do not mind.


I do not see necessity for templates. Simple assertions will do the job:

o:works-for
     isa Property
     subject_role o:Employee @  o:is-employed
     object_role o:Employer @  o:is-employed


And again, this can be an overwriting behavior.

if I just say

o:works_for
   isa RDFishAssociation

I should be able to use it without any additional definitions as a  
"property"

john
    o:works_for The-Beatles

or

The-Beatles
   ^o:works_for john



Dmitry