14:34:19 <LeeF> -> http://www.w3.org/2009/sparql/wiki/Feature:Assignment

14:35:18 <SteveH> AndyS: the idea is to have explicit statement when you want to bind a variable to a value, strongly related to expressions in subselects, similar but assgnments can be said to be clearer, assignment could be a syntactic way of doing the other thing

14:35:22 <SteveH> q+

14:35:33 <SteveH> AndyS: implemented in ARQ, it's quite popular

14:36:04 <SteveH> LeeF: is assingment purely syntactic if we have susbselect and named projection

14:36:14 <SteveH> AndyS: not sure about scoping, but they're clearly related

14:36:15 <LeeF> ack SteveH

14:36:44 <LeeF> SteveH: Assignment as a native feature rather than syntactic sugar scares me - doesn't seem to fit into a query language

14:36:53 <LeeF> SteveH: ...given my background

14:37:22 <Zakim> -Orri

14:37:27 <SteveH> AndyS: similar thing is the ability to put an expression inline, syntactic sugar for putting a [something] in there

14:37:47 <ericP> q+

14:37:50 <SteveH> AndyS: it doesn't introduce a binding, but it's in the same space

14:37:50 <LeeF> http://www.w3.org/2009/sparql/wiki/Feature:ScalarExpressionsInTriplePatterns

14:37:58 <LeeF> ack ericP

14:38:13 <SteveH> ericP: I would argue that creating a varaible is doable in SQL, but you name it with the expression name

14:38:16 <bijan> XQuery has lots of variables :)

14:38:19 <chimezie> My main concern (in addition to possible redundancy with subselects) is control of recursion which is handled 'naturaly' by sub-select and grouped graph patterns

14:38:20 <bijan> For...Let...

14:38:24 <SteveH> ericP: in SPARQL we would just name it with a bound variable name

14:38:28 <SteveH> q+ to reply

14:38:45 <SteveH> AndyS: you cant write a recursive expression

14:38:55 <bijan> But I share SteveH's inclination toward fear. But I also share his sense that it might be an unwarrented fear :)

14:39:03 <Zakim> +??P14

14:39:12 <LeeF> zakim, ??P14 is Orri

14:39:12 <Zakim> +Orri; got it

14:39:30 <SteveH> chimezie: doesn't it depend on evaluation model, you could assign to an expression that is refered to outside

14:39:37 <SteveH> AndyS: the prosoal doesnt cover that

14:39:45 <LeeF> s/prosoal/proposal

14:39:55 <kjetil> ack SteveH

14:39:55 <Zakim> SteveH, you wanted to reply

14:39:58 <JanneS> AndyS, can/could there be function calls on the right side of the assignment? Or do you implement that in ARQ?

14:40:01 <ericP> SteveH: in SQL it doesn't *look* like a variable assignment

14:40:16 <LeeF> SteveH: +1 to Eric that you can do similar in SQL, but it doesn't look like assignment - it's the syntax that scares me since it looks like an assignment, it's non-obvious how it works

14:40:21 <AndyS> q+

14:40:22 <ericP> ... i don't know the scope. is it pure functional?

14:40:29 <bijan> q+ to ask for pointers to examples

14:40:31 <ericP> ... worried about user expectations

14:41:03 <SteveH> AndyS: can have functions on RHS

14:41:23 <SteveH> AndyS: these issues will all arise, but now talking about details of mechanism, quaestion is do we want this feature

14:41:29 <bijan> zakim, unmute me

14:41:29 <Zakim> bijan should no longer be muted

14:41:32 <LeeF> ack bijan

14:41:32 <Zakim> bijan, you wanted to ask for pointers to examples

14:41:42 <kjetil> ack AndyS

14:41:50 <SteveH> bijan: wondering if andy has pointers to examples from users, having trouble wrapping mind around standard functions

14:41:58 <AndyS> http://www.w3.org/2009/sparql/wiki/Feature:Assignment

14:42:24 <SteveH> bijan: looking for app examples, where used in anger

14:42:44 <JanneS> If functions are allowed on right side, maybe those who map SPARQL to SQL could not evaluate such expressions?

14:42:47 <SteveH> AndyS: used particularly in the case where there's a CONTRCUT

14:42:53 <chimezie> -> http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2009Mar/0009.html Holger's commets

14:43:00 <bijan> zakim, mute me

14:43:00 <Zakim> bijan should now be muted

14:43:00 <LeeF> q?

14:43:09 <AndyS> Janne - yes and same as FILTER situation isn't it?

14:43:21 <JanneS> yup

14:43:24 <SteveH> LeeF: anyone else implemented it

14:43:33 <LeeF> SimonS: we did it but only internally - very useful

14:43:34 <SteveH> SimonS: we did it internally, but can't say anything about user requirements

14:43:48 <SteveH> LeeF: straw poll

14:43:49 <SteveH> -1

14:43:54 <kjetil> +1

14:43:56 <kasei> +1

14:43:57 <SteveH> q+

14:43:57 <AlexPassant> +1

14:44:00 <chimezie> -1

14:44:00 <LukeWM> 0

14:44:02 <SteveH> q-

14:44:02 <john-l> 0

14:44:05 <ericP> +1

14:44:07 <bijan> +0

14:44:09 <SimonS> +1

14:44:11 <AndyS> +1

14:44:14 <ivanh> 0

14:44:14 <JanneS> +1

14:44:27 <dnewman2> 0

14:44:34 <LeeF> Orri: -1 un-query-language like

14:44:38 <LeeF> 0

14:44:52 <SteveH> LeeF: fan of feature, but happy to be able to do it other ways

14:45:16 <LeeF> topic: accesing rdf lists

<LeeF> summary: initial straw poll gives (+/0/-): 13/0/3

14:45:16 <LeeF> http://www.w3.org/2009/sparql/wiki/Feature:AccessingRdfLists

Lee Feigenbaum: http://www.w3.org/2009/sparql/wiki/Feature:AccessingRdfLists ←

14:45:34 <SteveH> AndyS: desire i to access all memers of a list in a length-neutral way

Andy Seaborne: desire i to access all memers of a list in a length-neutral way ←

14:45:47 <SteveH> AndyS: can do it with fixed length lists in some caes, but it gets burdensome

Andy Seaborne: can do it with fixed length lists in some caes, but it gets burdensome ←

14:46:04 <ericP> q+ to say this will be a bit difficult, but is probably the most important thing we could do for the semantic web

Eric Prud'hommeaux: q+ to say this will be a bit difficult, but is probably the most important thing we could do for the semantic web ←

14:46:13 <SteveH> AndyS: have some way in lang. to get one member per row, could also do most of it with property paths, except that the tail is isself a list

Andy Seaborne: have some way in lang. to get one member per row, could also do most of it with property paths, except that the tail is isself a list ←

14:46:21 <SteveH> AndyS: so you get duplicates

Andy Seaborne: so you get duplicates ←

14:46:22 <ivanh> q+

Ivan Herman: q+ ←

14:46:40 <SteveH> AndyS: implemented in ARQ, looks like rdfs:member, but applies to lists

Andy Seaborne: implemented in ARQ, looks like rdfs:member, but applies to lists ←

14:46:58 <SteveH> AndyS: used where you don't have closed lists

Andy Seaborne: used where you don't have closed lists ←

14:47:16 <SteveH> Orri: we have general transitive subquery, maybe be macro expanded into subquery

Orri Erling: we have general transitive subquery, maybe be macro expanded into subquery ←

14:47:22 <SteveH> orri: no special synta

Orri Erling: no special synta ←

14:47:22 <john-l> Is that transitive subquery feature listed on the Wiki?

John Clark: Is that transitive subquery feature listed on the Wiki? ←

14:47:31 <ivanh> s/synta/syntax/

Ivan Herman: s/synta/syntax/ ←

14:47:33 <LeeF> q?

Lee Feigenbaum: q? ←

14:47:34 <SteveH> Orri: we would not mid making shorthand

Orri Erling: we would not mid making shorthand ←

14:47:36 <LeeF> ack ericP

Lee Feigenbaum: ack ericP ←

14:47:36 <Zakim> ericP, you wanted to say this will be a bit difficult, but is probably the most important thing we could do for the semantic web

Zakim IRC Bot: ericP, you wanted to say this will be a bit difficult, but is probably the most important thing we could do for the semantic web ←

14:48:31 <SteveH> ericP: useful impl. requires ordered results, probably. added in two different implementations to get members of a list, to match any memmbers of a list, to treat as unordered, its not that hard to do, just hard to spec

Eric Prud'hommeaux: useful impl. requires ordered results, probably. added in two different implementations to get members of a list, to match any memmbers of a list, to treat as unordered, its not that hard to do, just hard to spec ←

14:48:33 <LeeF> q?

Lee Feigenbaum: q? ←

14:48:35 <LeeF> ack ivanh

Lee Feigenbaum: ack ivanh ←

14:48:55 <ericP> members(?x) ordered("1" "2") unordered("2" "1")

Eric Prud'hommeaux: members(?x) ordered("1" "2") unordered("2" "1") ←

14:49:00 <ericP> +1 to ivanh's point

Eric Prud'hommeaux: +1 to ivanh's point ←

14:49:22 <SteveH> ivanh: i really believe its important, I've seen several people defineing vocabs, wanted to use lists, but instead they do something convoluted because lists cannot be sparql'd

Ivan Herman: i really believe its important, I've seen several people defineing vocabs, wanted to use lists, but instead they do something convoluted because lists cannot be sparql'd ←

14:49:33 <AlexPassant> +1 wrt vocabulary design

Alex Passant: +1 wrt vocabulary design ←

14:49:33 <SteveH> ivanh: so had negative effect on the way vocabs were defined

Ivan Herman: so had negative effect on the way vocabs were defined ←

14:49:33 <chimezie> AndyS�:� assuming we had property paths, couldn't the fact tha the list tail is also a list be handled by excluding it from the results?

Chime Ogbuji: AndyS�:� assuming we had property paths, couldn't the fact tha the list tail is also a list be handled by excluding it from the results? ←

14:49:40 <chimezie> since the tail is always rdf:nil

Chime Ogbuji: since the tail is always rdf:nil ←

14:49:48 <LeeF> s/AndyS:/AndyS,

Lee Feigenbaum: s/AndyS:/AndyS, ←

14:50:12 <SteveH> chimezie: q for AndyS about property paths, if you had prop paths you could overcome by filtering out the tail

Chime Ogbuji: q for AndyS about property paths, if you had prop paths you could overcome by filtering out the tail ←

14:50:22 <SteveH> AndyS: it's the rdf:nil that's that issue

Andy Seaborne: it's the rdf:nil that's that issue ←

14:50:31 <SteveH> LeeF: any subset of the list, looks like a list

Lee Feigenbaum: any subset of the list, looks like a list ←

14:50:34 <AndyS> s/it's/it's not/

Andy Seaborne: s/it's/it's not/ ←

14:50:35 <ericP> (1 2 3) => (2 3) => (3) => ()

Eric Prud'hommeaux: (1 2 3) => (2 3) => (3) => () ←

14:50:41 <bijan> I.e., lists aren't objects with distinct boundaries in RDF

Bijan Parsia: I.e., lists aren't objects with distinct boundaries in RDF ←

14:50:54 <SteveH> chimezie: I'm pretty familiar with path-based, been able to get all the entries

Chime Ogbuji: I'm pretty familiar with path-based, been able to get all the entries ←

14:51:11 <SteveH> LeeF: my experiance has been that I'm mostly querying for a specific member

Lee Feigenbaum: my experiance has been that I'm mostly querying for a specific member ←

14:51:15 <SteveH> +1 to LeeF

+1 to LeeF ←

14:51:16 <AndyS> http://lists.w3.org/Archives/Public/public-rdf-dawg/2009JanMar/0100.html

Andy Seaborne: http://lists.w3.org/Archives/Public/public-rdf-dawg/2009JanMar/0100.html ←

14:51:41 <SimonS> +q any example, where you do not know the head?

Simon Schenk: +q any example, where you do not know the head? ←

14:51:45 <bijan> Redundant answers can also be a problem

Bijan Parsia: Redundant answers can also be a problem ←

14:51:55 <LeeF> ack SimonS

Lee Feigenbaum: ack SimonS ←

14:52:10 <SteveH> SimonS: can you give an example of realworld query where don't know the head

Simon Schenk: can you give an example of realworld query where don't know the head ←

14:52:19 <SteveH> SimonS: whenever I query a list I know the head

Simon Schenk: whenever I query a list I know the head ←

14:52:26 <bijan> q+

Bijan Parsia: q+ ←

14:52:43 <SteveH> AndyS: to some extent it's a corner case, but can produce a lot of questions

Andy Seaborne: to some extent it's a corner case, but can produce a lot of questions ←

14:52:48 <bijan> zakim, unmute me

Bijan Parsia: zakim, unmute me ←

14:52:48 <Zakim> bijan should no longer be muted

Zakim IRC Bot: bijan should no longer be muted ←

14:52:54 <LeeF> ack bijan

Lee Feigenbaum: ack bijan ←

14:52:55 <SteveH> AndyS: if you try to get into explaining then it causes confusion

Andy Seaborne: if you try to get into explaining then it causes confusion ←

14:53:15 <SteveH> bijan: I would have thought that problem is that when you think you have the query, you're actually punching into the middle

Bijan Parsia: I would have thought that problem is that when you think you have the query, you're actually punching into the middle ←

14:53:26 <SteveH> bijan: you could end up querying the tail, that would be a worry

Bijan Parsia: you could end up querying the tail, that would be a worry ←

14:53:44 <bijan> zakim, mute me

Bijan Parsia: zakim, mute me ←

14:53:44 <Zakim> bijan should now be muted

Zakim IRC Bot: bijan should now be muted ←

14:53:58 <ivanh> +1

Ivan Herman: +1 ←

14:53:59 <kjetil> +1

Kjetil Kjernsmo: +1 ←

14:54:01 <ericP> +1

Eric Prud'hommeaux: +1 ←

14:54:01 <bijan> +1

Bijan Parsia: +1 ←

14:54:02 <AlexPassant> +1

Alex Passant: +1 ←

14:54:02 <SteveH> LeeF: strawpoll on rdf lists query mechanism

Lee Feigenbaum: strawpoll on rdf lists query mechanism ←

14:54:02 <LukeWM> +1

Luke Wilson-Mawer: +1 ←

14:54:04 <AndyS> +1

Andy Seaborne: +1 ←

14:54:04 <john-l> +1

John Clark: +1 ←

14:54:04 <SteveH> +1

+1 ←

14:54:04 <kasei> +1

Greg Williams: +1 ←

14:54:06 <JanneS> +1

Janne Saarela: +1 ←

14:54:07 <chimezie> -1 (I'm not convinced that property-path based querying doesn't resolve the real world issue with accessinglists)

Chime Ogbuji: -1 (I'm not convinced that property-path based querying doesn't resolve the real world issue with accessinglists) ←

14:54:12 <dnewman2> +1

Dave Newman: +1 ←

14:54:17 <bijan> (and I hate rdf:lists :))

Bijan Parsia: (and I hate rdf:lists :)) ←

14:54:20 <SimonS> -1 ack with chimezie

Simon Schenk: -1 ack with chimezie ←

14:54:25 <LeeF> Orri: +1

Orri Erling: +1 [ Scribe Assist by Lee Feigenbaum ] ←

14:54:41 <LeeF> -1 (with Simon & Chime)

Lee Feigenbaum: -1 (with Simon & Chime) ←

14:55:01 <ivanh> q+

Ivan Herman: q+ ←

14:55:06 <bijan> q+ to ask about the property path solution people

Bijan Parsia: q+ to ask about the property path solution people ←

14:55:34 <SteveH> ivanh: if it works with prop paths, the q I have is if prop paths doesn't do it would you still have -1

Ivan Herman: if it works with prop paths, the q I have is if prop paths doesn't do it would you still have -1 ←

14:55:50 <SteveH> ?: if it doesn't I would

?: if it doesn't I would ←

14:56:01 <ivanh> ack ivanh

Ivan Herman: ack ivanh ←

14:56:04 <SteveH> LeeF: I'm indifferent if we do property paths or not

Lee Feigenbaum: I'm indifferent if we do property paths or not ←

14:56:08 <bijan> q-

Bijan Parsia: q- ←

14:56:09 <SteveH> thanks

thanks ←

14:56:20 <bijan> I had ivanh's question :)

Bijan Parsia: I had ivanh's question :) ←

14:56:23 <SteveH> ericP: +1 on having list access as a requirement, however we do it

Eric Prud'hommeaux: +1 on having list access as a requirement, however we do it ←

14:56:34 <SteveH> ivanh: if property paths work, then I happy to sump special syntax

Ivan Herman: if property paths work, then I happy to sump special syntax ←

14:56:36 <SteveH> q+

q+ ←

14:56:38 <bijan> Though, special syntax should be evaluated separately

Bijan Parsia: Though, special syntax should be evaluated separately ←

14:56:50 <SteveH> orri: it seems that property paths would have to be extended

Orri Erling: it seems that property paths would have to be extended ←

14:56:58 <SteveH> orri: email about that on the list

Orri Erling: email about that on the list ←

14:57:03 <LeeF> ack SteveH

Lee Feigenbaum: ack SteveH ←

14:57:03 <bijan> Property Paths are way more heavyweight than special list handling

Bijan Parsia: Property Paths are way more heavyweight than special list handling ←

14:57:20 <bijan> +1 SteveH

Bijan Parsia: +1 SteveH ←

14:57:24 <LeeF> SteveH: counterpoint - in favor of accessing lists, not in favor of property paths

Steve Harris: counterpoint - in favor of accessing lists, not in favor of property paths [ Scribe Assist by Lee Feigenbaum ] ←

14:57:38 <ericP> SteveH: in favor of accessing lists, opposed to property paths as they seem complicated

Steve Harris: in favor of accessing lists, opposed to property paths as they seem complicated [ Scribe Assist by Eric Prud'hommeaux ] ←

14:57:40 <bijan> I could see implementations wanting to support lists but not property paths

Bijan Parsia: I could see implementations wanting to support lists but not property paths ←

14:57:46 <SteveH> yup

yup ←

<LeeF> topic: wiki maintenance

14:58:12 <SteveH> LeeF: bijan asked if anyone would object to moving feature pages so they're not in feature:

Lee Feigenbaum: bijan asked if anyone would object to moving feature pages so they're not in feature: ←

14:58:21 <ericP> don't all of our features start with F?

Eric Prud'hommeaux: don't all of our features start with F? ←

14:58:26 <JanneS> sorry, could only do 60mins today - cu

Janne Saarela: sorry, could only do 60mins today - cu ←

14:58:26 <Zakim> -JanneS

Zakim IRC Bot: -JanneS ←

14:58:44 <SteveH> LeeF: rationale: feature: makes it hard to read, wouldn't change anything because of categories

Lee Feigenbaum: rationale: feature: makes it hard to read, wouldn't change anything because of categories ←

14:59:01 <ericP> +!

Eric Prud'hommeaux: +! ←

14:59:03 <ericP> +1

Eric Prud'hommeaux: +1 ←

14:59:03 <bijan> MediaWiki is good that way

Bijan Parsia: MediaWiki is good that way ←

14:59:06 <SteveH> ivanh: just minor, places where I've seen references to feature:, but will forward

Ivan Herman: just minor, places where I've seen references to feature:, but will forward ←

14:59:15 <ericP> +ℑ

Eric Prud'hommeaux: +ℑ ←

14:59:21 <kjetil> +1 only if there is redirect, -1 if not

Kjetil Kjernsmo: +1 only if there is redirect, -1 if not ←

14:59:22 <SteveH> AndyS: I like them all coming up together

Andy Seaborne: I like them all coming up together ←

15:00:19 <SteveH> LeeF: inclined to say I don't really care

Lee Feigenbaum: inclined to say I don't really care ←

15:00:35 <SteveH> LeeF: bijan, if you want to do it go ahead

Lee Feigenbaum: bijan, if you want to do it go ahead ←

<LeeF> topic: next week and beyond

15:01:19 <SteveH> LeeF: next week will look at non-other boxes stuff, eg. XML syntax for queries, RDF synatx for SPARQL, semantics of SPARQL/OWL queries. may also look at other features

Lee Feigenbaum: next week will look at non-other boxes stuff, eg. XML syntax for queries, RDF synatx for SPARQL, semantics of SPARQL/OWL queries. may also look at other features ←

15:01:50 <SteveH> LeeF: aroudn end of next telecon, want survey for a couple of weeks to get formal positions on pioritising features

Lee Feigenbaum: aroudn end of next telecon, want survey for a couple of weeks to get formal positions on pioritising features ←

15:01:57 <SteveH> q+

q+ ←

15:02:11 <kjetil> ack SteveH

Kjetil Kjernsmo: ack SteveH ←

15:02:39 <kjetil> condorcet voting

Kjetil Kjernsmo: condorcet voting ←

15:02:52 <SteveH> LeeF: outcome would be a small set of 3-4 things that we will do, plus a prioritised set of things we might do time permitting

Lee Feigenbaum: outcome would be a small set of 3-4 things that we will do, plus a prioritised set of things we might do time permitting ←

15:03:05 <bijan> zakim, mute me

Bijan Parsia: zakim, mute me ←

15:03:05 <Zakim> bijan was already muted, bijan

Zakim IRC Bot: bijan was already muted, bijan ←

15:03:50 <SteveH> AndyS: does that lead to the idea that you do the 3 or 4 things, then move on the other set, things in initial set, if they're orthogonal and there's enough energy then it's better to put them in the required set

Andy Seaborne: does that lead to the idea that you do the 3 or 4 things, then move on the other set, things in initial set, if they're orthogonal and there's enough energy then it's better to put them in the required set ←

15:03:57 <SteveH> AndyS: telecon is a contraint

Andy Seaborne: telecon is a contraint ←

15:04:16 <bijan> Task forces!

Bijan Parsia: Task forces! ←

15:04:31 <SteveH> LeeF: say we did XML SPARQL serialisation, somewhat orthogonal, if the groups interested were seperate in a some way then they could have seperate telecon

Lee Feigenbaum: say we did XML SPARQL serialisation, somewhat orthogonal, if the groups interested were seperate in a some way then they could have seperate telecon ←

15:04:46 <ivanh> q+

Ivan Herman: q+ ←

15:04:54 <SteveH> LeeF: task force of 1-3 people not always best

Lee Feigenbaum: task force of 1-3 people not always best ←

15:04:55 <LeeF> ack ivanh

Lee Feigenbaum: ack ivanh ←

15:05:03 <AndyS> Bijan, can work but in our short timescale we have to come back together again.

Andy Seaborne: Bijan, can work but in our short timescale we have to come back together again. ←

15:05:11 <ericP> q+ to suggest that the queue should be closed

Eric Prud'hommeaux: q+ to suggest that the queue should be closed ←

15:05:12 <bijan> AndyS: for sure

Andy Seaborne: for sure [ Scribe Assist by Bijan Parsia ] ←

15:05:22 <LeeF> s/AndyS:/AndyS,

Lee Feigenbaum: s/AndyS:/AndyS, ←

15:05:34 <SteveH> ivanh: the problem I have is that, yes it works up to a certain point, but at some point all the results have to properly synchronised (in various ways), that is a major drawback somewhere down the line, we hould be careful

Ivan Herman: the problem I have is that, yes it works up to a certain point, but at some point all the results have to properly synchronised (in various ways), that is a major drawback somewhere down the line, we hould be careful ←

15:05:38 <SteveH> q+

q+ ←

15:05:38 <bijan> I was being somewhat ironic

Bijan Parsia: I was being somewhat ironic ←

15:05:52 <SteveH> LeeF: we've clearly indentifed some important features

Lee Feigenbaum: we've clearly indentifed some important features ←

15:06:18 <LeeF> SteveH: concern about task forces having decisions and then re-having those decisions with the main group

Steve Harris: concern about task forces having decisions and then re-having those decisions with the main group [ Scribe Assist by Lee Feigenbaum ] ←

15:06:24 <ericP> SteveH: concearned that TFs will have a discussion within the TF and have to have it again in the greater WG

Steve Harris: concearned that TFs will have a discussion within the TF and have to have it again in the greater WG [ Scribe Assist by Eric Prud'hommeaux ] ←

15:06:55 <SteveH> LeeF: agreed, but I think we can get around it by documenting discussions, and not opening debate, and people can show up at task forces, aware and a little concerned but I think we can deal with it

Lee Feigenbaum: agreed, but I think we can get around it by documenting discussions, and not opening debate, and people can show up at task forces, aware and a little concerned but I think we can deal with it ←

15:07:09 <Zakim> -ivanh

Zakim IRC Bot: -ivanh ←

15:07:17 <Zakim> -DaveNewman

Zakim IRC Bot: -DaveNewman ←

15:07:17 <ericP> RRSAgent, please draft minutes

Eric Prud'hommeaux: RRSAgent, please draft minutes ←

15:07:17 <RRSAgent> I have made the request to generate http://www.w3.org/2009/03/31-sparql-minutes.html ericP

RRSAgent IRC Bot: I have made the request to generate http://www.w3.org/2009/03/31-sparql-minutes.html ericP ←

15:07:20 <Zakim> -john-l

Zakim IRC Bot: -john-l ←

15:07:22 <Zakim> -Chimezie_Ogbuji

Zakim IRC Bot: -Chimezie_Ogbuji ←

15:07:25 <Zakim> -Orri

Zakim IRC Bot: -Orri ←

15:07:27 <Zakim> -Lee_Feigenbaum

Zakim IRC Bot: -Lee_Feigenbaum ←

15:07:30 <Zakim> -kasei

Zakim IRC Bot: -kasei ←

15:07:30 <LeeF> adjourned.

Lee Feigenbaum: adjourned. ←

Formatted by CommonScribe Show Interleaved IRC Text

---

This revision (#1) generated 2009-03-31 21:54:29 UTC by 'lfeigenb', comments: 'cleaned up minutes. Thanks to Steve for scribing.'