- From: Victor Porton <porton@narod.ru>
- Date: Sun, 06 Jul 2014 23:03:06 +0300
- To: Paul Tyson <phtyson@sbcglobal.net>
- Cc: Tim Berners-Lee <timbl@w3.org>, SW-forum Web <semantic-web@w3.org>
06.07.2014, 22:51, "Paul Tyson" <phtyson@sbcglobal.net>: > On Sun, 2014-07-06 at 22:32 +0300, Victor Porton wrote: >> š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. > > Then I did indeed entirely misinterpret your question. > > I don't know ADA, nor its tree data structure, so I should stay out of > this discussion. > > But as TimBL pointed out, common serialization formats for RDF are > already "tree-like". Why do those not work for you? It is irrelevant that serialization formats are tree-like. I am planning to use librdf (for which I am going to create Ada bindings) and it provides me data in plain triples (or quadruples). I need to construct a tree from triples. Ada probably does not provide a ready tree structure. I am just going to link together some records (as in a linked list but with a more complex structure). That you don't know Ada, does not make you unable to understand what I mean. Just replace "Ada tree structure" with your favorite language tree structure (Pascal tree structure, C++ tree structure, etc.) > Regards, > --Paul >> š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 -- Victor Porton - http://portonvictor.org
Received on Sunday, 6 July 2014 20:03:44 UTC