W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > April to June 2004


From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Wed, 30 Jun 2004 14:17:53 +0100
Message-ID: <E864E95CB35C1C46B72FEA0626A2E80803615F7D@0-mail-br1.hpl.hp.com>
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
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
    ( ?a rdf:type ns:Type1 ) 
    ( ?a ns:p2 ?b ) 
    ( ?a ns:p3 ?bb ) 
    ( ?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

Received on Wednesday, 30 June 2004 09:18:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:00:27 UTC