parid0026 | Fri, 29 Nov 2002 08:32:15
I share Bernard's concern about the kind of graph we end up with,
because an ISO standard is for everyone, not just for current
implementers. It would be good to be able to use established
mathematical techniques to gain assurance that the RM graph has nice
rather than nasty properties for future implementers.
parid0026 | Fri, 07 Feb 2003 17:05:41
A topic map graph consists of nodes and arcs. In a well-formed topic map graph, every arc is a typed, oriented connectedness of two nodes, and every node is one of the two endpoints of zero or more arcs.
reform to remove all references to "connectedness" and replace with relationship/s.
The "neologism" of connectedness appears to serve two purposes: 1. to not necessitate a data structure in a TM Application and, 2. to distinguish between "aspects of the structure of assertions" (I read as "subjects") that are nodes and those that are arcs. The notion of relationship works as well, provided it is stated that the relationships represented by arcs have no subjects, unless reified as nodes, and the relationships represented by nodes do have subjects. Seems simpler to define the distinction once and to not coin unfamiliar terms to make the distinction. (On the data structure question, simply make the statement that arcs do not imply any particular data structure.) (Note the term "connectedness" 24 times in the text, at parid0026, parid0932, parid0506, parid0907, parid0058, parid0056, parid0061, parid0063, parid0065, parid0067, parid0069, parid0071, parid0073, parid0075, parid0076 (twice), parid0908, parid0910, parid0909 (four times), parid0146, parid0209.) I will be submitting separate comments on each of these paragraphs with suggested new language.
parid0026 | Fri, 07 Feb 2003 17:05:41
In order to maintain the integrity of merged topic maps, it is necessary to establish a common structure for all assertions. In this RM4TM, the decisions as to which aspects of the structure of assertions should be "reified" as nodes, and which aspects should remain "unreified" as arcs, were made by distinguishing between the aspects of assertions that are substantive with respect to the relationships that they assert (and that could conceivably, therefore, need to become role players in other assertions about those relationships), as opposed to the aspects of assertions that nobody would want to make other assertions about unless they were discussing the design of assertions in general. In the structure of assertions set forth in this RM4TM, the former aspects are represented by a-nodes and c-nodes, while the latter aspects are represented as the four types of arcs (the "eight forms of connectedness")
reform to remove all references to "connectedness" and replace with relationship/s.
The "neologism" of connectedness appears to serve two purposes: 1. to not necessitate a data structure in a TM Application and, 2. to distinguish between "aspects of the structure of assertions" (I read as "subjects") that are nodes and those that are arcs. The notion of relationship works as well, provided it is stated that the relationships represented by arcs have no subjects, unless reified as nodes, and the relationships represented by nodes do have subjects. Seems simpler to define the distinction once and to not coin unfamiliar terms to make the distinction. (On the data structure question, simply make the statement that arcs do not imply any particular data structure.) (Note the term "connectedness" 24 times in the text, at parid0026, parid0932, parid0506, parid0907, parid0058, parid0056, parid0061, parid0063, parid0065, parid0067, parid0069, parid0071, parid0073, parid0075, parid0076 (twice), parid0908, parid0910, parid0909 (four times), parid0146, parid0209.) I will be submitting separate comments on each of these paragraphs with suggested new language.