- From: Bijan Parsia <bparsia@cs.man.ac.uk>
- Date: Tue, 12 Sep 2006 12:46:52 +0100
- To: Fred Zemke <fred.zemke@oracle.com>
- Cc: public-rdf-dawg@w3.org
This is in discharge of my action item to review and relate Fred's comments to current issues. On Aug 2, 2006, at 8:24 PM, Fred Zemke wrote: > > Master list of my comments > > In the telecon on 1 Aug 2006, I was asked to state which of my > comments I regard as closed. I also learned about the issue > list. Following up on the telecon, I have assembled > all my comments in this message (a very long one, I'm afraid) and > interspersed remarks (beginning with ++) on subsequent developments, > in many cases stating that the matter is closed in my mind. > > As for what is left, I would like to get the important issues > onto the issue list. Here is my proposed additions to the > issues list: > > 1. Material on entailment and general framework needs to be > rewritten. One objective of the rewrite is to extend the scope > of blank node identifiers to include FILTER clause in > rule [21] FilteredBasicGraphPattern. I thought kendall was going to open a catch all entailment issue. This should go there. > 2. Should we rearrange rule [14] SolutionModifier to place > OffsetClause before LimitClause, given that the OffsetClause > is processed first. This is not a currently open issue. Seems straightforward. > 3. Should items in the SELECT list be separated by commas. > I have heard that this is part of an existing issue on punctuation > which is being re-opened. Seems part of issue: http://www.w3.org/2001/sw/DataAccess/issues#punctuationSyntax > 4. Duplicates from UNION: do we require a result sequence to > have a precise count of duplicates, or is it more lax? I wonder if this is related to DISTINCT or just to the entailment framework. In so far as the DISTINCT issue also contains the "ALL" (default) case, i think it can be handled there i.e., in: http://www.w3.org/2001/sw/DataAccess/issues#formsOfDistinct > 5. The domain of solutions is not clearly specified. This is > particularly an issue for OPTIONAL and UNION. New issue to me, but perhaps falls under the semantics one. > 6. Formal semantics of OPTIONAL is not clear. The current > wording "if S is a pattern solution of A and of B otherwise > if S is a solution to A but not to B" appears to reduce > logically to just "S is a solution of A". This issue is > likely to be handled at the same time as the issue on the > domain of solutions to OPTIONAL, though I'd like to list it as > a separate issue. I think we should evolve the poorly named "nestedOptionals" issue to cover this. http://www.w3.org/2001/sw/DataAccess/issues#nestedOptionals But then the issues list needs to break out the various sub-bits. we might call it "semantics of optional) > 7. How does filter evaluation work if there is an unbound > variable that is not within a BOUND function? New to me. > 8. There is no bridge from the syntax to the semantics. I think this is in the enatilment one, but it's also a presentational matter. [snip] I have some replies/comments to/on Fred's detailed comments, but we should break them out. Cheers, Bijan.
Received on Tuesday, 12 September 2006 11:47:03 UTC