- 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