Chatlog 2009-06-09

See original RRSAgent log and preview nicely formatted version.

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