See also: IRC log
<LeeF> ACTION: AndyS to draft text recognizing the ambiguity [DONE] [recorded in http://www.w3.org/2007/10/16-dawg-minutes.html#action01]
<LeeF> ACTION: Chimezie to propose text to clarify that not all graphs in the dataset need to be disjoint/distinct [DONE] [recorded in http://www.w3.org/2007/10/16-dawg-minutes.html#action02]
<LeeF> 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 [DONE] [recorded in http://www.w3.org/2007/10/16-dawg-minutes.html#action03]
<LeeF> ACTION: LeeF to fix approval on dataset and graph tests [DONE] [recorded in http://www.w3.org/2007/10/16-dawg-minutes.html#action04]
<LeeF> ACTION: ericP to adapt impl report to include syntax tests [DONE] [recorded in http://www.w3.org/2007/10/16-dawg-minutes.html#action05]
<LeeF> ACTION: ericP to poke IETF folks about registering SPARQL media types (esp. application/sparql-query) [DROPPED] [recorded in http://www.w3.org/2007/10/16-dawg-minutes.html#action06]
<LeeF> ACTION: LeeF to investigate PR mechanics, put together draft transition request [CONTINUES] [recorded in http://www.w3.org/2007/10/16-dawg-minutes.html#action07]
<LeeF> results of WBS survey on PR
LeeF: the overall response is unanimous agreement to go forward
LeeF: there is a PR blackout until after the tech plenary
LeeF: one more week before sending out transition request
<LeeF> Every CONSTRUCT is DISTINCT ?
LeeF: this was raised by Bijan
LeeF: summary - Bijan's interpretation was that CONSTRUCT was not allowed to include duplicate triples - bad for implementations.
LeeF: follow-up interpretation was to directly take bindings and flesh out the CONSTRUCT template
LeeF: the query language spec doesn't make a stance on this - a serialization of the result may or may not have dupes
LeeF: Bijan provided example text
LeeF: I didn't think it was a query language issue
AndyS: A note doesn't belong in the query language specification - bad place for it
AndyS: this has been brought up before for the same implementation
AndyS: Bijan didn't raise the issue but was 'spec browsing' when he came across the 'issue'
AndyS: don't want to talk about what other serializations do
ericP: mildly opposed - not our place to dictate serialization of RDF graph
ericP: might cause more confusion than otherwise
LeeF: CONSTRUCT is defined WRT set union (implicit distinct)
AndyS: set union or rdf merge?
So it's set UNION WRT terms
<ericP> chimezie: so it's set-union WRT the label?
<ericP> AndyS: it's set-union WRT the nodes
<LeeF> suggested text
<LeeF> """
<LeeF> "Please note that due to serialization freedom, the serialized
<LeeF> results may contain, syntactically, duplicate triples. There is no
<LeeF> way in SPARQL to force the endpoint to return a syntactically
<LeeF> duplicate free CONSTRUCTed graph."
<LeeF> """
LeeF: inclined to leave it alone but discuss it with protocol editor (Elias)
<LeeF> text at the end of 8.2.3
<LeeF> """
<LeeF> The RDF Dataset for this query contains a default graph and two named graphs. The GRAPH keyword is described below.
<LeeF> The actions required to construct the dataset are not determined by the dataset description alone. If an IRI is given twice in an dataset description, either by using two FROM clauses, or a FROM clause and a FROM NAMED clause, then it does not assume that exactly one or exactly two attempts are made to obtain an RDF graph associated with the IRI. Therefore, no assumptions can be made about blank node identity in triples obtained from the two occurrences in the d
<LeeF> """
-> http://lists.w3.org/Archives/Public/public-rdf-dawg/2005AprJun/0301.html Re: Name of a graph? and FROM and FROM NAMED
[[
This is somewhat misleading, w.r.t.
web architecture, which says that <alice> identifies
a resource that has a representation that is a graph.
The query might be run twice and get two different answers
because the state of the <alice> resource changed; i.e.
it was represented by a different graph.
]]
<LeeF> converting graph patterns algorithm
LeeF: clarification of steps to form an algebra expression from a query string
scribe: WRT nested GGPs
... clarification helps, doesn't change semantics. As a chair,
I'm concerned about substantial change at the last moment.
LeeF: second alternative: have ericP and chimezie take an additional look at suggested changes by end of tommorow
<LeeF> ACTION: EricP to review reworked text for 12.2.1 Converting Graph Patterns and send comments by end of day Tuesday [recorded in http://www.w3.org/2007/10/16-dawg-minutes.html#action08]
<LeeF> ACTION: Chimezie to review reworked text for 12.2.1 Converting Graph Patterns and send comments by end of day Wednesday [recorded in http://www.w3.org/2007/10/16-dawg-minutes.html#action09]
-> http://www.w3.org/2001/sw/DataAccess/rq23/rq25.html#convertGraphPattern 12.2.1 Converting Graph Patterns (editor's draft text)
<LeeF> ACTION: EricP to review reworked text for 12.2.1 Converting Graph Patterns and send comments by end of day Wednesday [recorded in http://www.w3.org/2007/10/16-dawg-minutes.html#action10]
<LeeF> action -8
LeeF: if we are okay with pending changes, we should reply to the triggering comment (Frank?)
scribe: to complete disposition
of comments
... will send out 3 URLs for disposition of comments for the 3
specifications
LeeF: we might want to make a document with changelog highlights
LeeF: had an action to look at 7 tests (identified by Andy) effected by how FILTERs are introduced to LeftJoin expression
scribe: no set of Earl results were effected by incorrect interpretation
LeeF: Pellet report?
-> http://www.w3.org/2001/sw/DataAccess/tests/implementations SPARQL Implementation Coverage Report
<LeeF> protocol impl report
<LeeF> query results XML format impl report
<LeeF> DoC for query language
<LeeF> DoC for protocol
<LeeF> DoC for XML
<LeeF> transition request (very incomplete)
ericP: was granted space for that namespace. what documents do we put there?
scribe: all the WSDL/XSD/RELAXNG
LeeF: nice to have a canonical URL 'base'
scribe: one negative (don't personally care about). There are versions of these documents at persistent locations which would become deprecated
ericP: clarity is worth deprecating these locations
AndyS: no opinion
ericP: we can put stuff there now
<ericP> chimezie: i agree that having a common location outweighs the cost of changing implementaitons
ericP: would feel comfy with a WG decision about this
ericP: after a month, these locations will be permanent
ericP: if we find bugs at a latter point we follow a process similar to teh specs: errata ,etc..
<LeeF> PROPOSED: All SPARQL WSDLs, XSDs, and Relax NGs live in /2007/SPARQL, adjust spec pointers appropriately
LeeF: are we changing target namespace in addition to locations
consider namespace-8 (TAG issue) if we don't use the same location
<LeeF> ACTION: EricP to draft documents into /2007/SPARQL with namespace changes etc. for review next week [recorded in http://www.w3.org/2007/10/16-dawg-minutes.html#action11]
<LeeF> adjourned