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

The thing I want is to fill a tree (represented as an Ada data structure) with data from RDF (validating it by the way).

The tree in Ada is a skeleton, it should fill with RDF data like meat.

I am not inclined to study SPARQL and use it (or any similar language). I want the data structure (and validator) to be represented as a "native" Ada tree data structure. One reason for this is to make it fast.

06.07.2014, 22:27, "Paul Tyson" <phtyson@sbcglobal.net>:
> On Sun, 2014-07-06 at 17:14 +0100, Tim Berners-Lee wrote:
>> šOn 2014-07 -06, at 16:46, Paul Tyson <phtyson@sbcglobal.net> wrote:
>>> šOn Sat, 2014-07-05 at 22:35 +0300, Victor Porton wrote:
>>>> šI think we should write some code which would transform RDF into a tree
>>>> š(not necessarily binary! utilize nameless nodes as nodes with N
>>>> šchilds) and also check the number of branches of a certain kind
>>>> š(usually 0..1 or 1..1).
>>>>
>>>> šHas anyone done a similar job?
>>> šI have not done that in RDF, but recently I had to generate optimal
>>> šspanning trees [1] from a directed acyclic graph (DAG). It occurred to
>>> šme that a similar technique could be applied to RDF if you first omitted
>>> šcycles from the RDF graph (perhaps by introducing blank nodes).
>>>
>>> šOne approach would be to put the spanning tree (however you choose to
>>> šdefine it) in one named graph, and all the other "non-tree" triples in
>>> šanother named graph.
>>>
>>> šThis would make it easier to apply conventional block-and-line layout
>>> šstyles (using XSL or CSS) to the spanning tree, and use the non-tree
>>> šlinks to "decorate" the format (e.g. using hyperlinks or other
>>> šinteractive behavior).
>>>
>>> šYour use case might be quite different than mine. I am motivated by the
>>> šproblem of applying formatting style to RDF graphs. Since conventional
>>> šlayout techniques for screen and paper have a tree-based target model
>>> š(pages/screens,blocks,lines,characters), somewhere in the process you
>>> šmust find or make a tree from your graph-based data. By specifying how
>>> što construct one or more useful (i.e., "meaningful for formatting")
>>> šspanning trees from a given RDF graph, you achieve greater flexibility
>>> šand transparency in the process.
>> šAny serializer to turtle, etc, produces a tree in the process.
>
> I assumed the original poster wanted a spanning tree of the RDF graph,
> not just a tree-like serialization of the RDF graph. This would require
> omitting all but one triple from each set of triples that have the same
> object.
>> šFor example, the serializer in rdflib.js uses the same algorithm for
>> ššserializing turtle/N3, rdf/xml and also a form of graphical HTML
>> ššlayout the tabulator project uses for a "data view" of rdf resource.
>> ššThis latter also represents quoted graphs of N3 as rounded-corner
>> ššbubbles around the graph, and is useful for vizualising at rule files.
>> šhttps://github.com/linkeddata/rdflib.js and specifically
>> ššhttps://github.com/linkeddata/rdflib.js/blob/master/serialize.js for
>> ššthe serializer and
>> ššhttps://github.com/linkeddata/tabulator/blob/master/js/panes/dataContentPane.js
>> šfor the code which generates the graphical view.
>
> Since it is trivial to construe any DAG as a tree, I did not think that
> is what the original question was about. Rather, I took the question as:
> "of all the possible spanning trees implicit in an RDF graph, are some
> more useful (e.g., more 'meaningful') than others, and if so how best to
> specify and construct them?". (It is quite likely I did not get the
> question right.)
>
> I interpreted the question thus because a problem that is looming in my
> work is how to tame the "great blooming, buzzing confusion" that comes
> at you from any nontrivial RDF query. Solutions such as Tabulator tame
> the confusion by presenting the graph as linked hierarchical views of
> property lists, which is fine for data geeks but not attractive or
> optimal for many business uses. Custom queries and transformations can
> provide effective interfaces but are tedious to build and maintain, and
> can limit users' interaction with the data. By introducing the ability
> to specify a meaningful spanning tree into the query-transform process
> we get another control point with which to enrich and style the raw RDF
> data for particular business purposes. We will also have provided a
> declarative bridging mechanism between the web of data and the web of
> documents (to the extent that our specified spanning trees are
> "document-like").
>
> Regards,
> --Paul
>> šIn general, a graph may have disconnected parts and so may have to be serialized to more than one tree.
>>
>> š(Note that if you allow N3's šreverse arc syntax š( šš<#a> is :child of
>> ššš<#b> ) the you can serialize any acyclic graph to turtle without
>> ššhaving to generate arbitrary identifiers for blank nodes, just using
>> ššthe turtle [ ] šsyntax. ššThat is one reason why it was a shame that
>> ššthe reverse syntax was omitted from Turtle. šššThe serializer above
>> ššdoes not use the reverse link syntax in its output, so it generates a
>> šštree of forward links. šThis goes against a šmaxim of mine that
>> ššforward links are not treated special over backward links in RDF...
>> ššbut I digress.)
>>> šI suppose such a system could be implemented with SPARQL, but it would
>>> šbe nice to have a non-SPARQL declarative syntax for specifying the
>>> šspanning tree. RIF might work.
>>>
>>> šRegards,
>>> š--Paul
>>>
>>> š[1] http://en.wikipedia.org/wiki/Spanning_tree
>>>> šI am working for bindings librdf for Ada2012. I could write such code
>>>> šdirectly in Ada (so it may be easier), but better would be to make C
>>>> šinterface for this. I may write in Ada and leave TODO note "port it to
>>>> šC".
>>>>
>>>> šAny response?
>>>>
>>>> š--
>>>> šVictor Porton - http://portonvictor.org

--
Victor Porton - http://portonvictor.org

Received on Sunday, 6 July 2014 19:33:13 UTC