Last modified on 9 June 2009, at 19:24
Please justify/explain all edits to this page, in your "edit summary" text.
<LeeF> present: ericp, leef, axel, andy, bijan, kasei, pgearon, steveh, LukeWM, chimezie, orri, KjetilK, AlexPassant, bglimm, JacekK, Prateek, Simon <LeeF> regrets: iv_an_ru <LeeF> Meeting: SPARQL WG Weekly Telecon 14:03:04 <AxelPolleres> Agenda: http://www.w3.org/2009/sparql/wiki/Agenda-2009-06-09 14:03:45 <JacekK> scribe: JacekK 14:03:52 <JacekK> scribenick: JacekK 14:04:43 <JacekK> next scribe: Kjetil (tentatively) 14:04:48 <KjetilK> Zakim, mute me 14:04:48 <Zakim> KjetilK.a should now be muted 14:04:50 <LeeF> Regrets for next week for me [SemTech] 14:04:50 <pgearon> pgearon has joined #sparql 14:05:11 <AxelPolleres> Proposed: approve http://www.w3.org/2009/sparql/meeting/2009-06-02 14:05:24 <AxelPolleres> RESOLVED: approve http://www.w3.org/2009/sparql/meeting/2009-06-02 14:05:40 <JacekK> topic: liaisons 14:05:43 <bijan> Nope 14:06:01 <bijan> The OWL Specs are going to CR (for the interested) 14:06:14 <JacekK> ericP: nothing from xquery either 14:06:43 <JacekK> AxelPolleres: RIF's final specs will be discussed soon, otherwise nothing 14:06:55 <JacekK> AxelPolleres congratules on OWL CR 14:07:13 <JacekK> topic: actions 14:08:21 <LeeF> trackbot, close ACTION-10 14:08:30 <trackbot> ACTION-10 Talk to Eric to confirm minutes change from April 21 closed 14:09:13 <KjetilK> KjetilK has changed the topic to: http://www.w3.org/2009/sparql/wiki/Agenda-2009-06-09 14:10:55 <JacekK> trackbot, close ACTION-23 14:10:55 <trackbot> ACTION-23 Summarize implicit vs. explicit grouping re ISSUE-11 closed 14:11:21 <JacekK> trackbot, close ACTION-34 14:11:21 <trackbot> ACTION-34 Summarize issue discussed in the end of the telecon regarding PUT closed 14:11:52 <JacekK> trackbot, close ACTION-35 14:12:50 <trackbot> ACTION-35 Tell OWL/RIF that SPARQL is content with http://www.w3.org/2007/OWL/wiki/PlainLiteral closed 14:13:30 <LeeF> trackbot, close ACTION-21 14:13:34 <trackbot> ACTION-21 Summarize dataset issue w/ examples / suggestions per ISSUE-8 closed 14:12:18 <AxelPolleres> http://www.w3.org/2009/sparql/docs/features/ 14:12:24 <JacekK> topic: features and rationales document 14:13:07 <JacekK> AxelPolleres: most relevant things already in the document 14:13:13 <KjetilK> Zakim, unmute me 14:13:13 <Zakim> KjetilK.a should no longer be muted 14:13:46 <Zakim> +??P42 14:14:03 <JacekK> kjetil: we have pretty much all the text we require, with some open issues 14:14:31 <LukeWM> q+ 14:14:38 <JacekK> kjetil goes over the document 14:15:17 <JacekK> kjetil: for related discussions, we simply link to the issue tracker 14:15:34 <AxelPolleres> http://lists.w3.org/Archives/Public/public-rdf-dawg/2009AprJun/0346.html 14:15:45 <AxelPolleres> (Andy's comments) 14:16:10 <JacekK> kjetil: none of the issues seem to be bloking, we could go to FPWD on what we have 14:16:46 <JacekK> kjetil: we should discuss if any issues need to be addressed before FPWD 14:16:48 <LeeF> q+ to suggest one week of review, then publish (even w/ unresolved issues) then refine 14:17:08 <AndyS> ?? 2nd and 3rd ?? Isn't it to be done by end July in prep for charter II? 14:17:31 <AndyS> q+ to suggest keeping the issues in the doc 14:17:37 <JacekK> LukeWM: some implementation text may not be correct (?) 14:17:48 <LukeWM> ack LukeWM 14:18:16 <AndyS> I can make sure it is at least feasible, parser-wise. 14:18:21 <JacekK> kjetil: we may need better examples 14:18:55 <JacekK> ack LeeF 14:18:55 <Zakim> LeeF, you wanted to suggest one week of review, then publish (even w/ unresolved issues) then refine 14:19:19 <SteveH> I'll commit to review it and comment 14:19:30 <JacekK> LeeF: we need to get people to commit to comment on the doc (it's not long) 14:19:30 <chimezie> I can do the same 14:19:37 <AxelPolleres> suggestion is to put remaining issue in ... as Editor's note? 14:19:48 <KjetilK> my summary of issues: http://lists.w3.org/Archives/Public/public-rdf-dawg/2009AprJun/0347.html 14:20:20 <JacekK> ericP: yes, we should make the open issues in a certain style so it's visible 14:20:34 <JacekK> ack AndyS 14:20:34 <Zakim> AndyS, you wanted to suggest keeping the issues in the doc 14:20:44 <JacekK> AndyS: the doc must be self-contained even if it's quite rough 14:21:00 <AndyS> ack me 14:21:13 <JacekK> AndyS: the summary up-front should be finished, frozen and time-stamped 14:21:33 <JacekK> AxelPolleres: it should be in the introduction, right? 14:21:58 <LeeF> ACTION: Axel to draft the introduction with a summary of the issues 14:21:58 <trackbot> Created ACTION-36 - Draft the introduction with a summary of the issues [on Axel Polleres - due 2009-06-16]. 14:22:36 <JacekK> AndyS: if the docs were on the wiki, it'd be easier to contribute text 14:23:01 <LeeF> The OWL WG edits their documents on the wiki and publishes directly from there, but that relies on a lot of SandroMagic (TM) 14:23:02 <JacekK> AxelPolleres: we decided for docs to be edited in CVS 14:23:07 <SteveH> if the document is in the wiki its harder to track changes 14:23:38 <bijan> Why not use the Wiki for proposed text 14:23:43 <JacekK> AndyS: while we're trying to gather material, wiki would be better 14:23:44 <bijan> and let the editors integrate it 14:24:01 <AndyS> What worked in RIF and OWL? 14:24:09 <AndyS> (worked well) 14:24:31 <bijan> The OWL WG regularly refers to "Wiki maddness" 14:24:36 <bijan> It was bad for publication 14:24:40 <bijan> It was very annoying for editing 14:24:45 <bijan> Brutal, really 14:25:27 <AndyS> OK - if the editors are prepared to "edit" not just "write" 14:25:39 <JacekK> bijan: wiki is good for tweaks by everybody 14:25:50 <AndyS> Sounds like it is not a good as it might be. 14:25:50 <JacekK> bijan: making systematic changes is harder, also seeing what you're doing is harder 14:26:07 <JacekK> bijan: wiki syntax is fragile 14:26:27 <Zakim> -kasei 14:26:37 <JacekK> AxelPolleres: so let's try to draft things on the wiki, and editors will incorporate that in the doc 14:26:44 <JacekK> bijan: that seems to be a reasonable model 14:27:12 <JacekK> zakim, who is speaking? 14:27:22 <AxelPolleres> kjetil is speaking 14:27:22 <Zakim> JacekK, listening for 10 seconds I heard sound from the following: 14 (40%), AxelPolleres? (14%), AndyS (16%) 14:27:25 <Zakim> +??P2 14:27:41 <kasei> Zakim, ??P2 is me 14:27:41 <Zakim> +kasei; got it 14:27:52 <kasei> Zakim, mute me 14:27:52 <Zakim> kasei should now be muted 14:27:52 <JacekK> AxelPolleres: at this point, we need more reviewers and comments on the doc 14:28:01 <JacekK> AxelPolleres: everyone should review it, but we should have a few actions 14:28:11 <JacekK> volunteers - steve, chime 15:22:00 <LeeF> ACTION: Chimezie to review F&R document 15:22:02 <trackbot> Created ACTION-39 - Review F&R document [on Chimezie Ogbuji - due 2009-06-16]. 15:22:03 <LeeF> ACTION: Steve to review F&R document 15:22:05 <trackbot> Created ACTION-40 - Review F&R document [on Steve Harris - due 2009-06-16]. 14:28:35 <SteveH> by end of week it tight, but I'll try 14:29:04 <JacekK> AxelPolleres: if the reviews arrive by end of week, we might already have a good almost-final material for the FPWD next week 14:29:40 <JacekK> AxelPolleres: for FPWD, we might just go with what we have with some refinement, or does somebody suggest we need a detailed review? 14:30:10 <KjetilK> q+ 14:30:16 <JacekK> AndyS: I've done a single, not very complete, read-through 14:30:18 <KjetilK> ack me 14:30:45 <JacekK> kjetil: people should also just have a look at the open issues (posted by Axel on my behalf) 14:31:00 <JacekK> kjetil: let's go through them quickly right now 14:31:08 <JacekK> kjetil: 1) we need a short name 14:31:10 <AxelPolleres> http://lists.w3.org/Archives/Public/public-rdf-dawg/2009AprJun/0347.html 14:31:33 <JacekK> kjetil: 2) examples should be implemented (we should confirm this) 14:31:44 <JacekK> kjetil: 3) service descriptions should prolly be a section by itself 14:32:00 <JacekK> kjetil: 4) suggestion for new version of the protocol 14:32:18 <LeeF> We haven't explicitly discussed project expressions, which is why 14:32:28 <JacekK> kjetil: 5) we need to check project expressions if there should be some material 14:32:37 <JacekK> kjetil: 6) patent policy (?) 14:32:56 <JacekK> ericP: just the boiler plate, we need not think about it 14:33:09 <LeeF> I can name 2 project expression issues off the top of my head - syntax for expressions & whether expression alias names are required 14:33:13 <JacekK> kjetil: 7) some linking consistency 14:33:58 <JacekK> AxelPolleres: service descriptions in their own subsection - any objections? 14:34:07 <JacekK> s/subsection/section/ 14:34:17 <kasei> q+ 14:34:19 <LeeF> +1 to serv descrip in own section, for the time being at least 14:34:31 <LeeF> it may end up having protocol aspects, or query aspects, or neither 14:34:38 <SteveH> +1 14:34:38 <kasei> Zakim, unmute me 14:34:38 <Zakim> kasei should no longer be muted 14:35:18 <JacekK> kasei: the separate section might imply that implementors can deel with this modularly 14:35:53 <KjetilK> Zakim, mute me 14:35:53 <Zakim> KjetilK.a should now be muted 14:35:56 <JacekK> kasei: somebody could implement query, protocol but not service descriptions 14:36:10 <LeeF> q+ 14:36:11 <ericP> note that our short name is still subject to approval by the publication team (who make sure we don't call it xquery-foo) 14:36:30 <AndyS> Not sure I agree - the service description might be 3rd party (woudl like 1st party but realistically?) 14:36:30 <KjetilK> ack kasei 14:36:38 <KjetilK> ack LeeF 14:37:00 <KjetilK> +1 14:37:03 <AxelPolleres> +1 to own section "Service Description" 14:37:05 <kasei> +1 LeeF 14:37:08 <JacekK> LeeF: for this document, it could be its own section; we don't need to say whether it belongs with either of the other parts 14:37:20 <kasei> Zakim, mute me 14:37:20 <Zakim> kasei should now be muted 14:37:42 <JacekK> AxelPolleres: so we'll put svc descriptions in its own section, with an issue that it may belong to protocol or query 14:37:50 <AxelPolleres> RESOLVED: we will have an own section "Service Description" 14:38:35 <JacekK> topic: service descriptions 14:38:45 <JacekK> AxelPolleres: we need a bit of a better idea on what we need 14:38:50 <LeeF> ISSUE: Is service description part of the protocol, the query language, or something else altogether? 13:20:01 <trackbot> Created ISSUE-31 - Is service description part of the protocol, the query language, or something else altogether? ; please complete additional details at http://www.w3.org/2009/sparql/track/issues/31/edit . 14:39:06 <JacekK> AxelPolleres: we have several proposals 14:39:48 <JacekK> AxelPolleres: 1) the issue was discussed already a long time ago in WG1 14:39:56 <AxelPolleres> http://www.w3.org/2001/sw/DataAccess/ftf4.html#item10 14:40:19 <JacekK> AxelPolleres: the first WG's ftf4 lists some proposals 14:40:36 <JacekK> AxelPolleres: the f&r doc could use some of that, e.g. for use cases 14:41:04 <AxelPolleres> http://www.w3.org/2009/sparql/track/issues/23 14:41:09 <JacekK> AxelPolleres: the issue on media types & conneg is related 14:41:59 <AxelPolleres> http://www.w3.org/2009/sparql/meeting/2009-05-06#Full__2d_text_search 14:42:17 <JacekK> AxelPolleres: there are two directions - the hard one to go through existing descriptions and recommend something, the easier one just to enable hooks for description without specifying the content 14:42:28 <JacekK> AxelPolleres: we could just provide the mechanism and some examples 14:43:29 <AndyS> +1 to small (minimal) framework + *suggestions* to use other vocabs 14:43:29 <SteveH> q+ 14:43:41 <JacekK> ericP: an endpoint might support DESCRIBE or similar queries about itself 14:44:20 <JacekK> ericP: we may want to write down some obvious things, such as a class of SPARQL endpoints 14:44:40 <AndyS> q+ to mention 3rd party use 14:44:48 <JacekK> SteveH: I have problems with packing it into the query; with gateways it's hard to know what the URI of the actual endpoint is 14:44:56 <JacekK> ack SteveH 14:45:21 <LeeF> I was a pretty strong advocate of service description, so I should also say that I strongly support doing whatever we see as minimal guidance to encourage people to start describing their endpoints/services :-) 14:45:23 <JacekK> SteveH: I'm also uncomfortable about requiring some data to be in the endpoint 14:45:30 <AxelPolleres> q+ to ask whether we could obtain the service description by simply Get [entpoint] requesting mime type rdf/xml? 14:45:37 <JacekK> SteveH: must prefer an HTTP header that would point to the description 14:45:43 <JacekK> q+ to suggest HTTP OPTIONS 14:46:09 <kasei> in addition to an Endpoint class, I'd think at minimum we should define properties for extension points (functions, possibly entailment regimes) 14:46:11 <JacekK> ericP: if we have the description, then we'd also want an endpoint that can query them 14:46:44 <JacekK> SteveH: if the HTTP header gives you a URI, you can just do FROM that URI 14:46:45 <kasei> heh 14:47:03 <JacekK> ericP: I find it easier to specify graphs than to add HTTP headers 14:47:22 <AndyS> SOAP? 14:47:24 <JacekK> SteveH: it took me less than an hour to add the header, but embedding dynamic data in the endpoint is harder 14:47:28 <AxelPolleres> Zakim, who is on the queue? 14:47:28 <Zakim> I see AndyS, AxelPolleres, JacekK on the speaker queue 14:47:48 <JacekK> ericP: the header may also not make it through proxies 14:48:22 <JacekK> ericP: I meant it's difficult to specify the HTTP header, not to implement it - we'd need to involve IETF, HTTP extensibility, RFC iterations... 14:48:30 <chimezie> What is the Atom precedence here? 14:48:43 <JacekK> AndyS: some use cases, where the endpoint is not the one offering the description 14:48:52 <JacekK> AndyS: a repository (UDDI-like situation) 14:48:56 <AxelPolleres> that's an interesting one. 14:49:14 <JacekK> AndyS: all discussion now has focused on the endpoint describing itself 14:49:25 <LeeF> chimezie, good question 14:49:34 <JacekK> AxelPolleres: is there an issue in the authority of descriptions? 14:49:59 <chimezie> Atom appears to have an explicit 'service document' with a known URI 14:50:02 <JacekK> AxelPolleres: what's the use case for 3rd party description of an endpoint? 14:50:07 <LeeF> chimezie, EliasT tells me that Atom Publishing Protocol (APP) has a well-known service.xml file 14:50:58 <chimezie> Yeah, i'm looking to see if the URI for this service document is 'hardcoded' or can be discovered via introspection of some kind 14:51:06 <AndyS> Currently - It is not part of the protocol. Must have "query=" 14:51:17 <JacekK> ericP: query is a required parameter 14:51:36 <JacekK> AxelPolleres: could we add a new behavior there? 14:51:48 <LeeF> chimezie, he says you can find it via a meta tag in HTML 14:52:01 <JacekK> ericP: it's currently an error, and our WSDL description would then be "everything-optional" 14:52:02 <chimezie> hmmm.. 14:52:25 <AxelPolleres> Zakim, who is on the queue? 14:52:25 <Zakim> I see AndyS, AxelPolleres, JacekK on the speaker queue 14:52:28 <JacekK> ericP: but an error could be reasonable if the request is not recognized - an old system 14:52:34 <AxelPolleres> ack AndyS 14:52:34 <Zakim> AndyS, you wanted to mention 3rd party use 14:52:43 <AxelPolleres> ack AxelPolleres 14:52:43 <Zakim> AxelPolleres, you wanted to ask whether we could obtain the service description by simply Get [entpoint] requesting mime type rdf/xml? 14:52:53 <LeeF> chimezie, EliasT points me to http://www.ibm.com/developerworks/xml/library/x-atomsidebar/index.html 14:52:58 <chimezie> [[[ 14:52:58 <chimezie> How Service Documents are discovered is not defined in this 14:52:59 <chimezie> specification. 14:53:02 <chimezie> ]]] -- Atom Pub 14:53:10 <JacekK> JacekK: one of the ways to get the description would be HTTP OPTIONS 14:53:17 <SteveH> http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html 14:53:22 <SteveH> OPTIONs 14:53:41 <LeeF> I wouldn't knw where to start to implement something via OPTION 14:53:50 <AndyS> Do you get content neg on OPTIONs? 14:53:56 <ericP> http://www.w3.org/Protocols/rfc2616/rfc2616-sec9#sec9.2 14:54:05 <LeeF> q? 14:54:08 <LeeF> ack JacekK 14:54:08 <Zakim> JacekK, you wanted to suggest HTTP OPTIONS 14:54:11 <SteveH> AndyS, yes 14:54:25 <AndyS> OPTION * is tricky but otherwise servelet API would route it. 14:54:28 <AndyS> Thx Steve 14:54:32 <JacekK> JacekK: OPTIONS is used to discover, for example, which of GET/POST/PUT/DELETE is available 14:54:43 <kasei> might run into trouble using OPTION in many www client APIs 14:54:48 <JacekK> JacekK: HTTP currently doesn't specify what can be returned as the body of the response 14:55:11 <JacekK> AxelPolleres: time is running out, any volunteer to summarize this in an email, or the wiki? 14:55:39 <JacekK> ericP: steve and I should have an argument on the wiki 14:56:00 <JacekK> ericP: but I'll be quite busy the upcoming weeks 14:56:13 <JacekK> SteveH: I've already put my thoughts on the wiki 14:56:36 <kjetil> kjetil has joined #sparql 14:56:44 <JacekK> SteveH: I didn't add anything about the query language stuff, not expecting that we'd even consider it 14:57:28 <AxelPolleres> ACTION: Eric to add to http://www.w3.org/2009/sparql/wiki/Feature:ServiceDescriptions about different options to serve descriptions 14:57:35 <chimezie> It seems like a comprehensive set of usecases might frame this discussion better (so we aren't talking about open-ended service descriptions, but descriptions of specific SPARQL-related services) 14:58:04 <JacekK> LeeF: SteveH, what did you mean by the query lang stuff? 14:58:13 <AxelPolleres> ACTION: Jacek to add to http://www.w3.org/2009/sparql/wiki/Feature:ServiceDescriptions about different options to serve descriptions (specifically HTTP OPTION) 13:22:02 <trackbot> Created ACTION-37 - Add to http://www.w3.org/2009/sparql/wiki/Feature:ServiceDescriptions about different options to serve descriptions (specifically HTTP OPTION) [on Jacek KopeckÃ½ - due 2009-06-16]. 14:58:30 <JacekK> SteveH: syntax extensions, but it's a bit of a chicken-and-egg problem - you need to know what lang is allowed before you could ask for the description 14:59:11 <AxelPolleres> Eric: at least type sparqlendpoint 14:59:25 <AxelPolleres> Orri: each feature should have a URI. 14:59:35 <AxelPolleres> http://lists.w3.org/Archives/Public/public-rdf-dawg/2009AprJun/0299.html 14:59:44 <kasei> I'm here 15:00:15 <JacekK> AxelPolleres: we prolly don't want to standardize a full description language 15:00:20 <Zakim> -john-l 15:00:28 <JacekK> AxelPolleres: a Note could be an option 15:00:33 <kasei> q+ to mention vocabulary 15:00:36 <kasei> Zakim, unmute me 15:00:36 <Zakim> kasei should no longer be muted 15:00:41 <Zakim> -Chimezie_Ogbuji 15:01:08 <AxelPolleres> Orri: void good for the data, but we need to extend for the query language/endpoitn capabilities 15:01:37 <JacekK> kasei: agree that we should have a class for endpoints, and I'd add a property for saying "this endpoint supports this extension function" and maybe other extensions (entailment regimes etc.) 15:01:39 <AxelPolleres> Kasei: we need URIs for extension functions supported, entailment regimes. 15:01:46 <pgearon> +1 15:01:52 <SimonS> +1 15:01:59 <kasei> Zakim, mute me 15:01:59 <Zakim> kasei should now be muted 15:02:06 <AxelPolleres> http://www.w3.org/2001/sw/DataAccess/ftf4.html#item10 15:02:29 <JacekK> AxelPolleres: the link mentions some of what we've discussed 15:02:56 <JacekK> AxelPolleres: did SADDLE come from that discussion? 15:03:14 <SteveH> SteveH has joined #sparql 15:03:20 <kasei> I can write up a brief proposal 15:03:25 <JacekK> AxelPolleres: volunteers for reviewing the old discussion? 15:03:33 <JacekK> AxelPolleres: thanks kasei 13:25:02 <trackbot> Created ACTION-38 - Write up a brief proposal surrounding service description [on Gregory Williams - due 2009-06-16]. 15:03:45 <JacekK> telcon done # SPECIAL MARKER FOR CHATSYNC. DO NOT EDIT THIS LINE OR BELOW. SRCLINESUSED=00000440