[sc34wg3] New syntax for (binary) associations
db3000 at mac.com
Sun Feb 3 12:50:37 EST 2008
On 3-Feb-08, at 6:23 AM, Robert Barta wrote:
> 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>
I agree with all that. But I think it is nothing to do with
representations of associations.
I would create a PSI and description (with text above) and publish it
on the web with explanation that
when "is-employed-by(X,Y)" is used, X corresponds to "Employee" role
and Y corresponds to "Employer" role.
Even at TMDM level we deal with representations, so "is-employed-by
(X,Y)" can represent exactly
the same thing as "is-employed-by(employee: X, employer: Y)", it is
just encoded using more compact representation.
> 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
Many "isa" associations are time sensitive. Modeling "real world"
roles as TM types makes sense to me, because
types allow to describe rich context of "being". "Real world"
roles become types "with parameters".
"Employee" has parameter "list of organizations", "Project Manager"
has parameter "list of projects", etc.
BTW, many topic mappers re-use topic types for roles, so we will
probably have "Employee" and "Employer" defined as types anyway.
so we will have something like this:
o:is-employed-by(o:Employee: X, o:Employer: Y)
More information about the sc34wg3