- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Wed, 23 Feb 2005 14:59:55 +0000
- To: Bob MacGregor <bmacgregor@siderean.com>
- Cc: public-rdf-dawg-comments@w3.org
Bob MacGregor wrote: > Andy, > > Seaborne, Andy wrote: > > >>... snip ... >> >>To quote the current working draft: >> >>""" >>CONSTRUCT with a template >>... >>If any such instantiation produces a triple containing an unbound >>variable, or an illegal RDF construct (such as a literal in subject or >>predicate position) then that triple is not included in the RDF graph >>""" >> >>Only the triple involved, not the whole template, is skipped on >>unbound variables. >> >> Andy > > > I did read through it quickly, but you left out the part about the > optional warning. > > "then that triple is not included in the RDF graph, and a warning may > be generated." > > It would be very annoying (and just plain wrong) to generate a warning if > an unbound variable occurred in a template when it is sanctioned by an > OPTIONAL within a WHERE clause. Perhaps the spec should be rewritten to > say something like: > > "an unbound variable prevents the inclusion of the enclosing triple > in the RDF graph, while > an illegal construct (such as ...) also prevents the inclusion of a > triple and may > generate a warning" It seems likely that both cases, wanting warnings and not wanting warnings. If it is not expected that there will be unboudn variables in the template pattern, a warning is useful. Control of warnings would be down to the implementation - I guess you will choose not to issue a warning in this case - if teh query is being executed through some programming API. For the remote case, the working group has not decided how warnings get communicated over the protocol - query language document just says they are possible. > > So, given that unbound variables ARE OK (modulo spurious warnings) in a > template, > I fail to see why you had a problem representing trees with variable > depth -- perhaps > some other kind of variability is a problem, but templates can easily > generate trees > with different depths. The current template in a construct can only represent fixed length relationships so, with careful use of unbound variables, some variability is possible. But arbitrary depth can't be expressed - for example "all of this tree" for a tree of unknown bound of depth. This is characteristic of a restriction in SPARQL pattern matching as well and may turn out to be a limitation - reports from implementation experience in earlier systems is that while this does to arise, it is not often. A issue nearby is accessing RDF collections. Some questions like is X a member of list L can't be asked and we would like to hear of suggestions for this - one has been to use an inference rules (SPARQL queries an RDF graph howver that grah comes about). > > Cheers, Bob > Thanks for the comments, Andy
Received on Wednesday, 23 February 2005 15:17:36 UTC