[sc34wg3] RM4TM SLUO : Objective or Requirement?
Fri, 22 Nov 2002 14:52:55 +0200
The following message was sent by "Marc de Graauw" <firstname.lastname@example.org> on Fri, 22 Nov 2002 13:09:39 +0100.
> * Bernard Vatant
> | 3.4.1 One subject for each node
> | "In topic map graphs, only nodes can represent subjects, and every node
> represents a
> | single subject." 
> | If I understand well the SLUO, out of RM prose and recent Steve Newcomb's
> | SLUO is not expressed by 3.4.1 but by the reverse:
> | "In a topic map graph, every subject is represented by a single node" 
> | That I can't find anywhere explicitly expressed in the document - did I miss
> | I assume 3.4.1. means what it says. If it is intended to express also the
> SLUO, it's a bug
> | to be fixed.
> 3.9 says:
> "In a well-formed topic map graph, every node represents a single subject, but
> some subjects may be represented by more than one node. In a fully merged
> topic map graph, every subject is represented by a single node."
> | OTOH if SLUO is only an Objective, it should be expressed by:
> | Recommendation:
> | "In a topic map graph, every subject *should be* (as far as possible)
> represented by a
> | single node" 
> I completely agree. SLUO can never be more than a (very important) design
> guideline. One can never be sure subjects are actually represented by only one
> node (topic) since human knowledge is only partial...
A quick comment on this issue:
Subject Identity Discrimination Properties allow the RM (an RM
conformant application) to determine whether two nodes 'have the same
subject' by comparing the values of their SIDPs according to the rules
defined in the governing TM Application Definition (for example the SAM).
If the result of this comparision is that the nodes represent the
same subject, the RM requires the nodes to be merged. It does not
require the nodes to be merged if 'subject equality' cannot be
calculated on the basis of the SIDP values and their semantics
as defined in the application definition.
I think that this is sufficiently expressed by the merging rules, but
possibly an addition to 3.4.1 could further clarify this. ( Steve? )
> sc34wg3 mailing list