Re: Streaming version of CONSTRUCT

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