- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Tue, 25 May 2004 14:17:17 +0100
- To: "Thompson, Bryan B." <BRYAN.B.THOMPSON@saic.com>, "''public-rdf-dawg@w3.org' '" <public-rdf-dawg@w3.org>
-------- Original Message -------- > From: Thompson, Bryan B. <mailto:BRYAN.B.THOMPSON@saic.com> > Date: 25 May 2004 13:54 > > Andy, > > I think where these examples fall short is that they presume a query > approach rather than assuming some sort of abstract model of variable > bindings for a result set. The first example is using a path model, > which is troubling given the syntactic freedom of RDF/XML and given > the opportunity to deliver a response in N3 or other notations. Actually Treehugger is not dependent on the serialization. The path is a path in the abstract syntax - the graph. Damian happens to have choosen a path-syntax that is like the stripped syntax as he is interested in FOAF data particularly. It interfaces the graph to Saxon. Why not ask Damian in rdf-interest? (and he reads the DAWG list :-) > The > second example presumes that we are using a specific query language > with looping constructs into which we can embed the XML that we want > to generate. I'm not sure why the looping constructs are a problem. XQuery is decalrive so a processor isn't constrained to execute the XQuery script as a program. XSLT has loops. > > What I have in mind is that variable bindings are generated by a query > against the RDF data model -- and that those bindings should expose a > (cannonical) abstract model of the query response SUCH THAT an XSL > processor can consume those bindings and people can reliable match > on the contents of the bindings in order to generate XML. Much in > the same way that XSL and XPath are connected by the notion of a > "node set" which is generated by XPath and consumed by XSL. If we aren't inventing a new transform language, we have to interface to whatever the existing tools. If we were inventing a new transform language, we would have that freedom. > > Maybe I am off base, but I guess the question is "If variable bindings > are the interface into the query result that we expose to the client, > can the client successfully use that interface to generate arbitrary > XML?" > > -bryan > > -----Original Message----- > From: Seaborne, Andy > To: Thompson, Bryan B.; ''public-rdf-dawg@w3.org' ' > Sent: 5/25/2004 8:27 AM > Subject: RE: Building a bridge from RDF to the web? > > > > -------- Original Message -------- > > From: Thompson, Bryan B. <mailto:BRYAN.B.THOMPSON@saic.com> > > Date: 25 May 2004 13:13 > > > > Andy, > > > > You wrote: > > > > > If that bridge is a way to extract information from RDF models and > > > get it into both XHTML (for people) and XML (for people and for > > > web services), then I agree with you. > > > > Variable bindings certainly seem to be a good place to start in order > > for the client to be able to avoid posing the query twice - once to > > the RDF store and once to the identified sub-graph (and possible using > > a different kind of query interface altogether!) > > > > So, can you outline for me how you see that variable bindings exposed > > by a DAWG protocol could be exploited by an XML Stylesheet so as to > > generate, e.g., an XHTML document? > > > > -bryan > > Rather than an on-the-fly design, how about from the examples of systems > that have tried this: > > --------------------- > > From: http://rdfweb.org/people/damian/treehugger/introduction.html > Treehugger example: > > <xsl:for-each > select="./rss:items/rdf:Seq/rdf:li/rdf:Resource"> > ... > do something with each member of the sequence > ... > </xsl:for-each> > > A path is Treehugger is property/class/property/class - I prefer a > property/property/property path but that isn't relevant here. > > So make/replace the "select" attribute be a graph pattern. Need to cope > with multiple variables in the query string. > > --------------------- > > From Jonathan Robie's talk: > http://www.w3.org/2004/Talks/tp-robie/slide4-0.html > > declare namespace rdf = "rdf.tagsalad.org"; > > for $artist in rdf:instance-of-class(rdf:predicate-domain("c:creates")) > let $artifact := rdf:join-on-property($artist, "c:creates"), > $museum := rdf:join-on-property($artifact, "c:exhibited") > return > <result> > <artist>{ $artist }</artist> > <artifact>{ $artifact }</artifact> > <museum>{ $museum }</museum> > </result> > > --------------------- > > Can one write in Xquery: > $var1 $var2 := someQueryFunction("graph pattern") > If so, then this would be a more compact form. > > Bryan - is this what you had in mind? > > Andy > > > > > > > -----Original Message----- > > From: Seaborne, Andy > > To: Thompson, Bryan B.; 'public-rdf-dawg@w3.org' > > Sent: 5/25/2004 6:39 AM > > Subject: RE: Building a bridge from RDF to the web? > > > > > From: Thompson, Bryan B. <> > > > Date: 24 May 2004 20:49 > > > > > > One of the issues that became clear to me during the recent WWW > > > meeting in NYC is that we are missing a bridge between the RDF model > > > and XML. In particular, people who are going to be using the > > > semantic web need a bridge from the RDF data model to application > > > specific XML vocabularies (actually, we need one that goes the > > > other way also, but that is, I think, a seperate question). > > > Perhaps the most common use case is querying an RDF resource and > > > using the results to drive an XSL Transform, which in turn might > > > generate XHTML. > > > > If that bridge is a way to extract information from RDF models and > > get it into both XHTML (for people) and XML (for people and for web > > services), then I agree with you. There isn't going to be one such > > form for presenting information extracted from RDF so tools such as > > XSLT and XQuery seem to be the toolsets to use. > > > > There has been some work on this: Rob outlined the use of XQuery and > > OWL data, and it reminded me of Jonathan Robie's presentation [1] at > > Cannes this year. The important aspect here is that access is to the > > abstract graph, not the RDF/XML syntax. > > > > Elsewhere, Howard talked about using paths to access the graph and > > Treehugger [2] does this by dymanically materialising an XML document > > from the RDF abstract graph. > > > > This is getting stuff out of RDF. The requirement it places on the > > WG, as I see it, is to produce a format for variable bindings that is > > easily digestable by other systems. That does not automatically mean > > an XML format because it is the output of XQuery functions but an XML > > format would work (it can be made streamable which RDF isn't). > > > > I have also seem people do queries in JSP taglibs to produce HTML and > > also using Velocity to create XHTML from RDF - a standard library to > > do the variable bindings to Velocity > > > > > > > > This issue has been more or less discussed in the context of > > > templates, which did not receive strong support at the first f2f as > > > a requirement for DAWG. > > > > IIRC the "Templates" discussion was slightly different. Its about > > constructing new RDF from information pulled from existing RDF. See > > the SeRQL 'construct' [3] operation or "cwm --filter". > > > > > However I think that NOT having this is going to be a major > > > stumbling block for adoption of the DAWG recommendation by > > > application developers and is going to make it very difficult to > > > get at that sense of loose coupling and content reuse that makes > > > the web so exciting. > > > > > > I would like to get a sense from people of how a DAWG spec could > > > best facilitate this. Do we need to do this ourselves? Can we > > > expose the data model query language in such a way that it can be > > > usefully applied by XSL Transforms? Should this be considered out > > > of scope for the charter? > > > > > > Thanks, > > > > > > -bryan > > > > [1] http://www.w3.org/2004/Talks/tp-robie/ > > [2] http://rdfweb.org/people/damian/treehugger/ > > [3] http://www.openrdf.org/doc/users/ch05.html#d0e1101
Received on Tuesday, 25 May 2004 09:17:39 UTC