- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Wed, 30 Jun 2004 14:17:53 +0100
- To: RDF Data Access Working Group <public-rdf-dawg@w3.org>
- Cc: "'Asemantics Staff'" <staff@asemantics.com>
(For clarity, I've removed the parts of Alberto's message that I'm not addressing in this reply). -------- Original Message -------- > From: Alberto Reggiori <mailto:alberto@asemantics.com> > Date: 29 June 2004 18:06 > > > Features: > > > > + New result form: CONSTRUCT > > +1 useful > > but, we are wondering whether or not this would require full XML > well-formed syntax support in CONSTRUCT then, for example when the > query results/output would contain rdf:parseType="Literal" literal > values (i.e. including entities, XML escapes, attributes and so on) > i.e. more like XQuery constructors. Of course, if we would require the > CONSTRUCT clause to be used to "build" simpler RDF graphs without > requiring those to be in XML format this would not be a big issue (or > escape those using N-Triples or Turtle canonical XML syntax then?). > Simpler design is better perhaps - but we might need to re-consider > this more once users and developers will start using BRQL for > real-world Web/XML applications. The CONSTRUCT clause builds an RDF graph as an abstraction - it is not generating serialized syntax so the issue of XML does not arise. It does not allow the construction of new literals, only new triples. The output is a RDF graph which may be passed to an application directly (local case) or serialized as request in the protocol (RDF/XML, N3, N-Triples, Turtle, TriX,...). How the serialization occurs (rdf:parseType="Literal", entities, XML escapes, attributes) isn't a matter for the CONSTRUCT clause. To construct arbitrary XML, my personal favourite approach is for a DAWG-QL query to output an XML-based result set (i.e. variable bindings) and process that in XQuery/XSLT. This allowed both integrated use where a DAWG processor is embedded inside a XQuery system and remote use where an Xquery process makes a remote request, gets back XML and processes that. > > Concerning about a more syntax aspect of BRQL, perhaps AS keyword could > be used as a synonym for CONSTRUCT for read-ness. > > > + Triple source identification (sometimes known as "quads") > > +1 very useful feature > > even though we wonder whether or not the use of SOURCE keyword for > quads would clash with the current FROM synonym to specify the input > source to query from (e.g. select ?foo ?bar source my-foo-bar.rdf where > (?foo....) using bar for <>.....) - perhaps DOMAIN, GRAPH or NAME > keywords could be used instead for quads? Firstly - the syntax in the document is merely to illustrate the features. It is heavy on the new features when a proper syntax would not. (background: SOURCE is a synomyn for FROM but is rarely used). FROM/SOURCE has to occur before any triple patterns, and then only once. So the SOURCE keyword does not clash because every clause in introduced by a keyword (SELECT, FROM/SOURCE, CONSTRUCT, DESCRIBE, WHERE, OPTIONAL, AND, USING) and there can't be a nested SOURCE clause. This is true for both top down and bottom up parsing styles. > > > + Optional triple matching > > +1 very useful > > what about using '[]' (square brackets) around triple-patterns > themselves as an alternative to spell out the OPTIONAL keyword? or use > instead a '?' (question mark) in front of a triple-pattern to express > that it is optional? i.e. more UNIX like and familiar to developers - > see also > http://lists.w3.org/Archives/Public/www-rdf-rules/2003Apr/0030.html for > some old ideas along those lines. > > More, it is not clear at the BRQL syntax level how to "group" > triple-patterns by the "optional" clause i.e. using nested parenthesis > or use braces to > group sources vs. repeated keywords The OPTIONAL clause is like WHERE - a list of triple patterns: SELECT ?a ?b ?bb WHERE ( ?a rdf:type ns:Type1 ) OPTIONAL ( ?a ns:p2 ?b ) ( ?a ns:p3 ?bb ) OPTIONAL ( ?a ns:q ?q ) so the clauses are terminated by the next clause keyword. > + allow '$' (dollar sign) as an alternative to '?' on variables (or > better replace it due to clashing with SQL interface usage of '?' for > 'placeholders and bind values' - see for example DBI interface > http://www.perl.com/lpt/a/2001/03/dbiokay.html#placeholders ) Useful experience note there. > > Yours > > Alberto Andy
Received on Wednesday, 30 June 2004 09:18:10 UTC