<scribe> scribenick: AndyS

<AlexPassant> AxelPolleres: SimonS should be there

<AxelPolleres> scribe: Andy

<AxelPolleres> Link to Agenda: http://www.w3.org/2009/sparql/wiki/Agenda-2009-03-24

Admin

<AxelPolleres> PROPOSED: Approve minutes at http://www.w3.org/2009/sparql/meeting/2009-03-17

Next time: telecon is 15:00 GMTDT

scribe: back to normal now timezones shifted everytwhwre that's going to.

<AxelPolleres> RESOLVED: Approve minutes at http://www.w3.org/2009/sparql/meeting/2009-03-17

Scribe next time: Souri

F2F

AndyS: Videoconf tested: Bristol - MIT

Axel: Any concerns for a 2 site F2F?

<SteveH> Bristol is good for LukeWM and SteveH

<AxelPolleres> Bristol

<AlexPassant> Bristol would be ok for me

<SimonS> Bristol

<kasei> MIT

AndyS: Bristol

<JacekK> UIBK would probably prefer Bristol

<john-l> Most likely site would be Cambridge

<ywang4> i will be in cambridge

<LeeF> I'll be in cambridge

<scribe> ACTION: Axel: To ask EricP to setup a WBS for the F2F [recorded in http://www.w3.org/2009/03/24-sparql-minutes.html#action01]

<trackbot> Created ACTION-1 - Ask EricP to setup a WBS for the F2F [on Axel Polleres - due 2009-03-31].

Liasons

Orri: RDB2RDF - no WG just yet - chartering started

<AxelPolleres> http://www.w3.org/2009/sparql/wiki/Category:Features

No new features added.

<AxelPolleres> subtopic: Parameters

<AxelPolleres> http://www.w3.org/2009/sparql/wiki/Feature:Parameters

Orri to present

Variable bindings.

Majority use named variables but other systems do differentiate (for checking)

Virtuoso has used this with BSBM (which has many small queries) to some advantage

Orri: allows caching query planning

<Souri> This is similar to bind variables

<AxelPolleres> argument for distinction: distinguish required parameters that must be bound?

EricP: simple is to substitute for the variable value.

<kasei> ericP's FeDeRate work seems like a generalization of this, but with changes to sparql syntax

<Zakim> kjetil, you wanted to ask if there are other ways to do it?

kjetil: are there other ways?

Orri: yes but this is understood

<Zakim> ericP, you wanted to ask relative importance to e.g. update

<SteveH> it depends on the capability of your optimiser, comprehensive ones won't always be able to reuse the parse tree

EricP: how important is this to Orri?

Orri: update is more important but this is most important on protocol.

<SteveH> -1

<kjetil> +1

<AlexPassant> 0

<kasei> +1

<john-l> +1

<Souri> 0

<chimezie> +1 (brings SPARQL protocol that much closer to typical HTTP behavior)

<JacekK> +1

<AxelPolleres> 0

<ericP> -1 (have other priorities)

<iv_an_ru> +0.5

<SteveH> LukeWM: -1 (FWIW

<SimonS> +1

-1 (unclear alternatives)

<LeeF> 0

<ywang4> 0

<LeeF> To me, standardizing parameters seems to have a modest but not huge interoperability benefit, fwiw/.

<SteveH> LeeF, not if we get it wrong

<SteveH> sorry, LeeF,

<LeeF> SteveH, acknowledged

<chimezie> I think the argument for closer interaction with HTTP and the query language is a stronger argument for me

<SteveH> [to repeat what I said on the phone] the current implementations have serious side effects

Axel: Orri, please send email about this.

<LeeF> chimezie, I like that one too, in general, but it's less motivating (to me, personally & as chair) as a reason to work on standardizing it ahead of other things with greater interop benefits :)

<AxelPolleres> Orri: +1 to parameters

<AxelPolleres> subtopic: Query by reference

Axel: may be related to parameters

<AxelPolleres> http://www.w3.org/2009/sparql/wiki/Feature:Query_by_reference

<iv_an_ru> I'd add that params may make text more readable, esp. when their values are very long literals.

Axel: sent by Leigh Dodds
... ability to send a URI to the query, not the query itself.

<SimonS> +q

SteveH: issues of security

<ericP> SteveH: not sure why it matters except in massive queries

<chimezie> I agree on that point as well

<ericP> SimonS: limited use compared to security probs

Simon: useful if refer to views and combine with parameters

<ericP> ... perhaps has more value when combined with views or parameters

Simon: else less value

<iv_an_ru> I'd prefer "include" for views.

Orri: A view is (like) a subquery

<chimezie> The general security concern of executing external 'code'

<chimezie> especially now we might have update support

Simon: security: server is pulling external input

<iv_an_ru> +1 to chimezie

<SteveH> the external request will be coming from the SPARQL processor machine, which may have IP=based security

<ericP> SteveH: the request is issued by sparql processor which may be inside a firewall

<kasei> is this just a DOS issue (re: inside a firewall)? can't you do the same thing with "FROM <...>"?

<scribe> ACTION: SteveH: Add to feature security issues [recorded in http://www.w3.org/2009/03/24-sparql-minutes.html#action02]

<trackbot> Sorry, couldn't find user - SteveH

<SteveH> -1

<ericP> -1

<chimezie> -1

<john-l> -1

<Souri> -1

<kjetil> -1

-1

<kasei> 0

<AlexPassant> 0

<AxelPolleres> 0

<LeeF> 0

<JacekK> 0

<SimonS> 0

<dnewman2> 0

<iv_an_ru> 0

subtopic: return format

<ericP> APPROVED: not standardize query by reference

<AxelPolleres> http://www.w3.org/2009/sparql/wiki/Feature:ReturnFormatKeyword

<ywang4> 0

<AlexPassant> Zakim: ack me

<LeeF> ACTION: LeeF to figure out that silly trackbot and how it knows about users [recorded in http://www.w3.org/2009/03/24-sparql-minutes.html#action03]

<trackbot> Sorry, couldn't find user - LeeF

Alex?

Alex: common parameter for query results
... has some implementation but diferent names, meanings
... switchign server costs
... simply to agree on keyword

<LeeF> SteveH, I want to prematurely ask you if you know whether XmlHttpRequest implementations allow JavaScript (and other) clients to set Accept: headers for content negotiation

SteveH: issues about having same thign in two places
... also what about MIME types not keywords

<SteveH> LeeF, I think they do, yes

<ericP> AndyS: same as steve's identifier (keyword) point

<ericP> ... is Alex open to media types?

LeeF, they use output=

<ericP> AlexPassant: would agree, if it can be used the same way

was originally from Yahoo!

<Zakim> SteveH, you wanted to talk about redundancy with HTTP

kjetil: practical experience with JQuery.
... Accept: did not work but using a parameter did.

<ericP> kjetil: tried using Accept: but gave up do to a bad HTTP implementation

<LeeF> My take on this one - probably best handled via recommendations in a WG Note, rather than a Rec track feature

<chimezie> I agree with LeeF's suggestion

kjetil: wants to work a bit on this to understand it before deciding (may reject then)

<chimezie> I can imagine such a Note handling 'RESTFul' behavior for SPARQL services, for instance

<SteveH> it seems a bit like corssing a boundary to have it in the query language, rather than protocol

<SteveH> *crossing

<ericP> i'm not inclined to write architectural work-arounds for implementation limitations

<SteveH> +1

<scribe> ACTION: kjetil to update the wiki page with his experience (caveat: kjetil may be delayed in doing it) [recorded in http://www.w3.org/2009/03/24-sparql-minutes.html#action04]

<trackbot> Created ACTION-2 - Update the wiki page with his experience (caveat: kjetil may be delayed in doing it) [on Kjetil Kjernsmo - due 2009-03-31].

<ericP> -1

0

<kjetil> +1 on a Note

<SteveH> -1

<AlexPassant> +1

<iv_an_ru> I'd say that the &format=... is convenient for debugging, but that's not something that should be interoperable to the formal degree.

<SimonS> -1

<john-l> 0

<LeeF> -1

<kasei> 0

<Souri> 0

<AxelPolleres> 0 the note may make sense indeed

<kasei> (but +1 to a note)

<iv_an_ru> +0.125 :)

<JacekK> -1 to language keyword / protocol parameter

<chimezie> -1

subtopic: service description

<AxelPolleres> http://www.w3.org/2009/sparql/wiki/Feature:ServiceDescriptions

kasei: proposal to allow info for an endpoint in a common way + info about data at the endpoint
... miniting URIs for features and functions
... vocabulary for describing

<scribe> ... postponed from last time

UNKNOWN_SPEAKER: void, DARQ, SADDLE have experiemented here -- need a way to access this
... (Those three are more about describign the data)

<iv_an_ru> The handle + vocabulary.

<LeeF> My main question on service description is whether it's more useful for "core" features, some of which may not be implemented by a not-fully-compliant implementation, vs. "extension" features, but i think that's a detail to work out later

UNKNOWN_SPEAKER: DARQ and SADDLE are closer but not the complete answer
... so draw from experience here

<LeeF> In general, even though I think there is a substantial cost to specify service description correctly, it's my current favorite approach to encouraging extensibility & interop outside the WG

Orri: voiD OK for cardinality for dist. query system
... maybe have a system graph (common name?)

<SimonS> +q proposal for extension point

<LeeF> To me, system graph vs. protocol-something vs. new query form are implementation details, don't have to be decided right now

kasei: experimental use of DARQ and SADDLE - voiD popular for data description

<ericP> i think that standardizing info for federation is premature

<ericP> (cool, but premature)

Axel: volunteers to compare these 3?

kasei offers

<chimezie> we have a good start with this via current Wiki URLs

<ericP> +1 to minting identifiers for functions and features

<SteveH> +1

<JacekK> +1

Votes about URIs for features

<JacekK> +1 to eric

not the propsoal

<ywang4> +1

<iv_an_ru> +1

<chimezie> +1 for that (not the proposal)

<LeeF> +1 (though less inclined without a way to get at them)

<SimonS> +q

<SteveH> I think the schema and HTTP header will evolve

<SimonS> I think minting URIs without a mechanism to get a description is a bit pointless

<iv_an_ru> nice

<LeeF> +1 to Simon's comment

<kasei> +1

Strawpoll on capability to describve endpoints

<JacekK> +1

<kjetil> 0

<john-l> +1

<chimezie> +1

<LeeF> +1

<SimonS> +1

<AxelPolleres> strawpoll: enable service description of enfpoint

<iv_an_ru> +1

<AlexPassant> +1 (w/ mappings to existing vocabularies)

<Souri> 0

<SteveH> 0

<AxelPolleres> +1

-1 (too early)

<scribe> ACTION: kasei: summarise the vocabularies (DARQ, SADDLE, voiD) [recorded in http://www.w3.org/2009/03/24-sparql-minutes.html#action05]

<trackbot> Sorry, couldn't find user - kasei

<iv_an_ru> AndyS, as soon as the description is open, it could be too empty, but not too early :)

subtopic: commenst and warnings

Orri: metadata inline

<AxelPolleres> http://www.w3.org/2009/sparql/wiki/Feature:ExecCommentsAndWarnings

Orri: implementation dependent

<ericP> as written, SPARQL Query language has no errors which one would expect the user

Orri: e.g. runout of time for query

<ericP> i see most uses of this on the protocol side

<LeeF> SPARQL does define malformed-query and query-request-refused faults in the protocol, fwiw

Orri: can be in response header

<AxelPolleres> connection to REDUCED?

Orri: but that is returned first before resutls start - server issue
... related issue is names for errors

<SteveH> seems /way/ too early to me

<LeeF> """

<LeeF> QueryRequestRefused

<LeeF> This WSDL fault message should be returned when a client submits a request that the service refuses to process. The QueryRequestRefused fault message neither indicates whether the server may or may not process a subsequent, identical request or requests, nor does it constrain a conformant SPARQL service from returning other HTTP status codes or HTTP headers as appropriate given the semantics of [HTTP].

<LeeF> When the QueryRequestRefused fault message is returned, query processing services must include explanatory, debugging, or other additional information intended for human consumption via the fault-details type defined in Excerpt 1.3.

<LeeF> """

Orri: maybe just a placeholder for now

<ericP> i have a hunch that if we do add something to the query lang which begets an error, that we'd at least give it an identifier

Axel: related to query response linking
... are there active champions?

<AxelPolleres> http://www.w3.org/2009/sparql/wiki/Feature:Query_response_linking

<SimonS> -1 for merging

<SteveH> -1 for merge

-1 to merge

ADJOURNED

<LeeF> AndyS, thanks, I'll take care of the minutes

LeeF, thanks

This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/hae/have/
Succeeded: s/LeeF:/LeeF,/
Succeeded: s/is/if/
Found ScribeNick: AndyS
Found Scribe: Andy

WARNING: No "Present: ... " found!
Possibly Present: APPROVED Alex AlexPassant AndyS Axel AxelPolleres DaveNewman JacekK LeeF LukeWM Orri P38 PROPOSED Philippe Simon SimonS Souri SteveH chimezie dnewman2 ericP iv_an_ru john-l kasei kjetil scribenick strawpoll subtopic trackbot ywang4
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy

Regrets: LeeF SimonS

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting

Got date from IRC log name: 24 Mar 2009
Guessing minutes URL: http://www.w3.org/2009/03/24-sparql-minutes.html
People with action items: add axel kasei kjetil leef steveh