Re: CONSTRUCT / template merging.

Pat Hayes wrote:
>>
>> The intent of the CONSTRUCT is that it should not create two different 
>> bNodes:
> 
> 
> Yes, OK, I see that now. So  right, the language to use is that the 
> result is the/ union/ of the pattern instances, not the merge.

Corrected.

> 
> However, there are some more issues with CONSTRUCT.
> 
> First, there is the issue of whether the pattern after the CONSTRUCT is 
> allowed to contain bnodes.  Patterns are not allowed to contain bnodes; 
> and yet in an earlier email you seemed to be saying (?) that the pattern 
> pat1 in
> 
> CONSTRUCT pat1 WHERE pat2
> 
> can contain bnodes. If so, it's not a pattern as we have defined it; and 
> since it can contain variables its not a graph, so it will have to be an 
> entirely new kind of thing. Which is OK, we can do that, but we need to 
> be clear (I need to be clear). So, what's the story here? Bnodes allowed 
> in pat1 or not?

Yes - constructed bNodes should be allowed. I've started changing the text to 
talk about "templates" in CONSTRUCT, rather than a pattern.  This allows us to 
have something in templates that can't be in patterns - although I'd note that 
_:a is a legalXML 1.1 qname.

> 
> Second, what do we do if there is an instance mapping S for pat2 such 
> that S(pat1) is not a legal RDF graph? For example:
> 
> CONSTRUCT (ex:a ?x ex:b) WHERE ?y foo ?x
> 
> with a target containing the triple
> 
> ex:aa foo "13"^^xsd:number .
> 
> which would try to put a literal into the predicate position. As we have 
> defined it, this would be a legal pattern instance, but it wouldn't be a 
> legal RDF triple. So what gets constructed in a case like this?

Would ot work so that, like when there is an unbound variable, the individual 
triple template is skipped, although the rest of the template is still processed 
for the solution.  Alternative, the whole substitution based on this solution 
could be not done.  My goal is consistency here - I am not concerned which way 
we go as long as we do it clearly.

> 
> More generally, why do we restrict pat1 to be RDF in particular? Wouldnt 
> it make sense to allow any kind of text to be constructed here?

Just that the result has to be an RDF graph.

Coupled with the protocol aspect of our work, where RDF graphs get serialized, I 
am not keen on defining a spec with things outside RDF.  I'd just leave it to 
extensions and no claim of being "SPARQL".

> 
>> Now "CONSTRUCT * WHERE pattern" is supposed to be a shorthand for 
>> using the pattern as the template:
> 
>> "CONSTRUCT pattern WHERE pattern"
> 
> 
> OK, that makes sense. Id suggest then introducing the longer form first 
> in the document and then explaining the '*' case exactly in this way.

Good suggestion

> 
> Pat

	Andy

Received on Thursday, 6 January 2005 14:53:50 UTC