See also: IRC log
<scribe> scribenick: AxelPolleres
Lee: clarification... Wg is open
only to W3C members, although we conduct work in public
... minutes, agenda, wiki are all public and encouraged to be shared.
Lee: if you want to keep something non-public, mail us (team/chairs)
minutes from last time are on the web.
PROPOSED: accept minutes from last week
<bijan> I just look and they look ok
RESOLUTION: minutes from last week approved
next meeting: 10am US time, 1400Z
LeeF: we have intros linked from
... encourage others to supply intros
john-l: chime and i missed last week
john-l: 2nd rep for cleveland
clinic (cleveburg OH)
... chime and i are working on an impl, hoping to push mods back into spec
chime: john-l and i work on a patient registry
chime: we've done a hand full of improvements. expect they are useful in general
ivan: ivan the elder
... W3C semweb activity lead
... 2nd contact
yimin: working in lilly
... working on data integration projects in lilly
... looking for insert/delete, stuff like that
souri: Souri Das, Oracle
... was part of DAWG. passionate about it as i expect it to be useful for DI in general
LeeF, we might want a tracker intro under logistics
<LeeF> ericP, yes, i agree, but am not prepared to do it at the moment :)
AxelPolleres: liasons are
supposed to connect us with other groups touching our
... need liasons with three W3C groups:
AxelPolleres: .. OWL
... .. RIF
... .. RDB2RDF
<bijan> HCLS interest group
AxelPolleres: any other
... would like liason status update at beginnings of meetings
<bijan> I think it's overkill to do it each telecon...generally, there's fewer occasions to mention
RESOLUTION: Bijan appointed OWL liason
<iv_an_ru> Orri and I are in RDB2RDF
<AxelPolleres> Bijan: additional liaison XQuery?
<bijan> +1 to eric for liasing with HCLS
RESOLUTION: ericP appointed HCLS liason
RESOLUTION: orri appointed RDB2RDF liason
RESOLUTION: axel appointed RIF liason
<Zakim> ericP, you wanted to say i have good contact with HCLS
<AxelPolleres> Should we "advertise" to them? maybe someone was interested to join us, at least to follow?
<AndyS> XQuery are also working on full text search
but i was locally muted
<AndyS> s/arealoo/are also/
ericP: expect that we will need to touch XQuery if we import more XPath functions
LeeF: most folks have tougher travel restrictions than in the past
<iv_an_ru> we will need to touch XQuery if we extend XQuery with SPARQL :)
LeeF: don't expect to have our
four meetings this year
... hope to have a f2f a couple months from now when we settle on our deliverables
PROPOSED: host first f2f 5-6May in Cambridge, MA, USA -- (other telecon sites may be amendmants)
<bijan> tues are potentially bad
<AndyS> May 6,7 is preferrable to me as well. Can make May 5 if necessary
<bijan> I can't do tues easily
<AxelPolleres> eric: rooms might be a problem 7-8
<bijan> 2 days
<chimezie> +1 2 days
<ywang4> 2 days should be fine
<SteveH> +1 2 days
<ivan> 2 days (it is hard to keep up work of that intensity for 3 days)
<souri2> May 6-7 is better for me. 2 days.
<AndyS> 2 days unless it is clear 3 is needed
<bijan> Can't do the 5th
<bijan> (most likely)
<AxelPolleres> no preference
<ywang4> okay, i can try to adapt
<iv_an_ru> My US visa has expired so I'm probably missing the f2f.
<AxelPolleres> let's tentatively fix 6-7 shall we also set up a questionaire?
<SteveH> +q to ask about multi site
<bijan> I think chairs decision is fine
<Zakim> SteveH, you wanted to ask about multi site
<bijan> As long as it's announced far enough in advance...8 weeks
<AndyS> I can ask our comms people about a telecon link
<bijan> I can ask about access grid access
<LeeF> Pick other (U.K. / Europe?) site in the next week or two, please send possibilities to mailing list
PROPOSED: host first f2f 6-7May in Cambridge, MA, USA -- (other telecon sites may be amendmants)
<souri2> What will be the hours for F2F?
<Zakim> ericP, you wanted to mention video room availability
<bijan> Manchester has a room
<bijan> HP has one...I've seen it :)
<iv_an_ru> use case 1: TPC-H
<iv_an_ru> (we pass it in SPARQL :)
LeeF: 1st phase: define what
features we want to work on
... we're bound to 18 months, including spec, tests, impl report
... likely a very small set. need to settle on them in the next month
<AxelPolleres> Please indicate your availability for F2F1 on the wiki page: http://www.w3.org/2009/sparql/wiki/F2F1
LeeF: we're blurring the line
between use case and feature
... e.g. "peform aggregate functions", "query over arbitrary length tasks"
... we're not aiming for higher-level use cases, à la "Bob runs a stereo store..."
... looking for examples, implementations
<iv_an_ru> use case 2: a graph with Gantt chart, personal calendars and some trivial validation.
LeeF: need a champions who will speak in depth about the feature
bijan: would we do one req, or stagger them?
LeeF: should we write todo list or a priority list?
bijan: i like getting things
... but there's value publicity of a slew of things
... but if we can get stuff out
AndyS: knocking off some easy ones would get the community engaged
<bijan> +1 to AndyS
<SteveH> +1 to AndyS
AndyS: i like to work on one thing at a time, and do it properly
ivan: short charter, and rec
process takes time and energy
... publishing several things in a staggered way could backfire
... bijan, is the idea to pub sparql1,1, 1,2, 1.3?
bijan, was wondering if we could modularize parts into specs.
scribe: e.g. separate owl semantics spec
<bijan> The HTML5 spec indicates the stability levels of different *sections* of the spec...which might be good for implementors
LeeF: modularizing sounds great, if we can modularize ourselves
<AndyS> +1 to modularization (if it does not cause rework just for modulrity)
<Zakim> bijan, you wanted to answer
ericP: could modularize sections, do tests and impl reports, and package as a spec when we get near the end
AxelPolleres: use cases should
identify which spec they affect (e.g. protocol, xml results
... we've listed deliverables in the charter. we're not bound to that?
LeeF: nope. our deliverables will fall out from our use cases
iv_an_ru: not sure the final doc
should be a single spec, e.g. SPARQL1.1
... they [features] are more useful when used together
... when i need business intelligence, i need it on everything
<ivan> +1 to iv_an_ru
LeeF: don't expect us to break up core parts
<Zakim> SteveH, you wanted to ask about terminology
<bijan> The spec shouldn't have everything it but neither should it be the minimal publishable unit
LeeF: don't want to lose interop if all these features are on their own specs
SteveH: do we want use cases?
<bijan> New features + rationale?
SteveH: am nagged by calling features "use cases"
SteveH: just want to call them what they are
<chimezie> then perhaps we should be a little more explicit in the request for what we want (usecase v.s. feature request)
<bijan> (The OWL document is called "new features and rationales"
LeeF: agreed. would like to dive straight into features
SteveH: when we prioritize, we'll talk about use cases, regardless of whether we write them down
<AndyS> While features are natural/obvious this is OK but if one comes along which the WG as a whole finds unobvious, we need to back off to use cases.
<LeeF> +1 to AndyS_
AxelPolleres: template rationale: thought the features we want to add should be driven by practical examples
<iv_an_ru> use cases should be written down at least in our wiki, if not in final docs, because they demonstrate how features "interoperate".
<bijan> Use cases doesn't exhaust...e.g., implementability are also considerations
AxelPolleres: had in mind to
merge use cases in the 2nd phase
... good feature requests often have a use case around them
<iv_an_ru> Let's think that everything is implementable :)
<bijan> So, new feature: "Awesome feature"; rationale: "here's the intuition", "here's the implementation considerations", "here's some use cases"
AxelPolleres: if you a system with .e.g aggregates, add you syntax to that feature
<bijan> Are we all registered in the wiki? If not what do we do?
<SteveH> +1 to calling the features and having a usecase subsection
LeeF: let's call them features (tweak the template), add a section for use cases under each feature, and have example syntaxes for the feature
<LukeWM> +1 to that too
<ywang4> will go offline shortly, have fun :)
APPROVED: rename "use cases" to "features"
<bijan> Did I miss the in
<bijan> structiosn for getting on the wiki?
<bijan> Oh. Ewwwww
<LeeF> I'll send a bunch about this in email
<Zakim> AndyS, you wanted to ask about outside contributions
AndyS: what about folks who are
not in the group, but plan to join
LeeF: would like folks to send to public-rdf-dawg-comments
<bijan> +1 to open solicitation
<SteveH> risks a lot of work sorting out duplicates
AndyS: danger of opening floodgate
<SteveH> but still +1
<bijan> We can always say "no" :)
<LeeF> I'll take the responsibility for sorting out dupes :-)
<bijan> No specification without championiation!
<iv_an_ru> We can invite people to read the wiki before (re)submitting proposals :)
<LeeF> iv_an_ru +1
<AxelPolleres> heavy echo
<bijan> ta ta
<AxelPolleres> scribenick: AxelPolleres
Ivan: we can allow input from those who intend to join.
Lee: Will sned an email on the list to gather as many features as we can by next week.
<iv_an_ru> Even more, implementation providers may announce in their support mailing lists that they collect wishes for SPARQL 2.0 and act as proxies.
<AndyS> SPARQL 1.1 please. Not 2.0. It's incremental!
Lee: Is it appropriate to list that on the blog as well.
<SteveH> +1 to SPARQL 1.1
<iv_an_ru> ok, SPARQL 1.1
Ivan: Next week will be messy, since meeting is one hour earlier!!!
<LeeF> AxelPolleres, do you want to try to follow the scribe instructions, or would you like me to?