Re: [xsl] RDF graph to SVG force-directed layout

["Martynas Jusevičius martynas@xxxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

Hi Paul,

I wonder if that JSON-LD/d3.js code can be found anywhere? :)


Martynas
atomgraph.com

On Thu, Oct 15, 2020 at 3:16 AM Paul Tyson phtyson@xxxxxxxxxxxxx
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> I also thought of d3.js, but donbt know if it fits your overall
architecture or data flow.
>
> Years ago I experimented with json-ld from fuseki into a d3 client that
rendered very nice graphs. It showed great promise. But as it had no xsl, that
solution would be off-topic for this list.
>
> Regards,
> bPaul
>
> > On Oct 14, 2020, at 17:37, Liam R. E. Quin liam@xxxxxxxxxxxxxxxx
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
> >
> > o;?On Wed, 2020-10-14 at 21:01 +0000, Martynas JuseviD
ius
> > martynas@xxxxxxxxxxxxx wrote:
> >> Hi,
> >>
> >> could anyone suggest any optimizations to this stylesheet that
> >> transforms a graph encoded as RDF/XML to an SVG directed graph
> >> layout:
> >
> > without looking in detail - are you able to use d3.js in the browser to
> > do the fotce calulation part? It might not be faster but watching the
> > SVG objects  move  gradually into equilibrium has its own fascination.
> >
> > Most of these algorithms are likely to be at best O(nB2) C Niterations,
> > so there's some inherent  slowness.
> >
> > Looking slightly more  closely -
> > * consider using xsl:iterate instead of a recursive template at line
> > 282;
> > * run the stylesheet on the command-line and have Saxon write out
> > profiling information to see where the time goes
> > * add as= to any templates * variables that don't already have them
> > * use on-no-match="shallow-copy" on an xsl:mode declaration for
> > ac:SVTPositioning and delete the template on line 303
> > * consider using maps rather than elements during positioning, as
> > creating DOM elements in a browser is likely to be slow
> >
> > But an algorithm with worse than n^2 complexity is always likely to
> > have problems as n increases - the trick (as with e.g. QuickSort) is to
> > remember complexity is usually an average best case, and find values
> > for which the algorithm does better. E.g. removing nodes from
> > consideration when they stop moving under a certain amount each time.
> >
> > Liam
> >
> >
> > --
> > Liam Quin, https://www.delightfulcomputing.com/
> > Available for XML/Document/Information Architecture/XSLT/
> > XSL/XQuery/Web/Text Processing/A11Y training, work & consulting.
> > Barefoot Web-slave, antique illustrations:  http://www.fromoldbooks.org