See also: IRC log
<SimonR> We have regrets from Souri (from previous minutes) and PatH (http://lists.w3.org/Archives/Public/public-rdf-dawg/2007JanMar/0077.html)
RESOLUTION: accept 30 Jan minutes as a true record
RESOLUTION: accept 6 Feb minutes as a true record
Next Meeting: 20 Feb, scribe: EliasT
ACTION: [DONE] Lee to adapt text from 4.1.1 to specify how the protocol can contribute to the base IRI for query evaluation as per #relIRIs in the QL spec [recorded in http://www.w3.org/2007/02/13-dawg-minutes.html#action03]
ACTION: [DONE] LeeF to add Andy's bnode label scope tests to CVS as unapproved syntax tests [recorded in http://www.w3.org/2007/02/13-dawg-minutes.html#action05]
ACTION: [CONTINUES] AndyS to add text clarifying the prohibition on blank node labels in multiple BGPs to rq25 [recorded in http://www.w3.org/2007/02/13-dawg-minutes.html#action04]
ACTION: AndyS to add text clarifying the prohibition on blank node labels in multiple BGPs to rq25 [CONTINUES] [recorded in http://www.w3.org/2007/02/13-dawg-minutes.html#action06]
ACTION: EricP to run the yacker tool over and annotate the existing tests [CONTINUES] [recorded in http://www.w3.org/2007/02/13-dawg-minutes.html#action07]
ACTION: LeeF to remember that the wee, lost filter tests should be put [CONTINUES] [recorded in http://www.w3.org/2007/02/13-dawg-minutes.html#action08]
ACTION: Lee to talk to protocol editors re: POSTing application/sparql-query [CONTINUES] [recorded in http://www.w3.org/2007/02/13-dawg-minutes.html#action09]
LeeF's results for these tests
PROPOSED: to approve the syntax tests in data-r2/syntax-sparql4/manifest.ttl
APPROVED
re: base IRI and rfc 3986: 0067 and 0074
LeeF: most substantial issue was
the base IRI
... RFC3986 contains a series of resolution steps for base
URIs
... there was text in rq?? but not in protocol
LeeF: when drafting, I had a different interpretation than ericP
[[
if a URI was used to retrieve the
representation, that URI shall be considered the base URI
]]
... base URI should be HTTP
GET with query parameters at the end
... in the SOAP/POST query, it should be just the endpoint
<LeeF> Otherwise, the
<LeeF> "Retrieval URI" identified in 5.1.3, Base "URI from the Retrieval URI", is
<LeeF> the complete URL used to send a particular SPARQL query to a SPARQL
<LeeF> protocol service implementing the SparqlQuery
<LeeF> interface.Determining the Base IRI
<LeeF> Relative IRIs that appear in a [SPARQL] query are resolved against a base
<LeeF> IRI as per [RFC3986] section 5.1, "Establishing a Base URI". If present in
<LeeF> the query, the BASE keyword defines the Base IRI used to resolve relative
<LeeF> IRIs per RFC3986 section 5.1.1, "Base URI Embedded in Content". Otherwise,
<LeeF> Section 5.1.2, "Base URI from the Encapsulating Entity", defines how the
<LeeF> Base IRI may come from an encapsulating document, such as a SOAP envelope
<LeeF> with an xml:base directive. (See 2.3 SOAP Envelope.
<LeeF> If none of the above specifies the Base URI, the default Base
<LeeF> URI (section 5.1.4, "Default Base URI") is used.
<LeeF> (scratch that text, copy/paste issues)
http://service.exmaple/SPARQL?quer=..+++++...&named="sdfd3434554654#$$5"
WHERE { <.> ?s ?o }
<http://service.exmaple/SPARQL> or <http://service.exmaple/>
<EliasT> so the worry is simply if we explicitly say the endpoint URI and resolution is impacted by slashes we are in trouble.
<AndyS> Only case Lee and I found was <#foo>
<LeeF> http://lists.w3.org/Archives/Public/public-rdf-dawg/2007JanMar/0073.html
[[
The "Retrieval URI" identified in 5.1.3, Base "URI from the Retrieval URI", is the URL from which a particular SPARQL query was retrieved.
]]
<LeeF> from 1.2.2 (from Andy's email)
<LeeF> [[
<LeeF> ...
<LeeF> To use that access mechanism to perform an action on the
<LeeF> URI's resource is to "dereference" the URI.
<LeeF> When URIs are used within information retrieval systems to identify
<LeeF> sources of information, the most common form of URI dereference is
<LeeF> "retrieval": making use of a URI in order to retrieve a
<LeeF> representation of its associated resource.
<LeeF> ]]
does "from which a particular SPARQL query was retrieved." contradict using http://service.exmaple/SPARQL?quer=..+++++...&named="sdfd3434554654#$$5" as the base?
EliasT: no
"from which a particular SPARQL query was retrieved. (Please note XXX in the SPARQL Protocol.)"
<SimonR> Are we talking about where the query was retrieved from (e.g. an .rq file somewhere) or where the result set was retrieved from (the endpoint)?
<EliasT> SimonR: both, sort of.
<LeeF> SimonR, well we need the base IRI for the query... so the reading of 3986 should be the retrieval URI of the query -- but that could be either of your choices, right?
<SimonR> Well, no...I'd say it would be the first. If we were being super-pedantic.
<EliasT> right, but that's *if*, we currently don't support retrieving .rq queries.
<LeeF> If you're processing http://example.org/sparql?query=SELECT...
<LeeF> and I ask you for the retrieval URI of the query, is the correct answer "none" or "http://example.org/sparql?query=SELECT..." ?
<AndyS> If there is a secondary retrive to get the query then that is the new base. c.f.
<AndyS> SELECT FROM <http://example/daat
<AndyS> SELECT FROM <http://example/data> which resets the base for reading the FROM
<LeeF> 04 01If you're processing http://example.org/sparql?query=SELECT...
<LeeF> and I ask you for the retrieval URI of the query, is the correct answer "none" or "http://example.org/sparql?query=SELECT..." ?
base OR xml:base OR resolutionURI OR service-defined
| service-defined is advised to default to service?mush
<LeeF> [[
<LeeF> ...
<LeeF> To use that access mechanism to perform an action on the
<LeeF> URI's resource is to "dereference" the URI.
<LeeF> When URIs are used within information retrieval systems to identify
<LeeF> sources of information, the most common form of URI dereference is
<LeeF> "retrieval": making use of a URI in order to retrieve a
<LeeF> representation of its associated resource.
<LeeF> ]]
does "http://example.org/sparql?query=SELECT..." give a representation of a SPARQL query?
<SimonR> +1 to extend
i think rfc3986.5.1.3("http://example.org/sparql?query=SELECT...") gives a base URI for the result set
<LeeF> <h20>
<LeeF> <h2o>
{ ?chem :bondsTo <h2o> }
<AndyS> also FROM <data.rdf>
PROPOSED: base uri resolution in
sparql protocol comes from: base OR xml:base OR resolutionURI
OR service-defined where service-defined is advised to default
to service?mush
... The SPARLQ Protocol does not derefrence query URIs so 5.1.3
does not apply. Per 5.1.4, services must define their own base
URI, which may be the service invocation URI.
... ed(The SPARLQ Protocol does not derefrence query URIs so
5.1.3 does not apply. Per 5.1.4, services must define their own
base URI, which may be the service invocation URI.)
seconded by EliasT
APPROVED: SimonR abstains
<LeeF> ACTION: Elias to add wording for PROPOSED: ed(The SPARLQ Protocol does not derefrence query URIs so 5.1.3 does not apply. Per 5.1.4, services must define their own base URI, which may be the service invocation URI.) [recorded in http://www.w3.org/2007/02/13-dawg-minutes.html#action10]
LeeF: tx all for muddling through
this
... tx to SimonR for review start
... all: please keep the reviews flowing
<SimonR> Adjourned at 15:50 Z.