- From: Simon Spero <sesuncedu@gmail.com>
- Date: Mon, 21 Feb 2011 14:21:31 -0500
- To: Christophe Dupriez <dupriez@destin.be>
- Cc: Dan Brickley <danbri@danbri.org>, SKOS <public-esw-thes@w3.org>
Received on Monday, 21 February 2011 19:22:04 UTC
EQ-types might be represented as multiple lined variants, by analogy to = ≃ ≣ ≡ etc. Related terms can appropriately be represented by a line with arrows on each end.[1] I haven't done a lit review on how well this visualization style might work, let alone done any tests, so these are thoughts off the top of my head. I think I might try generating some samples (if the code hasn't bit-rotted) even if I don't have time to jump through IRB hoops. There may be pre-defined UML notation that can be punned (related could be lines with no arrows), but I'm not sure how cognitively inutitive a lot of UML notation is. Simon [1] Ironically, in the machine translation of LCSH to a thesaurus, the algorithm used to decide whether to generate an RT link, or a BT link, was: When there is a see also link from A to B { if there is a see also link from B to A { add an RT link from A to B add an RT link from B to A } else { add a BT link from A to B } } This would have worked perfectly if the data had been entered entirely in accordance with policy, but since each see also reference was keyed in separately, any errors cause RT links to be turned in to much more semantically constrained BT links.
Received on Monday, 21 February 2011 19:22:04 UTC