W3C home > Mailing lists > Public > semantic-web@w3.org > July 2014

Re: Transforming RDF into (non-binary!) trees

From: Jean-Claude Moissinac <jean-claude.moissinac@telecom-paristech.fr>
Date: Wed, 9 Jul 2014 15:00:01 +0200
Message-ID: <CAP8HVi2fMvp4vdxhzH3Mhfx=LbxNSY0zdmHm5sDC9uwH+Nweew@mail.gmail.com>
To: "Eric Prud'hommeaux" <eric@w3.org>
Cc: Paul Tyson <phtyson@sbcglobal.net>, Victor Porton <porton@narod.ru>, SW-forum Web <semantic-web@w3.org>
My view

generally
- an RDF document defines a graph (perhaps with disconnected parts)
- a graph is not a tree

So, what we need is some tree views on the graph
A same graph can be used to generate several views
So, for each view, I need some implicit or explicit rules to define what
the view will be

The case is common to build user interaction on an RDF graph.
I've a sample described here
http://onsem.wp.mines-telecom.fr/2014/03/18/web-visualization-of-a-simple-ontology/
visible here
​​http://givingsense.eu/demo/bloomdisplay/d3TreeBloom.htm

For that sample, I get a json-ld representation of my graph.
Then, I use rules like (simplified version)
 childrenFinder = function(node) {
             var j=0;
             var children = new Array();
             root["@graph"].forEach(function(n, i) {
                 if (n.subClassOf["@id"]===node["@id"]){
                     children[j] = n; j++;
                 }
               );
             }
             return children;
           };

 to find childrens of a node

​To generalize the method, I think we need:
* a starting node in the graph, which will be the root of the tree
* a rule to find children of a node; a generic rule could be:
for a node of type T, the children are found by following predicates (P1,
P2, ... PN)​ and selecting objects node following conditions (C1, C2...CN)
other nodes linked to a node of the tree are either ignored or taken as
'value' of the node

What do you think of that generic approach?

--
Jean-Claude Moissinac
Received on Wednesday, 9 July 2014 13:00:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 07:42:52 UTC