From: Seaborne, Andy <andy.seaborne@hp.com>

Date: Fri, 01 Jul 2005 16:27:09 +0100

Message-ID: <42C560CD.3050208@hp.com>

To: Geoff Chappell <geoff@sover.net>

CC: 'RDF Data Access Working Group' <public-rdf-dawg@w3.org>

Date: Fri, 01 Jul 2005 16:27:09 +0100

Message-ID: <42C560CD.3050208@hp.com>

To: Geoff Chappell <geoff@sover.net>

CC: 'RDF Data Access Working Group' <public-rdf-dawg@w3.org>

Geoff Chappell wrote: > >>-----Original Message----- >>From: Seaborne, Andy [mailto:andy.seaborne@hp.com] >>Sent: Monday, June 27, 2005 8:14 AM >>To: RDF Data Access Working Group; Geoff Chappell >>Subject: Refining Optionals >> > > [...] > > >>== Outline >> >>This is an informal description of definitions : it will need formalizing. >> >>We also require that in a group: >> >>?x = "junk" >>For this, we require that if ?x is not mentioned in BP then ?x solves the >>pattern of one of Opt1, Opt2 so writing Opt1 = OPTIONAL(P1) then ?x is a >>solution of some Pi. >> >>?x = unbound >>If ?x occurs in some Pi and BP.Pi has a solution, then a solution with ?x >>unbound is not considered a solution of the group. >> >>This looks as if it can be combined in to a condition for a group solution >>S >>involving ?x, where ?x is mentioned in some optional Opt(Pi), then ?x is a >>solution BP.Pi or no BP.Pj has a solution and ?x is unbound. This is now >>defining optional as a "solution extension" to solutions of the basic >>pattern in >>the group. >> >>Details still need to be worked out but I'd appreciate comments and >>feedback on >>the approach. > > > So by this approach, given data: > > :x1 :p1 :v1 > :x1 :p2 :v2 > > This query: > > optional {?s :p1 ?o1} optional (?s :p2 ?o2} > > would yield: > > ?s=:x1 ?o1=:v1 ?o2=:v2 Yes - that's what I think the application would expect. Optional is an extension of the results where possible. > > and not (e.g.): > > ?s=:x1, ?o2=:v2 > or > ?s=:x1, ?o1=:v2, ?o2=:v2 > > since ?o1 is bound in at least one of the optional patterns? I'd not expect these. The outline above treats each variable separately - the first has ?o1 unbound so but {?s :p1 ?o1} matched. The second has ?o1=:v2 but {?s :p1 ?o1} mentions ?o1 and is not solved by this. > > But then why not apply that same logic to unions? e.g > > {{?s :p1 ?o1} union {?s :p2 ?o2}} > > Would you expect the answer to be: > > (?s=:x1, ?o1=:v1), (?s=:x1, ?o2=:v2) > > or > > (?s=:x1, ?o1=:v1, ?o2=:v2) The former - mainly for consistency when the two branches of the union use the same variable. > > The unwanted results in the optional cases stem from the implied disjunction > in optional (A or not A), > so it might seem inconsistent to treat them > differently than unions. While "Optional" is "P or not(P)", it is also true that only one of the branches matches for any solution. Coudl you say why they are being treated differently? It seems its the additional conditions to force which of the branches to use. > But that seems a bit bizarre - i.e. why is: > > (?s=:x1, ?o1=:v1, ?o2=:v2) > > any more of a solution than: > > (?s=:x1, ?o1=:v2, ?o2=:v2) > > ?? Because {?s :p1 ?o1} is the only mention of ?o1 and it can't associate ?o1 with :v2. I'm trying to express the idea of "if you can add some information to a soltuion do so". > > > BTW, do you have an example of how nested optionals would be treated by this > approach? Good question! I believe, but can't prove yet, that nested optionals just work because the conditions strip off a level of optional and talk in terms of the pattern of the optional, so it recurses, applying the group conditions for the group of outer optional. > > > -Geoff Thanks for the reply - very appeciated AndyReceived on Friday, 1 July 2005 15:27:17 UTC

*
This archive was generated by hypermail 2.3.1
: Wednesday, 7 January 2015 15:00:48 UTC
*