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

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

From: Neubert Joachim <J.Neubert@zbw.eu>
Date: Wed, 16 Mar 2011 12:33:13 +0100
Message-ID: <3A59BB6451C972429019B12996F92DAD048FA005@frodo.zbw-nett.zbw-kiel.de>
To: "Christophe Dupriez" <dupriez@destin.be>
Cc: "SKOS" <public-esw-thes@w3.org>
Hi Christophe,
 
Great work! 
 
I'd love to see some concepts from STW rendered like this, e.g. http://zbw.eu/stw/descriptor/13723-2 (Financial market). The whole SKOS file is for download at http://zbw.eu/stw/versions/latest/download.

 
One thing which is special in STW: It has a systematic part, which forms an own hierarchy in addition to the standard descriptor - descriptor relations. Don't know if and how this could be expressed - maybe by assigning different shapes (for type zbwext:Thsys and zbwext:Descriptor).
 
Cheers, Joachim
 


________________________________

	Von: public-esw-thes-request@w3.org [mailto:public-esw-thes-request@w3.org] Im Auftrag von Christophe Dupriez
	Gesendet: Dienstag, 15. März 2011 17:34
	An: Simon Spero
	Cc: Dan Brickley; SKOS
	Betreff: 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. 

		  

		   


Received on Wednesday, 16 March 2011 11:33:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 16 March 2011 11:33:53 GMT