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