W3C home > Mailing lists > Public > public-esw-thes@w3.org > March 2011

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

From: Christophe Dupriez <dupriez@destin.be>
Date: Tue, 15 Mar 2011 17:34:16 +0100
Message-ID: <4D7F9508.50701@destin.be>
To: Simon Spero <sesuncedu@gmail.com>
CC: Dan Brickley <danbri@danbri.org>, SKOS <public-esw-thes@w3.org>
Hi Simon!

I advanced with GraphViz and SKOS Thesauri display...

* 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!


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.
Received on Tuesday, 15 March 2011 16:34:15 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 March 2016 13:32:14 UTC