<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>Den 9. nov. 2009 kl. 03.06 skrev Xuân Baldauf:</div><blockquote type="cite">
<div bgcolor="#ffffff" text="#000000">
(Example 2)<br>
<blockquote>drive(driver: Paul, from: Amsterdam, to: Rotterdam)<br>
walk(walker: Paul, from: Amsterdam, to: Rotterdam)<br>
ride_bike(bike_rider: Paul, from: Amsterdam, to: Rotterdam)</blockquote></div></blockquote></div><div><div>(Thanks for formulating this Xuan)</div><div><br></div></div><div><div>TMCL not efficiently supporting reuse of roles currently spells trouble for</div><div>any ZTM-support.</div><div><br></div><div><div><div>I usually just complain to or through Lars Marius but since he holds a different</div><div>opinion in this case and I found it interesting enough I tried to formulate our</div><div>intuition.</div><div><br></div></div></div><div><br></div><div><br></div><div>For what its worth:</div><div> I've interpreted the subject uniqueness objective to mean that one would</div><div>prefer to reuse role types across association signatures, much like Xuan's</div><div>second example. </div><div><br></div><div>When designing I find that we can always model more accurately and require ever</div><div>more fine-grained descriptions. Unfortunately it very soon becomes ceremony, a</div><div>“cognitive load” and an obstruction in eliciting data from our contributors.</div><div>Both input forms and visualization enter into this and we more than</div><div>occasionally find it convenient to group by role-type in one and</div><div>association-type in the other.</div><div><br></div><div>We've also found that our users sometimes prefer fuzzy meanings and that we,</div><div>somewhat counter-intuitively, get better data as a result. (That is partially a</div><div>function of how the topic map gets visualized as mentioned above.)</div><div><br></div><div><br></div><div>In previous (internal) discussions we've noticed that Lars Marius and Graham</div><div>advocate non-reuse whereas other luminaries have seemed to hold other</div><div>positions. </div><div><br></div><div>Until now I suspected this was caused more by the syntax they use to express</div><div>associations, rather than any defining feature or Topic Maps-trueism.</div><div><br></div><div>tolog at least, with its association predicated, puts the focus on the</div><div>association type:</div><div> composed-by(opera, composer)</div><div><br></div><div>whereas in ZTM, which can be thought of as a “topic-publishing-engine”, we</div><div>often think of our code as «standing» on a topic and viewing the rest of the</div><div>topic map from there by following associations:</div><div> alfano.associatedTopics(roletype=composed) # anything composed by Alfano</div><div><br></div><div>Combined with the challenge of building understandable user-interfaces this has</div><div>made the role-type prominent in our code and designs.</div><div><br></div><div><br></div><div>The “first-class-ness” and visibility of roletypes has lead us towards reuse.</div><div>Also I've thought that a particular subject used as a role-type does not exclude</div><div>it from being used as something else in other contexts. Author is an example</div><div>of something that we've seen as a topic type in one map and a role type in</div><div>another.</div><div><br></div><div>We think roletypes deserve a page of their own, the highest honour we can</div><div>bestow a subject in ZTM, as it makes the model visible and thus more likely to</div><div>be maintained and understood. Such pages typically list topics playing the role</div><div>along with other functions. They might even be the gateway to a particular view</div><div>of another subject.</div><div><br></div><div> /author/<person></div><div> /presenter/<person></div><div> /musician/<person></div><div><br></div><div>That said (written), we're always interested in improving the way we model. A</div><div>clearly argued recommendation or some way of sensing when it is okay to break</div><div>the rule would be much appreciated as it lets us migrate towards common</div><div>principles.</div><div><br></div><div><br></div><div>apologies-for-not-being-capable-of-making-this-shorter-ly yours</div><div> Arnar Lundesgaard</div></div></body></html>