<iv_an_ru> KjetilK, I've read http://www.w3.org/2009/sparql/docs/features/ and it's fully OK for me. Thank you.

<KjetilK> iv_an_ru, great!

<iv_an_ru> AlexPassant, thank you too.

<iv_an_ru> (and I'm sorry but I'm off today)

<kasei> hmm... Zakim usually recognizes me as IPCaller on this line.

<SteveH_> Zakim: ??P22 is [Garlik]

<KjetilK> SteveH_, are you sure?

<kasei> one of the unidentified ones is me. not sure which.

<SteveH_> I'll hang up and try again

<SteveH_> Zakim: KjetilK is [Garlik]

<SteveH_> np :)

<AxelPolleres> http://www.w3.org/2009/sparql/wiki/Agenda-2009-06-09

<scribe> scribe: JacekK

<scribe> scribenick: JacekK

next scribe: Kjetil (tentatively)

<LeeF> Regrets for next week for me [SemTech]

<AxelPolleres> http://www.w3.org/2009/sparql/meeting/2009-06-02

<AxelPolleres> Proposed: approve http://www.w3.org/2009/sparql/meeting/2009-06-02

RESOLUTION: last minutes approved

<AxelPolleres> RESOLVED: http://www.w3.org/2009/sparql/meeting/2009-06-02

liaisons

<bijan> Nope

<bijan> The OWL Specs are going to CR (for the interested)

ericP: nothing from xquery either

AxelPolleres: RIF's final specs will be discussed soon, otherwise nothing

AxelPolleres congratules on OWL CR

actions

ACTION 10 DONE

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

<LeeF> trackbot, close ACTION-10

<trackbot> ACTION-10 Talk to Eric to confirm minutes change from April 21 closed

trackbot, close ACTION-23

<trackbot> ACTION-23 Summarize implicit vs. explicit grouping re ISSUE-11 closed

trackbot, close ACTION-34

<trackbot> ACTION-34 Summarize issue discussed in the end of the telecon regarding PUT closed

trackbot, close ACTION-35

<AxelPolleres> http://www.w3.org/2009/sparql/docs/features/

features and rationales document

<trackbot> ACTION-35 Tell OWL/RIF that SPARQL is content with http://www.w3.org/2007/OWL/wiki/PlainLiteral closed

AxelPolleres: most relevant things already in the document

<LeeF> trackbot, close ACTION-21

<trackbot> ACTION-21 Summarize dataset issue w/ examples / suggestions per ISSUE-8 closed

kjetil: we have pretty much all the text we require, with some open issues

kjetil goes over the document

kjetil: for related discussions, we simply link to the issue tracker

<AxelPolleres> http://lists.w3.org/Archives/Public/public-rdf-dawg/2009AprJun/0346.html

<AxelPolleres> (Andy's comments)

kjetil: none of the issues seem to be bloking, we could go to FPWD on what we have
... we should discuss if any issues need to be addressed before FPWD

<AndyS> ?? 2nd and 3rd ?? Isn't it to be done by end July in prep for charter II?

LukeWM: some implementation text may not be correct (?)

<AndyS> I can make sure it is at least feasible, parser-wise.

kjetil: we may need better examples

<Zakim> LeeF, you wanted to suggest one week of review, then publish (even w/ unresolved issues) then refine

<SteveH_> I'll commit to review it and comment

LeeF: we need to get people to commit to comment on the doc (it's not long)

<chimezie> I can do the same

<AxelPolleres> suggestion is to put remaining issue in ... as Editor's note?

<KjetilK> my summary of issues: http://lists.w3.org/Archives/Public/public-rdf-dawg/2009AprJun/0347.html

ericP: yes, we should make the open issues in a certain style so it's visible

<Zakim> AndyS, you wanted to suggest keeping the issues in the doc

AndyS: the doc must be self-contained even if it's quite rough
... the summary up-front should be finished, frozen and time-stamped

AxelPolleres: it should be in the introduction, right?

<scribe> ACTION: AxelPolleres to draft the introduction with a summary of the issues [recorded in http://www.w3.org/2009/06/09-sparql-minutes.html#action01]

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

<LeeF> ACTION: Axel to draft the introduction with a summary of the issues [recorded in http://www.w3.org/2009/06/09-sparql-minutes.html#action02]

<trackbot> Created ACTION-36 - Draft the introduction with a summary of the issues [on Axel Polleres - due 2009-06-16].

AndyS: if the docs were on the wiki, it'd be easier to contribute text

<LeeF> The OWL WG edits their documents on the wiki and publishes directly from there, but that relies on a lot of SandroMagic (TM)

AxelPolleres: we decided for docs to be edited in CVS

<SteveH_> if the document is in the wiki its harder to track changes

<bijan> Why not use the Wiki for proposed text

AndyS: while we're trying to gather material, wiki would be better

<bijan> and let the editors integrate it

<AndyS> What worked in RIF and OWL?

<AndyS> (worked well)

<bijan> The OWL WG regularly refers to "Wiki maddness"

<bijan> It was bad for publication

<bijan> It was very annoying for editing

<bijan> Brutal, really

<AndyS> OK - if the editors are prepared to "edit" not just "write"

bijan: wiki is good for tweaks by everybody

<AndyS> Sounds like it is not a good as it might be.

bijan: making systematic changes is harder, also seeing what you're doing is harder
... wiki syntax is fragile

AxelPolleres: so let's try to draft things on the wiki, and editors will incorporate that in the doc

bijan: that seems to be a reasonable model

<AxelPolleres> kjetil is speaking

AxelPolleres: at this point, we need more reviewers and comments on the doc
... everyone should review it, but we should have a few actions

volunteers - steve, chime

<SteveH_> by end of week it tight, but I'll try

AxelPolleres: if the reviews arrive by end of week, we might already have a good almost-final material for the FPWD next week
... for FPWD, we might just go with what we have with some refinement, or does somebody suggest we need a detailed review?

AndyS: I've done a single, not very complete, read-through

kjetil: people should also just have a look at the open issues (posted by Axel on my behalf)
... let's go through them quickly right now
... 1) we need a short name

<AxelPolleres> http://lists.w3.org/Archives/Public/public-rdf-dawg/2009AprJun/0347.html

kjetil: 2) examples should be implemented (we should confirm this)
... 3) service descriptions should prolly be a section by itself
... 4) suggestion for new version of the protocol

<LeeF> We haven't explicitly discussed project expressions, which is why

kjetil: 5) we need to check project expressions if there should be some material
... 6) patent policy (?)

ericP: just the boiler plate, we need not think about it

<LeeF> I can name 2 project expression issues off the top of my head - syntax for expressions & whether expression alias names are required

kjetil: 7) some linking consistency

AxelPolleres: service descriptions in their own section - any objections?

<LeeF> +1 to serv descrip in own section, for the time being at least

<LeeF> it may end up having protocol aspects, or query aspects, or neither

<SteveH_> +1

kasei: the separate section might imply that implementors can deel with this modularly
... somebody could implement query, protocol but not service descriptions

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

<AndyS> Not sure I agree - the service description might be 3rd party (woudl like 1st party but realistically?)

<KjetilK> +1

<AxelPolleres> +1 to own section "Service Description"

<kasei> +1 LeeF

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

AxelPolleres: so we'll put svc descriptions in its own section, with an issue that it may belong to protocol or query

<AxelPolleres> RESOLVED: we will have an own section "Service Description"

service descriptions

AxelPolleres: we need a bit of a better idea on what we need

<LeeF> ISSUE: Is service description part of the protocol, the query language, or something else altogether?

AxelPolleres: we have several proposals
... 1) the issue was discussed already a long time ago in WG1

<AxelPolleres> http://www.w3.org/2001/sw/DataAccess/ftf4.html#item10

AxelPolleres: the first WG's ftf4 lists some proposals
... the f&r doc could use some of that, e.g. for use cases

<AxelPolleres> http://www.w3.org/2009/sparql/track/issues/23

AxelPolleres: the issue on media types & conneg is related

<AxelPolleres> http://www.w3.org/2009/sparql/meeting/2009-05-06#Full__2d_text_search

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
... we could just provide the mechanism and some examples

<AndyS> +1 to small (minimal) framework + *suggestions* to use other vocabs

ericP: an endpoint might support DESCRIBE or similar queries about itself
... we may want to write down some obvious things, such as a class of SPARQL endpoints

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

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

SteveH_: I'm also uncomfortable about requiring some data to be in the endpoint
... must prefer an HTTP header that would point to the description

<kasei> in addition to an Endpoint class, I'd think at minimum we should define properties for extension points (functions, possibly entailment regimes)

ericP: if we have the description, then we'd also want an endpoint that can query them

SteveH_: if the HTTP header gives you a URI, you can just do FROM that URI

<kasei> heh

ericP: I find it easier to specify graphs than to add HTTP headers

<AndyS> SOAP?

SteveH_: it took me less than an hour to add the header, but embedding dynamic data in the endpoint is harder

ericP: the header may also not make it through proxies
... I meant it's difficult to specify the HTTP header, not to implement it - we'd need to involve IETF, HTTP extensibility, RFC iterations...

<chimezie> What is the Atom precedence here?

AndyS: some use cases, where the endpoint is not the one offering the description
... a repository (UDDI-like situation)

<AxelPolleres> that's an interesting one.

AndyS: all discussion now has focused on the endpoint describing itself

<LeeF> chimezie, good question

AxelPolleres: is there an issue in the authority of descriptions?

<chimezie> Atom appears to have an explicit 'service document' with a known URI

AxelPolleres: what's the use case for 3rd party description of an endpoint?

<LeeF> chimezie, EliasT tells me that Atom Publishing Protocol (APP) has a well-known service.xml file

<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

<AndyS> Currently - It is not part of the protocol. Must have "query="

ericP: query is a required parameter

AxelPolleres: could we add a new behavior there?

<LeeF> chimezie, he says you can find it via a meta tag in HTML

ericP: it's currently an error, and our WSDL description would then be "everything-optional"

<chimezie> hmmm..

ericP: but an error could be reasonable if the request is not recognized - an old system

<Zakim> AndyS, you wanted to mention 3rd party use

<Zakim> AxelPolleres, you wanted to ask whether we could obtain the service description by simply Get [entpoint] requesting mime type rdf/xml?

<LeeF> chimezie, EliasT points me to http://www.ibm.com/developerworks/xml/library/x-atomsidebar/index.html

<chimezie> [[[

<chimezie> How Service Documents are discovered is not defined in this

<chimezie> specification.

<chimezie> ]]] -- Atom Pub

JacekK: one of the ways to get the description would be HTTP OPTIONS

<SteveH_> http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

<SteveH_> OPTIONs

<LeeF> I wouldn't knw where to start to implement something via OPTION

<AndyS> Do you get content neg on OPTIONs?

<ericP> http://www.w3.org/Protocols/rfc2616/rfc2616-sec9#sec9.2

<Zakim> JacekK, you wanted to suggest HTTP OPTIONS

<SteveH_> AndyS, yes

<AndyS> OPTION * is tricky but otherwise servelet API would route it.

<AndyS> Thx Steve

JacekK: OPTIONS is used to discover, for example, which of GET/POST/PUT/DELETE is available

<kasei> might run into trouble using OPTION in many www client APIs

JacekK: HTTP currently doesn't specify what can be returned as the body of the response

AxelPolleres: time is running out, any volunteer to summarize this in an email, or the wiki?

ericP: steve and I should have an argument on the wiki
... but I'll be quite busy the upcoming weeks

SteveH_: I've already put my thoughts on the wiki
... I didn't add anything about the query language stuff, not expecting that we'd even consider it

<AxelPolleres> ACTION: Eric to add to http://www.w3.org/2009/sparql/wiki/Feature:ServiceDescriptions about different options to serve descriptions [recorded in http://www.w3.org/2009/06/09-sparql-minutes.html#action03]

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

LeeF: what did you mean by the query lang stuff?

<AxelPolleres> ACTION: Jacek to add to http://www.w3.org/2009/sparql/wiki/Feature:ServiceDescriptions about different options to serve descriptions (specifically HTTP OPTION) [recorded in http://www.w3.org/2009/06/09-sparql-minutes.html#action04]

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

<AxelPolleres> Eric: at least type sparqlendpoint

<AxelPolleres> Orri: each feature should have a URI.

<AxelPolleres> http://lists.w3.org/Archives/Public/public-rdf-dawg/2009AprJun/0299.html

<kasei> I'm here

AxelPolleres: we prolly don't want to standardize a full description language
... a Note could be an option

<AxelPolleres> Orri: void good for the data, but we need to extend for the query language/endpoitn capabilities

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.)

<AxelPolleres> Kasei: we need URIs for extension functions supported, entailment regimes.

<pgearon> +1

<SimonS> +1

<AxelPolleres> http://www.w3.org/2001/sw/DataAccess/ftf4.html#item10

AxelPolleres: the link mentions some of what we've discussed
... did SADDL come from that discussion?

<LeeF> i think

<kasei> I can write up a brief proposal

AxelPolleres: volunteers for reviewing the old discussion?
... thanks kasei

telcon done

<AxelPolleres> ACTION: Kasei to start with a proposal for service descriptions to trigger mail discussion [recorded in http://www.w3.org/2009/06/09-sparql-minutes.html#action05]

<LeeF> I'll take care of that, JacekK

<kasei> Axel: does that include both vocab and access mechanism?

<LeeF> thanks for scribing!

sure thing! 8-)

<kasei> the discussion at the end was vocab, and it seemed some of the access stuff was covered by another action.

bye all

<ericP> LeeF, something like[[ SELECT ?v { <> void:description ?v } ]] would pass through proxies 'cause you only need to call the service <>

<ericP> wait, that'd be base

<AxelPolleres> kasei: my personal opinion, vocab is covered partially already by others, let's check what is necessary, but NOT covered byt things like void.

<kasei> I may be unclear on what my action is, then :)

<AxelPolleres> lee, eric... seems we forgot trackbot this time, or it dropped?

<AxelPolleres> so, I guess actions need to be recorded manually?

<AxelPolleres> Bye all!

<ericP> 2009-06-09T14:31:00Z -!- trackbot [trackbot@128.30.52.30] has quit [Connection reset by peer]

<LeeF> AxelPolleres, we had the bot for half the time

<AxelPolleres> yup.

<LeeF> we'll have to muddle through to repair things

<AxelPolleres> need to run, if you had time to clean up/complete the actions now, I 'd appreciate, otherwise, I can try after RIF.

<trackbot> Getting data for channel #sparql at http://www.w3.org/2009/sparql/track//api/users failed - alert sysreq of a possible bug

<AxelPolleres> eric, may I kindly ask for the minutes magic again :-) thnx!

<LeeF> AxelPolleres, ericP doesn't know the minutes magic :-)

<ericP> AxelPolleres, it works this way:

<ericP> LeeF, please make minutes happen

<AxelPolleres> LeeF, please make minutes happen

<AxelPolleres> :-)

<LeeF> AxelPolleres, I do not understand 'please make minutes happen'

<ericP> crappy bot

<LeeF> ericP, I do not appreciate 'crappy bot'

<ericP> espece de bot

<AxelPolleres> http://www.w3.org/2009/06/09-sparql-minutes.html didn't work, it seems.

<LeeF> AxelPolleres, I'm having trouble with lots of things, so I'll try again later today

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/subsection/section/
Succeeded: s/bijan/LeeF/
Succeeded: s/saddle/SADDL/
Found Scribe: JacekK
Inferring ScribeNick: JacekK
Found ScribeNick: JacekK
Default Present: +539149aaaa, AxelPolleres?, bijan, +1.216.445.aabb, john-l, +005aacc, SimonS, bglimm, AndyS, kasei, SteveH_, LukeWM, JacekK, Chimezie_Ogbuji, pgearon, EricP, LeeF, Prateek
Present: +539149aaaa AxelPolleres? bijan +1.216.445.aabb john-l +005aacc SimonS bglimm AndyS kasei SteveH_ LukeWM JacekK Chimezie_Ogbuji pgearon EricP LeeF Prateek

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


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Got date from IRC log name: 09 Jun 2009
Guessing minutes URL: http://www.w3.org/2009/06/09-sparql-minutes.html
People with action items: axel axelpolleres eric jacek kasei

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.