IRC log of sparql on 2009-03-24

Timestamps are in UTC.

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: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