- From: Steve Harris <S.W.Harris@ecs.soton.ac.uk>
- Date: Mon, 21 Feb 2005 09:10:13 +0000
- To: "'RDF Data Access Working Group'" <public-rdf-dawg@w3.org>
On Sun, Feb 20, 2005 at 07:20:32 +0000, Andy Seaborne wrote: > >>2/ str(bNode) is an evaluation error > > > > > >Is it out of the question to get a string with the same form as a N3 bNode > >back? eg _:a. I'm not sure I'd argue for that, but I think that rejecting > >all solutions which feature str(?x) where ?x binds to a bNode will be > >inconvient and supprising in some cases. > > Would the str(bNode) => "" regardless of label be useful? It avoids > rejecting the solution or requiring a sprinkling of > > isBlank(?x) || str(?x) ... > > to change the sense of ?x being a bNode. Ah, I think I misunderstood the sense of "evaluation error" I took that to mean that str(?x) where ?x is a bNode will reject that solution. If isBlank(?x) || str(?x) will always succeed I dont think this is so much of an issue. Its a question for users though, really. > Exposing the internal bNode label seems inappropriate (and, as the label has > no meaning except to distinguish bNodes) meaningless. Otherwise str() and > isBlank() could be used to find a bNode again :-) I wasn't thinking it would be the internal name, more like the name we serialise to in CONSTRUCT with returned bNodes. > BTW - does it say somewhere that || and && only evaluate the RHS if the LHS > is false/true respectively? I dont remeber seeing any mention of shortcutting. - Steve
Received on Monday, 21 February 2005 09:10:17 UTC