DAWG agenda - Tues 9 Oct 2007 @ 14:30 UTC

0. Convene [1]RDF Data Access WG meeting of Tuesday, 9 October 2007
at 14:30:00 UTC
          + LeeF chairing
          + teleconference bridge: tel:+1.617.761.6200 
tel:+33.4.89.06.34.99 tel:+44.117.370.6152 code:7333
          + on irc at: irc://irc.w3.org:6665/dawg
          + Scribe: @@
          + Regrets:
          + roll call
          + minutes from last week [2]
          + Next meeting is 16 Oct 2007 @@ recruit scribe, regrets?
          + agenda comments?


1. Review ACTION Items

These actions appear DONE:

ACTION: AndyS to put replacement text for filter attachment into rq25
ACTION: ericP to implement the conservative algorithm (fail a test -> 
fail the feature) in the implementation report
ACTION: LeeF to mail out a complete test case to determine 
implementation behavior in the OPTIONAL+FILTER+{{...}} case
ACTION: LeeF to mark test in 0003 as approved, update test suite, notify 
implementors
ACTION: LeeF to solicit implementors' desired behavior for {{ ... }} case
ACTION: LeeF to solicit mechanically generated test results from pyrhho db
ACTION: LeeF to weed out basic facets from complex tests [DROPPED]

Let's check on the status of the following actions:

ACTION: LeeF to investigate PR mechanics, put together draft transition 
request
ACTION: LeeF to examine 7 tests affected by change in 
http://lists.w3.org/Archives/Public/public-rdf-dawg/2007JulSep/0177.html 
  in view of implementors' experiences
ACTION: ericP to adapt impl report to include syntax tests
ACTION: ericP to poke IETF folks about registering SPARQL media types 
(esp. application/sparql-query)

2. Query Language - @@

The CR and editor's draft both have the following in section 4.1.1

"""
@@Check this against the final grammar.
"""

Can this be checked and/or removed?


3. OPTIONAL + FILTER + {{ ... }}

Summary of the situation:

Do the following two query structures have the same semantics?

3a: ... ?x ... OPTIONAL { ... FILTER (... ?x ...) }
3b: ... ?x ... OPTIONAL { { ... FILTER ( ... ?x ... ) } }

I put together two test cases that demonstrate the two possibilities:

   #dawg-optional-filter-005-simplified (same semantics)
   #dawg-optional-filter-005-not-simplified (different semantics)

I solicited feedback on this from SPARQL implementors. Here is a summary 
of the feedback:

1 implementation (outside of the WG) currently does -simplified, but 
this implementor did not express a preference for the simplified case, 
and instead expressed a preference for as few special cases as possible.

3 implementations (outside of the WG) currently do -not-simplified, and 
all the implementors expressed a preference for -not-simplified.

I also solicited advice from Ralph S. vis a vis the effect of our 
decision on our schedule. He advises that if the WG is confident in a 
resolution, then we cango ahead and resolve the ambiguity and, as long 
as implementors who fail the resolved semantics are comfortable with it, 
argue to go straight to PR nonetheless. Alternatively, we can decide to 
note the ambiguity and leave the text spec. unchanged (and no approved 
test in the test suite). This is the appropriate choice if we are not 
confident in the right way to resolve this issue and do not feel that 
leaving it ambiguous hampers implementations and users of SPARQL.

If the WG is strongly in favor of -not-simplified, I will propose 
adopting that. Otherwise, I will propose noting the ambiguity and doing 
nothing.


4. same graph in default and named graph parts of RDF dataset

See: 
http://lists.w3.org/Archives/Public/public-rdf-dawg/2007OctDec/0012.html

Different implementations treat the occurence of <X> twice in the 
dataset (in the default graph and as a named graph) different with 
respect to blank nodes. Several tests in the dataset/ and graph/ 
directories rely on one specific interpretation. The above note proposes 
alternative tests that test the same features without assuming one 
particular behavior or other other.

Chimezie also asks if we should include a warning about this possible 
interoperability sticking point in the spec.

Let's resolve these tests and any new spec text.


5. SPARQL query PR materials

Impl report: http://www.w3.org/2001/sw/DataAccess/tests/implementations

Needs - syntax tests (EricP), REDUCED information (LeeF), all green 
boxes (EricP / LeeF)

DoC: http://www.w3.org/2001/sw/DataAccess/doc-ql-cr

Needs - nothing?


6. SPARQL protocol PR materials

Impl report: http://www.w3.org/2001/sw/DataAccess/impl-report-protocol

Needs - Different treatment of QueryRefused (a la REDUCED) (LeeF), is 
SOAP treatment ok? (DAWG)

DoC: http://www.w3.org/2001/sw/DataAccess/doc-protocol-cr

Needs - Resolution of 2nd comment regarding @schemaLocation (DAWG, LeeF)


7. SPARQL XML result format materials

Impl report: (not yet)

Needs - to be assembled (LeeF)

DoC: http://www.w3.org/2001/sw/DataAccess/doc-xml-cr

Needs - nothing


8. PR Decision

We're going to run a one-week WBS if critical mass on telecon thinks 
we're ready for PR.


9. SPARQL Testimonials



[1] http://www.w3.org/2001/sw/DataAccess/
[2] 
http://lists.w3.org/Archives/Public/public-rdf-dawg/2007OctDec/att-0006/02-dawg-minutes.html

Received on Tuesday, 9 October 2007 03:32:30 UTC