[sc34wg3] New syntax for (binary) associations
rho at devc.at
Sun Feb 3 06:23:20 EST 2008
On Sat, Feb 02, 2008 at 01:39:12PM -0500, Dmitry wrote:
> I have a problem with understanding logical meaning of traditional
> associations, specifically type-subtype relationship between
> association types and roles.
That is indeed a critical section, but I think this is exactly where
RDF and TMs differ. And why I prefer the latter.
Associations in TM are (well, can be) highly relativistic constructs,
in that I can not only say
"someone is employed at organisation",
as in RDF, but add a lot more context, as in "there exists a context,
"someone plays the employee there,
some organisation plays the employer there,
and maybe there is also the position (say manager)"
The totality of the roles actually defines the "association type" for
me, so the tuple <employer, employee, position> would be the implicit
assoc type above.
The fact, then, that TMs allow me to add an explicit association type
to the tuple of roles, I just regard as a convenience for the human
user. In a sense, I regard
as a reification of the tuple (set)
<employer, employee, position>
The two predefined ones, isa and iko are special in the sense that
they are "context-free", i.e. they only include two things, regardless
of any further context.
If you write now:
> isa o:Employee
> o:works-for [ The-Beatles isa o:Employer]
then your are undermining completely my mindset above :-)
"isa o:Employee" would be bad modelling as the fact that someone is an
employee is quite ephemeral, whereas "isa o:Person" is true, even
after the death of that person (it is not true before the birth, but
that is another ontological problem). Same with "The-Beatles isa
> > 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.
**IF** we go for a default role type, then I would prefer tm:thing
(subject, whatever) for both. 'Subject' and 'Object' describe the
roles of something _in the statement_, not what I actually want to
More information about the sc34wg3