[sc34wg3] TM Data Model issue: assoc-role-player-type

Kal Ahmed sc34wg3@isotopicmaps.org
27 Oct 2003 20:33:37 +0000


I think it makes more sense to require the [role playing topic] property
to be non-null.=20

If you want to say that  the player is unknown, then you should be
required to create a topic to represent the "unknown" entity. After all,
if you say that the role player is unknown, then you are saying that
there is a subject that is the role player in the association (topic
maps don't allow fuzzy statements) and it is clear that the one thing
known about the role playing subject is that it plays a role in an
association.=20

Cheers,

Kal

On Thu, 2003-10-23 at 16:01, Geir Ove Gr=C3=B8nmo wrote:
> Another issue: I see that the properties [type] and [role playing
> topic] have now been made optional on the association role item.=20
>=20
> I have a suspicion that the rationale for this decision is that one
> should be able to represent non-complete data. Unfortunately this
> decision has some rather nasty side effects. Two words: duplicate
> suppression.=20
>=20
> The current equality rules consider properties with the value null to
> be identical. This means that any association role items that have a
> null value in their [type] or [role playing topic] properties may get
> suppressed because some other item also has the null
> value. Furthermore it may also lead to associations being suppressed.
>=20
> This effectively means that what is considered by the author to be
> "not complete" is being considered "suppressable" by the topic map
> processor.
>=20
> If authors want to represent non-complete data one cannot do this
> using the current null value. The NULL specified in the current TMDM
> draft is not the same as a NULL in SQL, i.e. it _not_ mean "unknown".
>=20
> I know that the XTM syntax allows the two values to be left out, but I
> would much rather like to see this "bug" be fixed than for it to make
> its way into the Topic Map Data Model.
>=20
> My view on this is that one should be draconian on this issue and
> require both properties. How can it hurt? I think it'll hurt people
> more by letting this change through.
>=20
> Geir O.
> _______________________________________________
> sc34wg3 mailing list
> sc34wg3@isotopicmaps.org
> http://www.isotopicmaps.org/mailman/listinfo/sc34wg3
--=20
Kal Ahmed <kal@techquila.com>
techquila