Re: GraphViz and SKOS... Conventions for visual schemas drafted from SKOS files?

Hi Simon!

I advanced with GraphViz and SKOS Thesauri display...
Example:
http://www.askosi.org/cobratoxin.png

* I kept features like shapes, colors, fonts, etc. for future 
enhancements (for instance, color for management status: to be revised, 
deprecated, etc.)
* Edges cannot be doubled (like you suggest) with GraphViz so I used 
solid lines for hierarchichal relations and dashed ones for EQs and RTs
    (and dotted for ommitted (out of focus) hierarchichal relations)
* I add a little empty circle to the arrow when the relation cross 
scheme boundaries (xxxMatch)

I propose you (and SKOS communities) a test for vizualisation and result 
discussion: designate me / send me a SKOS file and I would test its 
vizualisation with it and make the result available to the community.
One point: I graph from a "focus" concept, I do not graph the whole 
scheme (as this is is too often bewildering). With concept in 
polyhierarchies, I can also specify one hierarchy to focus on...

Have a nice day!

Christophe



Le 21/02/2011 20:21, Simon Spero a écrit :
> 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.
>
>