- From: Dan Brickley <danbri@w3.org>
- Date: Sat, 16 Mar 2002 11:59:06 -0500 (EST)
- To: Martin Gudgin <marting@develop.com>
- cc: "Williams, Stuart" <skw@hplb.hpl.hp.com>, Noah Mendelsohn <noah_mendelsohn@us.ibm.com>, XML Protocol Discussion <xml-dist-app@w3.org>, <em@w3.org>
On Sat, 16 Mar 2002, Martin Gudgin wrote: > ----- Original Message ----- > From: "Dan Brickley" <danbri@w3.org> > > On Fri, 15 Mar 2002, Martin Gudgin wrote: > > Anyway, re the ASCII art... > > > > > Per the encoding rules your second example ( relabeled ); > > > > > > <structA> > > > <edgeB>terminalB</edgeB> > > > <edgeC>terminalC</edgeC> > > > <edgeD> > > > <structE> > > > <edgeF>terminalF</edgeF> > > > <edgeG>terminalG</edgeG> > > > </structE> > > > </edgeD> > > > </structA> > > > > > > the resulting graph would look like this ( per the encoding rules > > > described ); > > > > > > > > > edgeB +-----------+ > > > +------>+"terminalB"| > > > | +-----------+ > > > | > > > +----+-----+ edgeC +-----------+ > > > |"nontermA"+------>+"terminalC"| > > > +----+-----+ +-----------+ > > > | > > > | edgeD +----------+ structE +----------+ edgeF +-----------+ > > > +------>+"nontermD"+-------->+"nontermE"+------>+"terminalF"| > > > +----------+ +----+-----+ +-----------+ > > > | > > > | edgeF +-----------+ > > > +------>+"terminalE"| > > > +-----------+ > > > > (I don't quite follow the detail example, since I don't see where > > TerminalE and nonTermD come from, but going from the XML above...) > > nonTermD is the node represented by element edgeD ( note this element also > represents edgeD ). TerminalE is a type, sorry. Should read terminalG and > the label should be edgeG ( that'll teach me to try and build ASCII art when > I'm tired! ) :) > > If we wanted to avoid having to exchange loads of ASCII art, the basic > > (source node, edge, target node) triples from the example above might > > could also be represented with something like: > > > > nontermA edgeB "terminalB" > > nontermA edgeC "terminalC" > > nontermA edgeD structE > > structE edgeF terminalF > > structE edgeF terminal > > > > ...ie we flatten the graph into its constituent node/edge/node triples > > Using your triples the graph would look like this; > > nontermA edgeB "terminalB" > nontermA edgeC "terminalC" > nontermA edgeD "nontermD" > nontermD structE "nontermE" > nontermE edgeF "terminalF" > nontermE edgeG "terminalG" OK, I had a crack at turning this into N-Triples so I could feed it to the GraphViz visualisation tool. See http://www.w3.org/2001/12/rubyrdf/examples/gudge/intro.html for N-Triples, .dot, SVG and PNG versions. Here's the N-Triples version. It differs only slightly from the syntax we've used here, by distinguishing (_:foo vs <foo>) between URI-labelled nodes and edges versions local identifiers. _:nontermA <http://example.com/s#edgeB> "terminalB" . _:nontermA <http://example.com/s#edgeC> "terminalC" . _:nontermA <http://example.com/s#edgeD> _:nontermD . _:nontermD <http://example.com/s#structE> _:nontermE . _:nontermE <http://example.com/s#edgeF> "terminalF" . _:nontermE <http://example.com/s#edgeG> "terminalG" . > More comments on your mail as I have time, thanks, look forward to it. Here's a question: does the N-Triples data file above contain everything that matters from the original SOAP Encoding, as far as the SOAP Encoding Data Model is concerned? If not, what's missing? (order? xml:lang language tagging?) > Gudge Dan
Received on Saturday, 16 March 2002 12:00:11 UTC