Re: RDQL + DAWG = BRQL

thanks Andy the reply - some short follow up thoughts below..

On Jun 30, 2004, at 3:17 PM, Seaborne, Andy wrote:

> (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.

ok now it is clearer - it is rather meant to be a RDBC (RDF DataBase 
Connectivity) API level construct - but I am still not convinced how 
keeping it completely RDF specific would avoid users from using 
CONSTRUCT as a XQuery constructor to plug DAWG-QL tools into their 
existing XML workflow.

> 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.

+1 I agree fully

and the result set format should be XML "friendly" - in fact tools like 
TreeHugger might be valuable for better and more user-friendly 
integration of DAWL-QL into the existing XML infrastructure. Seeing RDF 
query results through XPath-ish glasses might be extremely handy for 
real-world XML developers - which might rather see plain XML XPath 
queries as a special case of more general and powerful RDF multi-edge 
queries.

>>> + 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.

sure sure - the EBNF is fine and I did not argue on that - I rather 
thought that using the same keyword for different (but similar) usages 
(source selection and context/quads filtering) might confuse the user.

>>> + 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.

ok clearer thanks

>
>> + 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.

good!


Alberto

Received on Monday, 5 July 2004 05:17:08 UTC