14:05:19 <RRSAgent> RRSAgent has joined #sparql
14:05:19 <RRSAgent> logging to http://www.w3.org/2009/03/24-sparql-irc
14:05:37 <JacekK> rrsagent, this will be sparql
14:05:37 <RRSAgent> I'm logging. I don't understand 'this will be sparql', JacekK.  Try /msg RRSAgent help
14:06:13 <AndyS> scribenick: AndyS
14:06:17 <AxelPolleres> Regrets: LeeF, SimonS 
14:06:17 <Zakim> +Souri
14:06:17 <AxelPolleres> chair: Axel Polleres
14:06:40 <AlexPassant> AxelPolleres: SimonS should be there
14:07:08 <AxelPolleres> scribe: Andy 
14:07:15 <AxelPolleres> Link to Agenda:  http://www.w3.org/2009/sparql/wiki/Agenda-2009-03-24 
14:07:25 <AxelPolleres> Topic: Admin
14:08:01 <AxelPolleres> PROPOSED: Approve minutes at http://www.w3.org/2009/sparql/meeting/2009-03-17
14:08:02 <AndyS> Next time: telecon is 15:00 GMTDT
14:08:32 <AndyS> ... back to normal now timezones shifted everytwhwre that's going to.
14:08:34 <AxelPolleres> RESOLVED: Approve minutes at http://www.w3.org/2009/sparql/meeting/2009-03-17
14:08:51 <AndyS> Scribe next time: Souri
14:09:12 <AndyS> Topic: F2F
14:09:47 <AndyS> AndyS: Videoconf tested: Bristol - MIT
14:10:08 <AndyS> Axel: Any concerns for a 2 site F2F?
14:10:15 <SteveH> Bristol is good for LukeWM and SteveH
14:10:26 <AxelPolleres> Bristol
14:10:28 <AlexPassant> Bristol would be ok for me
14:10:30 <SimonS> Bristol
14:10:31 <kasei> MIT
14:10:34 <AndyS> AndyS: Bristol
14:10:36 <JacekK> UIBK would probably prefer Bristol
14:10:36 <john-l> Most likely site would be Cambridge
14:10:49 <ywang4> i will be in cambridge
14:10:52 <LeeF> I'll be in cambridge
14:11:41 <AndyS> ACTION: Axel: To ask EricP to setup a WBS for the F2F
14:11:41 <Souri> Souri has joined #sparql
14:11:41 <trackbot> Created ACTION-1 - Ask EricP to setup a WBS for the F2F [on Axel Polleres - due 2009-03-31].
14:12:25 <AndyS> Topic: Liasons
14:13:12 <SimonS> SimonS has joined #sparql
14:13:20 <AndyS> Orri: RDB2RDF - no WG just yet - chartering started
14:13:55 <AxelPolleres> http://www.w3.org/2009/sparql/wiki/Category:Features
14:14:26 <Zakim> +Philippe
14:14:35 <AndyS> No new features added.
14:14:54 <Zakim> +??P38
14:14:59 <AxelPolleres> subtopic: Parameters
14:15:01 <kjetil> Zakim, ??P38 is me
14:15:01 <Zakim> +kjetil; got it
14:15:09 <kjetil> Zakim, mute me
14:15:09 <Zakim> kjetil should now be muted
14:15:13 <AxelPolleres> http://www.w3.org/2009/sparql/wiki/Feature:Parameters
14:15:28 <AndyS> Orri to present
14:16:14 <AndyS> Variable bindings.
14:17:07 <AndyS> Majority use named variables but other systems do differentiate (for checking)
14:17:42 <Zakim> + +01212803aabb
14:17:54 <AndyS> Virtuoso has used this with BSBM (which has many small queries) to some advantage
14:18:05 <iv_an_ru> Zakim, +01212803aabb is me
14:18:05 <Zakim> +iv_an_ru; got it
14:19:01 <AndyS> Orri: allows caching query planning 
14:19:07 <Souri> This is similar to bind variables
14:19:09 <AxelPolleres> argument for distinction: distinguish required parameters that must be bound?
14:19:18 <kjetil> q+ to ask if there are other ways to do it?
14:19:34 <AndyS> EricP: simple is to substitute for the variable value.
14:20:09 <kasei> ericP's FeDeRate work seems like a generalization of this, but with changes to sparql syntax
14:20:09 <kjetil> ack me
14:20:11 <Zakim> kjetil, you wanted to ask if there are other ways to do it?
14:20:38 <ericP> q+ to ask relative importance to e.g. update
14:20:49 <AndyS> kjetil: are there other ways?
14:20:59 <AndyS> Orri: yes but this is understood
14:21:18 <AndyS> q+
14:21:26 <ericP> ack me
14:21:26 <Zakim> ericP, you wanted to ask relative importance to e.g. update
14:21:34 <kjetil> Zakim, mute me
14:21:34 <Zakim> kjetil should now be muted
14:21:39 <SteveH> it depends on the capability of your optimiser, comprehensive ones won't always be able to reuse the parse tree
14:21:44 <AndyS> EricP: how important is this to Orri?
14:22:14 <AndyS> Orri: update is more important but this is most important on protocol.
14:22:23 <SteveH> -1
14:22:25 <kjetil> +1
14:22:25 <AlexPassant> 0
14:22:27 <kasei> +1
14:22:27 <AndyS> ack me
14:22:29 <john-l> +1
14:22:30 <Souri> 0
14:22:31 <chimezie> +1 (brings SPARQL protocol that much closer to typical HTTP behavior)
14:22:31 <JacekK> +1
14:22:35 <AxelPolleres> 0
14:22:38 <ericP> -1 (hae other priorities)
14:22:41 <iv_an_ru> +0.5
14:22:41 <SteveH> LukeWM: -1 (FWIW
14:22:42 <SimonS> +1
14:22:47 <ericP> s/hae/have/
14:22:49 <AndyS> -1 (unclear alternatives)
14:22:49 <LeeF> 0
14:23:06 <ywang4> 0
14:24:24 <LeeF> To me, standardizing parameters seems to have a modest but not huge interoperability benefit, fwiw/.
14:24:36 <SteveH> LeeF: not if we get it wrong
14:24:45 <SteveH> sorry, LeeF,
14:24:47 <LeeF> s/LeeF:/LeeF,
14:24:59 <LeeF> SteveH, acknowledged
14:25:18 <chimezie> I think the argument for closer interaction with HTTP and the query language is a stronger argument for me
14:25:33 <SteveH> [to repeat what I said on the phone] the current implementations have serious side effects
14:25:52 <AndyS> Axel: Orri, please send email about this.
14:25:58 <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 :)
14:26:04 <AxelPolleres> Orri: +1  to parameters
14:26:28 <AxelPolleres> subtopic: Query by reference 
14:26:45 <AndyS> Axel: may be related to parameters
14:26:48 <AxelPolleres> http://www.w3.org/2009/sparql/wiki/Feature:Query_by_reference
14:26:54 <iv_an_ru> I'd add that params may make text more readable, esp. when their values are very long literals.
14:26:55 <AndyS> ... sent by Leigh Dodds
14:27:16 <SteveH> q+
14:27:21 <AndyS> .. ability to send a URI to the query, not the query itself.
14:27:23 <ericP> q+ to suggest the standardization wins aren't huge
14:27:29 <SimonS> +q
14:27:36 <dnewman2> dnewman2 has joined #sparql
14:27:53 <ericP> ack SteveH 
14:28:07 <AndyS> SteveH: issues of security
14:28:09 <ericP> SteveH: not sure why it matters except in massive queries
14:28:21 <chimezie> I agree on that point as well
14:28:22 <ericP> ack SimonS 
14:28:30 <Zakim> +DaveNewman
14:28:36 <ericP> SimonS: limited use compared to security probs
14:28:48 <AndyS> Simon: useful is refer to views and combine with parameters
14:28:52 <AndyS> s/is/if/
14:29:01 <ericP> ... perhaps has more value when combined with views or parameters
14:29:03 <ericP> q-
14:29:04 <AndyS> ... else less value
14:29:23 <iv_an_ru> I'd prefer "include" for views.
14:29:40 <AndyS> Orri: A view is (like) a subquery
14:29:59 <chimezie> The general security concern of executing external 'code' 
14:30:09 <chimezie> especially now we might have update support
14:30:14 <AndyS> Simon: security: server is pulling external input
14:30:19 <iv_an_ru> +1 to chimezie
14:30:35 <SteveH> the external request will be coming from the SPARQL processor machine, which may have IP=based security
14:31:15 <ericP> SteveH: the request is issued by sparql processor which may be inside a firewall
14:31:50 <kasei> is this just a DOS issue (re: inside a firewall)? can't you do the same thing with "FROM <...>"?
14:31:50 <AndyS> ACTION: SteveH: Add to feature security issues
14:31:50 <trackbot> Sorry, couldn't find user - SteveH
14:32:17 <SteveH> -1
14:32:18 <ericP> -1
14:32:20 <chimezie> -1
14:32:21 <john-l> -1
14:32:21 <Souri> -1
14:32:22 <kjetil> -1
14:32:22 <AndyS> -1
14:32:23 <kasei> 0
14:32:24 <AlexPassant> 0
14:32:26 <AxelPolleres> 0
14:32:26 <LeeF> 0
14:32:27 <JacekK> 0
14:32:29 <SimonS> 0
14:32:29 <dnewman2> 0
14:32:32 <iv_an_ru> 0
14:32:52 <AndyS> subtopic: return format
14:32:54 <ericP> APPROVED: not standardize query by reference
14:32:55 <AxelPolleres> http://www.w3.org/2009/sparql/wiki/Feature:ReturnFormatKeyword
14:32:59 <ywang4> 0
14:33:04 <AlexPassant> Zakim: ack me
14:33:18 <LeeF> ACTION: LeeF to figure out that silly trackbot and how it knows about users
14:33:18 <trackbot> Sorry, couldn't find user - LeeF
14:33:39 <AndyS> Alex?
14:33:43 <AxelPolleres> Zakim, unmute AlexPassant
14:33:43 <Zakim> AlexPassant should no longer be muted
14:34:17 <AndyS> Alex: common parameter for query results
14:34:26 <SteveH> q+ to talk about redundancy with HTTP
14:34:29 <AndyS> .. has some implementation but diferent names, meanings
14:34:50 <AndyS> .. switchign server costs
14:35:13 <AndyS> ... simply to agree on keyword
14:35:15 <AndyS> q+
14:35:37 <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
14:35:53 <AndyS> SteveH: issues about having same thign in two places
14:36:09 <AndyS> ... also what about MIME types not keywords
14:36:12 <SteveH> LeeF, I think they do, yes
14:36:31 <ericP> AndyS: same as steve's identifier (keyword) point
14:36:41 <ericP> ... is Alex open to media types?
14:36:52 <AndyS> LeeF, they use output=
14:37:08 <ericP> AlexPassant: would agree, if it can be used the same way
14:37:11 <AndyS> was originally from Yahoo!
14:37:19 <kjetil> q+ 
14:37:23 <AndyS> ack me
14:37:27 <SteveH> ack me
14:37:27 <Zakim> SteveH, you wanted to talk about redundancy with HTTP
14:37:32 <ericP> ack SteveH 
14:37:35 <kjetil> ack me
14:37:53 <AndyS> kjetil: practical experience with JQuery.
14:38:17 <AndyS> ... Accept: did not work but using a parameter did.
14:38:26 <ericP> kjetil: tried using Accept: but gave up do to a bad HTTP implementation
14:38:27 <LeeF> My take on this one - probably best handled via recommendations in a WG Note, rather than a Rec track feature
14:39:00 <chimezie> I agree with LeeF's suggestion
14:39:15 <AndyS> ... wants to work a bit on this to understand it before deciding (may reject then)
14:39:17 <chimezie> I can imagine such a Note handling 'RESTFul' behavior for SPARQL services, for instance
14:39:22 <SteveH> it seems a bit like corssing a boundary to have it in the query language, rather than protocol
14:39:25 <SteveH> *crossing
14:39:28 <ericP> i'm not inclined to write architectural work-arounds for implementation limitations
14:39:34 <SteveH> +1
14:39:40 <kjetil> Zakim, mute me
14:39:40 <Zakim> kjetil should now be muted
14:40:24 <kjetil> Zakim, unmute me
14:40:24 <Zakim> kjetil should no longer be muted
14:40:56 <AndyS> ACTION: kjetil to update the wiki page with his experience (caveat: kjetil may be delayed in doing it)
14:40:57 <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].
14:41:04 <kjetil> Zakim, mute me
14:41:04 <Zakim> kjetil should now be muted
14:41:11 <ericP> -1
14:41:12 <AndyS> 0
14:41:12 <kjetil> +1 on a Note
14:41:15 <SteveH> -1
14:41:17 <AlexPassant> +1
14:41:17 <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.
14:41:17 <SimonS> -1
14:41:19 <john-l> 0
14:41:20 <LeeF> -1
14:41:20 <kasei> 0
14:41:22 <Zakim> -kjetil
14:41:25 <Souri> 0
14:41:28 <AxelPolleres> 0 the note may make sense indeed
14:41:30 <kasei> (but +1 to a note)
14:41:31 <iv_an_ru> +0.125 :)
14:41:34 <JacekK> -1 to language keyword / protocol parameter
14:41:35 <kjetil> Zakim, unmute me
14:41:35 <Zakim> kjetil.a was not muted, kjetil
14:41:38 <chimezie> -1
14:41:49 <kjetil> Zakim, mute me
14:41:49 <Zakim> kjetil.a should now be muted
14:42:09 <AndyS> subtopic: service description
14:42:11 <AxelPolleres> http://www.w3.org/2009/sparql/wiki/Feature:ServiceDescriptions
14:42:39 <AndyS> kasei: proposal to allow info for an endpoint in a common way + info about data at the endpoint
14:43:06 <AndyS> ... miniting URIs for features and functions
14:43:15 <AndyS> ... vocabulary for describing
14:43:21 <AndyS> ... postponed from last time
14:43:51 <AndyS> ... void, DARQ, SADDLE have experiemented here -- need a way to access this
14:44:03 <ericP> q+ to ask about commonality of impls
14:44:08 <AndyS> ... (Those three are more about describign the data)
14:44:28 <iv_an_ru> The handle + vocabulary.
14:44:31 <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
14:45:00 <AndyS> ... DARQ and SADDLE are closer but not the complete answer
14:45:14 <AndyS> ... so draw from experience here
14:45:32 <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
14:47:00 <AndyS> Orri: voiD OK for cardinality for dist. query system
14:47:14 <AndyS> ... maybe have a system graph (common name?)
14:47:21 <ericP> q+ to ask if DARQ docs include SADDLe predicates
14:47:28 <SimonS> +q proposal for extension point
14:47:45 <SimonS> q+
14:47:58 <LeeF> To me, system graph vs. protocol-something vs. new query form are implementation details, don't have to be decided right now
14:48:16 <kjetil> q- proposal
14:49:07 <AndyS> kasei: experimental use of DARQ and SADDLE - voiD popular for data description
14:49:32 <SimonS> q-
14:49:37 <ericP> q-
14:49:49 <ericP> i think that standardizing info for federation is premature
14:49:58 <ericP> (cool, but premature)
14:50:15 <AndyS> Axel: volunteers to compare these 3?
14:50:28 <AndyS> kasei offers
14:50:51 <chimezie> we have a good start with this via current Wiki URLs
14:50:58 <ericP> +1 to minting identifiers for functions and features
14:51:12 <SteveH> +1
14:51:24 <JacekK> +1
14:51:49 <AndyS> Votes about URIs for features
14:51:51 <JacekK> +1 to eric
14:51:57 <AndyS> not the propsoal
14:51:58 <ywang4> +1
14:52:00 <iv_an_ru> +1
14:52:06 <chimezie> +1 for that (not the proposal)
14:52:13 <LeeF> +1 (though less inclined without a way to get at them)
14:52:31 <SimonS> +q
14:52:37 <SteveH> I think the schema and HTTP header will evolve
14:53:02 <SteveH> q+
14:53:11 <SimonS> I think minting URIs without a mechanism to get a description is a bit pointless
14:54:14 <iv_an_ru> nice
14:55:03 <LeeF> +1 to Simon's comment
14:55:47 <kasei> +1
14:55:48 <AndyS> Strawpoll on capability to describve endpoints
14:55:52 <JacekK> +1
14:55:53 <kjetil> 0
14:55:54 <john-l> +1
14:55:54 <chimezie> +1
14:55:55 <LeeF> +1
14:55:55 <SimonS> +1
14:55:56 <AxelPolleres> strawpoll: enable service description of enfpoint
14:55:57 <iv_an_ru> +1
14:55:59 <AlexPassant> +1 (w/ mappings to existing vocabularies)
14:55:59 <Souri> 0
14:55:59 <SteveH> 0
14:56:00 <AxelPolleres> +1
14:56:01 <SimonS> q-
14:56:03 <AndyS> -1 (too early)
14:56:50 <AndyS> ACTION: kasei: summarise the vocabularies (DARQ, SADDLE, voiD)
14:56:50 <trackbot> Sorry, couldn't find user - kasei
14:56:51 <Zakim> -ywang4
14:56:51 <iv_an_ru> AndyS, as soon as the description is open, it could be too empty, but not too early :)
14:57:05 <Zakim> -iv_an_ru
14:57:18 <AndyS> subtopic: commenst and warnings
14:57:28 <AndyS> Orri: metadata inline
14:57:31 <AxelPolleres> http://www.w3.org/2009/sparql/wiki/Feature:ExecCommentsAndWarnings
14:57:43 <AndyS> ... implementation dependent
14:57:49 <ericP> as written, SPARQL Query language has no errors which one would expect the user
14:57:54 <AndyS> ... e.g. runout of time for query
14:58:06 <ericP> i see most uses of this on the protocol side
14:58:40 <LeeF> SPARQL does define malformed-query and query-request-refused faults in the protocol, fwiw
14:58:41 <AndyS> ... can be in response header
14:58:47 <AxelPolleres> connection to REDUCED?
14:59:07 <AndyS> ... but that is returned first before resutls start - server issue
14:59:24 <AndyS> ... related issue is names for errors
14:59:27 <SteveH> seems /way/ too early to me
14:59:42 <LeeF> """
14:59:43 <LeeF> QueryRequestRefused
14:59:43 <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].
14:59:43 <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.
14:59:46 <LeeF> """
15:00:06 <AndyS> ... maybe just a placeholder for now
15:00:30 <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
15:00:40 <AndyS> Axel: related to query response linking
15:00:55 <AndyS> ... are there active champions?
15:01:04 <AxelPolleres> http://www.w3.org/2009/sparql/wiki/Feature:Query_response_linking
15:01:26 <Zakim> -DaveNewman
15:01:41 <SimonS> -1 for merging
15:01:49 <SteveH> -1 for merge
15:01:55 <AndyS> -1 to merge
15:02:03 <ywang4> ywang4 has left #sparql
15:02:29 <Zakim> -JacekK
15:02:30 <AndyS> ADJOURNED
15:02:32 <Zakim> -Chimezie_Ogbuji
15:02:33 <Zakim> -[Garlik]
15:02:44 <Zakim> -john-l
15:02:53 <LeeF> AndyS, thanks, I'll take care of the minutes
15:03:02 <Zakim> -??P25
15:03:04 <Zakim> -AlexPassant
15:03:25 <kjetil> Zakim, unmute me
15:03:25 <Zakim> kjetil.a should no longer be muted
15:03:28 <Zakim> -kasei
15:03:38 <Zakim> -SimonS
15:03:43 <AndyS> LeeF, thanks
15:03:53 <LeeF> RRSAgent, draft minutes
15:03:53 <RRSAgent> I have made the request to generate http://www.w3.org/2009/03/24-sparql-minutes.html LeeF
15:03:58 <LeeF> RRSAgent, make logs world
15:04:07 <Zakim> -kjetil.a
15:04:17 <kasei> kasei has left #sparql
15:04:34 <Souri> How do I generate using Zakim "* ericP is 5-11, has short reddish hair..." kind of comment?
15:04:58 <LeeF> Souri, it's an IRC thing - type "/me followed by the rest of the comment"
15:04:59 <Zakim> -ericP
15:05:15 <Souri> Thanks Lee.
15:05:31 <LeeF> yeah, like that :)
15:05:36 <Souri> ok
15:05:51 <Zakim> -AndyS
15:05:54 <Zakim> -Souri
15:05:57 <Zakim> -AxelPolleres
15:05:58 <Zakim> SW_(SPARQL)10:00AM has ended
15:06:01 <Zakim> Attendees were kasei, ywang4, kjetil, AxelPolleres, john-l, JacekK, AlexPassant, Chimezie_Ogbuji, [Garlik], AndyS, +0049261287aaaa, SimonS, Souri, ericP, iv_an_ru, DaveNewman
15:06:14 <SteveH> SteveH has joined #sparql
15:06:15 <LukeWM> LukeWM has joined #sparql
15:07:14 <AndyS> How do I ask trackbot about the actions?
15:07:34 <LeeF> trackbot, actions?
15:07:34 <trackbot> Sorry, LeeF, I don't understand 'trackbot, actions?'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
15:07:39 <LeeF> got me :)
15:07:48 <AndyS> Hmm - no help for trackbot
15:08:07 <AndyS> Tried /msg trackbot help
15:08:15 <LeeF>  http://www.w3.org/2005/06/tracker/irc doesn't show a list command
15:08:28 <sandro> sandro has joined #sparql
15:08:30 <LeeF> ericP, do you know where are tracker is installed?
15:08:38 <LeeF> or sandro, do you know where our tracker is installed? :)
15:08:55 <ericP> i have no clue about tracker
15:09:03 <ericP> you young kids these days
15:31:25 <SimonS> SimonS has left #sparql
16:23:46 <AndyS> AndyS has joined #sparql
16:36:00 <AndyS> AndyS has joined #sparql
17:35:28 <LeeF> AndyS, what did you mean when you said that current xmlHttpRequest implementations use output= for conneg?
17:39:06 <AndyS> Yahoo! documents the use of output=json http://developer.yahoo.com/common/json.html#output
17:40:09 <AndyS> This is used to (1) not require messing around with content negotiation (difficult to access from a script I'm told) and (2) get JSOn not the defaul XML.
17:41:06 <LeeF> ah ok, it was the "difficult to access from a script" part that I was wondering about
17:48:15 <AndyS> IF we do it, I advokate using "output=" because others do.  Joseki uses "accept=" as a synonym.
17:49:13 <LeeF> does Joseki provide an option to get it back suitable for use in a <script> tag to circumvent cross-domain XHR restrictions? (you know, returning "var results = { ... };"
17:51:00 <AndyS> It does "callback=" (see link above) - is that the same?
17:52:11 <LeeF> yes, the same
17:52:12 <LeeF> thanks
17:55:32 <AndyS> Joskei now support output=text :-)
17:56:09 <AndyS> IIRC these were it you/Elias request originally!
18:01:59 <sandro> sandro has joined #sparql
18:05:28 <Zakim> Zakim has left #sparql
18:30:29 <sandro> sandro has joined #sparql
19:28:03 <KjetilK> KjetilK has joined #sparql
20:26:59 <sandro> sandro has joined #sparql