SPARQL Working Group Minutes, 06 May 2009

Zakim IRC Bot: On IRC I see LeeF, AndyS, bijan, RRSAgent, Kjetil_, Zakim, AlexPassant, SimonS, SteveH, LukeWM, AxelPolleres, ivanh, john-l, KjetilK, trackbot, iv_an_ru, kjetil, ericP ←

Lee Feigenbaum: goal, fix what we're gonna dfo the next 2 months and the next 15month [ Scribe Assist by Axel Polleres ] ←

... been looking at the don't want column, noting that Clark and Parsia seem to use it as others used don't mind ←

Steve Harris: produced another graph which ranks don't-want below don't-mind ←

Steve Harris: we used don't-want to indicate things that we thought would impede the standards process ←

Steve Harris: yeah, though we didn't agree before hand so it's open to interpretation ←

Lee Feigenbaum: service discription is not a magic bullet, it does give impls a way to supply features which didn't make the cut ←

... i called it a required feature, not because i wanted it, but because it seemed very strange to have aggregate projections but not scalar projections ←

... also, project appeared to have more consensus than the alternative assignment ←

Eric Prud'hommeaux: full-text seems like it *could* have IPR so not worth including in charter if we're not likely to get to it ←

AndyS, i don't know of any IPR, just that it seems marginally more dangerous than other spaces ←

Lee Feigenbaum: added OWL 'cause i want SPARQL WG to tbe the first to use the extension mechanism ←

Lee Feigenbaum: it's important that we don't go off and work on our pet features and expect a rubber stamp ←

Ivan Mikhailov: I'm afraid that we should say something about full text, at least as non-normative section that points to some full text query spec. ←

Axel Polleres: "don't want"s in the top-12 plus SurfaceSyntax: Update 1 (Clark&Parsia), ←

Axel Polleres: FunctionLibrary 1 (Clark&Parsia), ProjectExpression 1 (Clark&Parsia), ←

Axel Polleres: Assignment 1 (Garlik), SPARQL/OWL 1 (OpenLink), SurfaceSyntax 1 (Clark&Parsia) ←

... i put SPARQL-OWL at the top of might-get-to list as i feel it will have energy ←

... property paths and basic fed query is likely to be the same players as other features ←

Greg Williams: i should say that i (rpi) used "don't want" more as a "rank below everything else", not as a "I have big problems with this" ... ←

... if we need an intuitve expression, would they still want another syntax? ←

Andy Seaborne: note that FILTERs do not have the expected scope so don't behave as folks expect ←

Steve Harris: difference between empty result or empty binding set needs to be considered... example pending [ Scribe Assist by Axel Polleres ] ←

Steve Harris: share AndyS's concearn that FILTER negation may not behave as expected ←

Zakim IRC Bot: kasei, you wanted to mention a fourth facet of service descriptions ←

Greg Williams: also supported extension functions & supported language extensions [ Scribe Assist by Lee Feigenbaum ] ←

Ivan Mikhailov: IMHO service descriptions consists of optional properties only, so there's no technical need to sub-divide. ←

Luke Wilson-Mawer: do we decide what you can put in the service description? i.e. schema? ←

Andy Seaborne: I disagree with the "99%" comment. Finding the graph matters. ←

Lee Feigenbaum: is anyone's vote on service description conditional on any of these sub-features? ←

Ivan Mikhailov: AxelPolleres, we promote fn:, xsd: and some other namespaces anyway :) ←

Lee Feigenbaum: q+ ericP to ask if anyone is opposed to standardizing the mechanism mainly/only & examples ←

Ivan Mikhailov: One should be able to read authoritative service description, but w/o any obligations. ←

Ivan Herman: i don't disagree with AndyS and SteveH, but we should flush out features we enable ←

Ivan Mikhailov: I can't agree with dataset descriptions with queries, this will ban "select all' queries. ←

Zakim IRC Bot: ericP, you wanted to ask if anyone is opposed to standardizing the mechanism mainly/only and to ask if anyone is opposed to standardizing the mechanism mainly/only & examples ←

Eric Prud'hommeaux: the impression I have is that if we provide the mechanism (e.g. DESCRIBE or something with endpoint URI) and some examples - we may flesh out some bits of a schema, but we don't want to decide on that /commit to that while deciding our feature set [ Scribe Assist by Lee Feigenbaum ] ←

Kjetil Kjernsmo: LARC and Virtuoso provide very useful fulltext features, interoperability is low though and main cost of migration [ Scribe Assist by Axel Polleres ] ←

Steve Harris: what proportion of the users are in your [expressivity] camp vs. those who need stemming and scoring ←

Axel Polleres: simon, can you put yourself on the q and explain your use case? ←

Andy Seaborne: Agree - minimum is truncate results on score but returning score is nice ←

Bijan Parsia: I'm confused as to why specing entailment regimes makes it more expensive to deploy SPARQL in general. ←

Ivan Mikhailov: AndyS, returning score is unavoidable, at least to find out the threshold value to use for truncating. ←

Andy Seaborne: Alternative is to pass the score trunctae point into matching. ←

Ivan Mikhailov: ericP, we don't have to make the full-text mandatory part of every implementation, we just should specify that when implemented it should support some set of functions and some fixed syntax. ←

Kjetil Kjernsmo: every web site had a search box. need to be able to apt-get install and run ←

Andy Seaborne: implementing Lucene may be more work than implementing SPARQL ←

Axel Polleres: iv_an_ru? kjetil asks whether you have something on your fulltext solution? ←

Ivan Mikhailov: Others will probably implement a cheaper free-text, because our FT provides special indexing of tags of XML documents in order to accelerate XPath queries. ←

Lee Feigenbaum: who has something they would boot off the list in favor of full-text ←

Axel Polleres: " doesn't look terribly compatible with triple patterns, does it? ←

Ivan Mikhailov: AxelPollers, score etc should not be in triple patterns syntax, because options (score etc) can be numerous. ←

Ivan Mikhailov: ?o <contains> "text pattern" --- for simple cases, a FILTER with function call for complications. ←

Greg Williams: I probably wouldn't implement it due to cost and lack of need, but would be happy for it to be an optional part of the language [ Scribe Assist by Lee Feigenbaum ] ←

Eric Prud'hommeaux: w3c tries to make coherent set of technologies, might shoehorn us into xpath full text expression [ Scribe Assist by Lee Feigenbaum ] ←

Ivan Mikhailov: No doubt, FT should stay outside mandadory part of the language. ←

Axel Polleres: would custom functions in FILTERs and ORDER BY work? Is a new syntax really needed? ←

Eric Prud'hommeaux: we've never had to specify how something is implemented, but we would be expected to write down what the functionality is [ Scribe Assist by Lee Feigenbaum ] ←

Paul Gearon: If we do spec a syntax (which I don't mind) then this is why I'm +1 on service descriptions, so we can advertise whether or not this feature is available ←

Kjetil Kjernsmo: if both systems meet our expressivity needs we can live with changing the surface syntax ←

Paul Gearon: SteveH, I see your argument, but DESCRIBE already set this precedent ←

Andy Seaborne: Property functions imply an exuection model we don't have so I pref explciit syntax for full text search ←

Steve Harris: what user set is content with conjunctive word lists vs. stemming and ranking? ←

... web sites care about stemming and ranking, which would be ugly as magic predicates ←

Steve Harris: wonders if were talking about implied ordering or ?x :fulltext [ result: ?res ; :rank ?rank ] ←

Andy Seaborne: predicate functions (graph patterns) can bite you as they require an undocumented order of execution ←

Andy Seaborne: example by orri for why fulltext is order dependent... we have to be cautious about that [ Scribe Assist by Axel Polleres ] ←

Bijan Parsia: Here's my response to the "around the room": It seems that there is a community for which full text is must have, another community which doesn't need it at all (most of the stuff I work on and the people I work with have little text in the datasets), and maybe some who could take it or leave it. (<---so very unprofound!) So, optional. I would be surprised if I'd implement it in either the RDF or the OWL systems I work on right now. ←

Birte Glimm: we would implement SPARQL + OWL, and full-text would be low on the weekend list ←

Bijan Parsia: Also, I have no expertise in this, so can't really help with the specification. ←

Bijan Parsia: (I don't even know what the different "levels" could be, i.e., what a "lite" version of the feature would be.) ←

Ivan Mikhailov: I've muted myself 'cause the connection is prohibitively noisy. ←

Axel Polleres: no objection, but if it affects execution order, i.e. doesn't fit into pred functionsd, it's a bit worrying me. [ Scribe Assist by Axel Polleres ] ←

Andy Seaborne: I don't see why we are forced to use XQ/FT -- is it even mappable? ←

Eric Prud'hommeaux: easiest way to handle it would be to handle to ask implementers to use existing XPath functions [ Scribe Assist by Axel Polleres ] ←

Bijan Parsia: My *prima facie* reaction is to wonder why we wouldn't use XPath full text ←

Axel Polleres: ... Xquery WG will ask us why we don't reuse their mechanism. ←

Andy Seaborne: I guess our user community would put it just the other way around. [ Scribe Assist by Axel Polleres ] ←

Ivan Mikhailov: It's cheaper to extend XQ/FT with "RDF literal" type than to re-invent the whole bicycle. ←

Bijan Parsia: SteveH, Oh, I totally believe that. I'm just saying that it's a choice that needs explanation. That can go easy or that can go hard... :) ←

Axel Polleres: Can someone point to an example where the execution order "kicks in"? ←

... magpreds in full-text arena imply execution ordering and update of the result set to be ordered ←

Ivan Mikhailov: Can someone point to an example where the execution order "kicks in"? --- ?text <contains> ?text-pattern ;) ←

Kjetil Kjernsmo: how evil is a magic predicate compared to a filter function? ←

Ivan Mikhailov: IMHO, what's important is to keep "really" magic predicates (with side effects like new bindings) apart from plain "syntax sugar" for filtering functions. ←

Ivan Mikhailov: Whatever requires the order, should be written as a subselect with ORDER BY. ←

Andy Seaborne: They can be done right but there is scope for diviating from the declarative property paradigm ←

Steve Harris: I have another issue with predicate functions, but I'll leave that ←

Paul Gearon: We deliberately expressed as much as we can with triples.... which brought us to predicate functions ←

Andy Seaborne: Axel, I am not proposing that - it assumes too much of the system. ←

Ivan Mikhailov: Whether we need "magic" or not is question of taste, but the "magic" of the service must be 100% documented by service description. ←

Ivan Herman: with negation and property paths, we can properly express lists? ←

Lee Feigenbaum: yes in the common case where you have a link the head of a list ←

Eric Prud'hommeaux: if we use property paths we will be writing off some use cases that involve preventing people from injecting new items in closed lists [ Scribe Assist by Lee Feigenbaum ] ←

Eric Prud'hommeaux: not sure how many use cases we're giving up if we don't have a mechanism to ensure a coherent list [ Scribe Assist by Lee Feigenbaum ] ←

Axel Polleres: q+ to ask whether we talk about PropertyPaths or AccessingLists here ←

Ivan Herman: the missing list access in SPARQL has a deleterious affect on SPARQL ←

Ivan Mikhailov: OTOH we don't have convenient features for selecting all items of a numbered list (?s ?p ?o filter (?p is of sort rdf:_N )) or for finding a position of ?o in a list ?s (i.e. to extract N from rdf:_N). ←

... i feel that lists in RDF are bad, so i don't mind their use being discouraged ←

Zakim IRC Bot: AxelPolleres, you wanted to ask whether we talk about PropertyPaths or AccessingLists here ←

Paul Gearon: I don't like lists, but they're used in OWL (eg. owl:intersectionOf) so they can't be avoided ←

Lee Feigenbaum: Clark & Parsia stated a preference for assignment because ProjectExpressions may be too complex for their use cases (not sure what those use cases look like) ←

Steve Harris: should not be an expressivity difference, but as SPARQL similar to SQL, do it similarly. ←

Andy Seaborne: Roughly: { pattern1 assign pattern 2 } is equiv to { { SELECT assign { pattern1 } pattern 2 } ←

Eric Prud'hommeaux: sees extra select as noise, would like more crisp syntax using let. ←

Steve Harris: will happen in subqueries anyway and will be needed to project out, so directly do it in projection. ←

Eric Prud'hommeaux: but if you do not have subquery, you will need additional subquery. ←

Eric Prud'hommeaux: how many people do want to push their constraints down to the binding of the variable? ←

Steve Harris: Prefer having subqueries, LET would be abbreviation only, maybe not often used. ←

Andy Seaborne: various forms of assignments. Logical vs. relational algebra. Semantics are compatible. ←

Lee Feigenbaum: is LET { <var> := <expr> } (theoretically) identical to { SELECT <expr> AS <var> }? ←

Zakim IRC Bot: LeeF, you wanted to note that assignment is not always more terse ←

Zakim IRC Bot: On the phone I see Bristol, ivanh (muted), MIT262, bijan, iv_an_ru ←

Andy Seaborne: { pattern1 LET (?x := ?a+?b) pattern 2 } is equiv to { { SELECT (?a+?b AS ?x) { pattern1 } pattern 2 } - need to have patten1 under select. ←

Kendall Clark: (oh, man, what a joy pastebin is in this context; no more crappy code pastes into IRC) ←

Lee Feigenbaum: Is there anybody who wants assignment, but not project expressions? [ Scribe Assist by Axel Polleres ] ←

Kjetil Kjernsmo: Zakim, Bristol has SimonS, SteveH, KjetilK, LukeWM, AndyS, AxelPolleres, AlexPassant, bglimm ←

Andy Seaborne: example easier to use Assignment, if we assign something, then do something with it. ←

Ivan Mikhailov: Maybe "LET ?x is a shorthand for ?a+?b" ... do something with ?x ←

Ivan Mikhailov: No circular assignments in any case, so no ordering headache. ←

Axel Polleres: ordering issues with assignment would be nesting issues with projectExpressions/subqueries. ←

Steve Harris: thinks this is exactly the kind of misunderstandings he means. ←

Axel Polleres: In the case of subselect you have the same problem with nesting ←

Kendall Clark: But we won't object to project expressions (though I find them much harder to read FWIW) ←

Axel Polleres: aggregate proposal means allow selects as expressions, but not require project expressions. ←

Lee Feigenbaum: Think we need ProjectExpressions, would not object to Assignment in addition ←

Steve Harris: agrees, but wants to stay close to relational algebra. Take good bits of SQL, but not bad ones. ←

Lee Feigenbaum: SPARQL looks like SQL. When I teach SPARQL to new people, they have a strong expectation that it has other SQL-like capabilities - so there is an education cost to things that diverge from that ←

Kendall Clark: -1 on emulating SQL; -10 for reasons of pedagogic utility (sorry, LeeF) ←

Ivan Herman: +1 to kendall; sparql is not sql, and we should not take the relationships between the two too far ←

Kendall Clark: competing with SQL, in any sense, is a game we will always lose IMO -- "they" have a massive lead in just about every sense ←

Ivan Mikhailov: SimonS, make sense to be identical to SQL or noticeable distinct, but not similar --- "Stroustrup's law". ←

Steve Harris: usually one starts with simpler logical units of a query to compose a more complicated one. Easy and natural. ←

Kendall Clark: for my $$, we already are "enough like SQL" that we ought to play some distinguishing moves for this phase of SPARQL evolution; which is one non-self-interested reason to push stuff like svc descriptions, inference regimes, etc. ←

Axel Polleres: back to ProjectExpressions. Seem to be strongly wanted, no objections. Can do assignment, if time allows. ←

Lee Feigenbaum: What I hear is: Steve feels strongly about not incluing assignment. Kendall feels strongly about having assignment ←

Kendall Clark: we might object if project expressions don't subsume assignment semantically ←

Kendall Clark: so, LeeF, if someone would write an email showing that PEs subsume assignment, I'd be happy to let "LET" go :) ←

Eric Prud'hommeaux: q+ to say that the Health Care and Life Sciences WG uses them a lot ←

Kendall Clark: and we'll keep using them in Pellet-Jena, so it's not a big deal ←

Simon Schenk: separate marking part of query to be evaluated at one EP from choosing the EP. ←

Kendall Clark: (FWIW, I want LET because I think the queries are more explicitly clear with them than w/out them) ←

Andy Seaborne: coming back to kendall: do things that are not in SQL but are useful. e.g. simple federated query is just to get the connectivity going. ←

ACTION: SteveH to write up how/whether assignment is subsumed by projected expressions + subqueries (tentative, with LukeWM) ←

Trackbot IRC Bot: Created ACTION-13 - Write up how/whether assignment is subsumed by projected expressions + subqueries (tentative, with LukeWM) [on Steve Harris - due 2009-05-13]. ←

Paul Gearon: FROM doesn't specify that URLs should be dereferenced. But I note that most implementations go and do just this ←

Steve Harris: want to make sure SPARQL does not sound dangerous per se to security people. ←

...if it is in core, then it should be switched off by default. or have separate language SPARQL+Federation. ←

Paul Gearon: Security is going to be much more important when we look at how this interacts with Updates ←

Zakim IRC Bot: ericP, you wanted to say that the Health Care and Life Sciences WG uses them a lot ←

Axel Polleres: sounds to me that this is an issue, but doesn't impete working on the feature ←

ISSUE: How to specify BasicFederatedQuery in a way that acknowledges optional nature of feature & security issues ←

Trackbot IRC Bot: Created ISSUE-1 - How to specify BasicFederatedQuery in a way that acknowledges optional nature of feature & security issues ; please complete additional details at http://www.w3.org/2009/sparql/track/issues/1/edit . ←

Ivan Mikhailov: I've implemented graph-level security recently and found it relatively cheap, so I don't worry too much. ←

Axel Polleres: sounds like some of the candidate core features for service descriptions then? ←

Kendall Clark: I think federation should be non-standardized and an area of vendor "competitive advantage"...It's super use-case specific in our experience, to boot ←

Ivan Mikhailov: competitive implenetaitons of non-standardized fedaration is Bad Thing. ←

Kjetil Kjernsmo: Without LimitByResource, working on multiple datasources becomes more difficult. ←

Axel Polleres: limit is always "distinct", yes? (otherwise doesn't make sense, does it?) ←

Kendall Clark: in fact, competitive implementations of non-standard federation can be a good thing if it clarifies the market such that standardization can happy in a subsequent phase; premature standardization can do the opposite: cloud & foreclose the market, etc ←

Kjetil Kjernsmo: You only care e.g. about distinct subjects. For example only have 10 resources plus their descriptions ←

Ivan Mikhailov: kendall, _cooperative_ implementations of non-standard federation can be a good thing. Like AndyS and I kept SPARUL syntax in sync even if started it independently. ←

Kendall Clark: that's only true if the market really wants one thing, and the cooperating parties are workin on that one thing ←

Ivan Mikhailov: We've seen enough "browser wars", don't want "sparql web-service endpoint wars" even if I win. ←

Lee Feigenbaum: SteveH, you're probably right, but Bob MacGregor made a habit of trying to find such cases and didn't yet succeed (on sparql-dev and dawg-comments) ←

Steve Harris: ?x a :A UNSAID { ?x a :B } is at least hard, though not impossible ←

Luke Wilson-Mawer: There is difference between adding surface syntax for old and new features. For old ones there are lots of use cases. ←

Andy Seaborne: Try writing intersection using cross product and negation. It can be done (apparantly). But it is very hard to get right. ←

Lee Feigenbaum: SteveH, AndyS, I agree re: very hard, that's not what i was saying :) ←

Kjetil Kjernsmo: If time allows and subselects + aggregates are done, maybe come back? ←

... regarding IN: possibly gives list access if specified right, if right hand side is a list. ←

Greg Williams: i would support "IN range", but generally not any of the other 3 surface syntaxes ←

Andy Seaborne: feature is surface syntax. Not comfortable with putting it under SurfaceSyntax. Discussion too open. ←

Kjetil Kjernsmo: q+ to ask whether we have agreed on the definition of surface syntax? ←

Steve Harris: commas in select alone do not help, also need it in limit etc. ←

Andy Seaborne: If the goal to prove the extension point, makes sense to me to look at a simpler one (first). SPARQL/OWL has value in itself - not a proof point. ←

Bijan Parsia: q+ to say my main goal is force commonality on existing implementations ←

Lee Feigenbaum: that will be a lesson to saying something negative about SPARQL/OWL ←

Ivan Mikhailov: We've added optional commas to select list syntax because SQL people wrote them. ←

Ivan Mikhailov: It's still LALR1 because commas are either optional delimiters of the list or nested in (...) ←

Kjetil Kjernsmo: Have OWL users, have some simple inferences, which take forever ←

Axel Polleres: purpose is being able to specify what it means to support OWL. ←

Ivan Mikhailov: Moreover, it may be convenient to "invert" the informal description of the grammar and say that commas are not required as soon as select list stays unambiguous. ←

Bijan Parsia: Kjetil, it's not clear to me that the inferences are "simple". ←

Birte Glimm: There needs to be some way of telling users that results will not only be subgraph matching. Have users how need that. ←

Axel Polleres: q+ to speak about why we need more refined notions of entailment even. ←

Ivan Mikhailov: +1, the best advantage of SPARQL is the very fact of being implemented. ←

Ivan Mikhailov: Implementation of something is more convenient than spec of everything. ←

Lee Feigenbaum: iv_an_ru, +30 to that (i think lessons from SPARQL v1 prove that out nicely) ←

Axel Polleres: support having OWL entailment regime, but DERI wants something more fine grained. ←

...sometimes one just does not want to have full OWL on the Web, as it results in nonsense results. ←

Andy Seaborne: The point is being able to layer algebra on top of OWL inferencing. ←

Zakim IRC Bot: AxelPolleres, you wanted to comment on IN and to speak about why we need more refined notions of entailment even. ←

Zakim IRC Bot: bijan, you wanted to say my main goal is force commonality on existing implementations ←

... need to take care of inconsistencies in the dataset for such entailment regime. ←

... main objective is make OWL query engines use SPARQL and become interoperable ←

Ivan Herman: OWL is not only huge DL reasoning with hundrets of classes. There are smaller profiles and smaller features useful on their own ←

ACTION: bijan to send mail about issues in BGP matching that must be considered when specifying OWL in SPARQL semantics ←

Trackbot IRC Bot: Created ACTION-14 - Send mail about issues in BGP matching that must be considered when specifying OWL in SPARQL semantics [on Bijan Parsia - due 2009-05-13]. ←

Axel Polleres: Define Entailment regime for OWL, subregimes for OWL EL and the like time permits? ←

Bijan Parsia: Issues should be the same for all, also for RIF. Describe abstractly. ←

Eric Prud'hommeaux: include relationship of OWL to RDF? e.g. using graph API with DL ←

Axel Polleres: q+ to ask (chair-hat-off) about SPARQL/RIF in/out of scope here, if we find volunteers? ←

Ivan Herman: for the records - we need to allow to clearly define the capabilities of an endpoint. Needs service descriptions. ←

Zakim IRC Bot: AxelPolleres, you wanted to ask (chair-hat-off) about SPARQL/RIF in/out of scope here, if we find volunteers? ←

Axel Polleres: also extend to RIF? Seems closey related. Would that be in the scope of SPARQL/entailment, time allowed? ←

Eric Prud'hommeaux: from a fashion perspective, we have a chance to develop more styles if we go madly off in all directions at once ←

Andy Seaborne: service descriptions do not cover multiple regimes in a single query. ←

Bijan Parsia: I think its' pretty clear that having multiple *is* useful. I think it's useful at least :) ←

Chime Ogbuji: i.e., specific entailment regimes for specific parts of the active graph ←

Bijan Parsia: Then it's just querying the *whole* graph under different semantics and combining the results under the algebra ←

Andy Seaborne: One way - different graphs with different entailment in one datasets. (There may be other ways - just an example - but this is no syntax way) ←

... reg. Axel's question: OWL is clearly described in RDF, hence also in SPARQL. For RIF, this does not hold. Hence, need additional syntax or protocol. ←

Chime Ogbuji: I interpreted that differently (i.e., I thought they were talking about parts of teh graph rather than parts of the query) ←

Zakim IRC Bot: AndyS, you wanted to note UC for multiple entailment in one query ←

Axel Polleres: in above link, semantics of RIF+RDF is specified, includes entailed RDF triples ←

Chime Ogbuji: My impression is (as Bijan suggested) many of the issues that will need to be addressed on the path towards an OWL-DL entailment regime, will be re-usable for other regimes (including RIF+RDF). As long as we aren't explicitely ruling out the possiblity of investigating taking that further step once the details for SPARQL-DL are worked out ←

Axel Polleres: Want do define what it means to evaluate a SPARQL query together with some RIF rules. Would not want to exclude it. ←

Zakim IRC Bot: KjetilK, you wanted to ask about ProjectExpression as required ←

Lee Feigenbaum: chimezie, sorry, did not notice that you joined on the phone! ←

16:35:55 <LeeF> http://www.w3.org/2009/sparql/wiki/FeatureProposal

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

16:36:59 <kasei> LeeF: regarding "in order" of time-permitting features, might extend timeline for required features, not for time-permitting

Lee Feigenbaum: regarding "in order" of time-permitting features, might extend timeline for required features, not for time-permitting ←

16:37:34 <kasei> ... assuming get through required features, need to decide which time-permitting features

... assuming get through required features, need to decide which time-permitting features ←

16:38:27 <kasei> ... overlap of work for some features, not others (bgp entailment). makes sense to do some work in parallel.

... overlap of work for some features, not others (bgp entailment). makes sense to do some work in parallel. ←

16:39:08 <SteveH> +1

Steve Harris: +1 ←

16:39:10 <AxelPolleres> +1

Axel Polleres: +1 ←

16:39:10 <KjetilK> +1

Kjetil Kjernsmo: +1 ←

16:39:19 <kasei> ... inclinded to remove ordering, in charter note time permitting features, and punt on choosing until it comes up later

... inclinded to remove ordering, in charter note time permitting features, and punt on choosing until it comes up later ←

16:39:20 <AlexPassant> +1, fair enough

Alex Passant: +1, fair enough ←

16:39:25 <SimonS>  +1

Simon Schenk: +1 ←

16:40:11 <kasei> AndyS: may be contention of WG when coming together with features toward the end

Andy Seaborne: may be contention of WG when coming together with features toward the end ←

16:41:51 <kasei> LeeF: should be default that things are rec track, but should be aware lots of ancillary work, chance we'll have to make some things WG notes

Lee Feigenbaum: should be default that things are rec track, but should be aware lots of ancillary work, chance we'll have to make some things WG notes ←

16:42:09 <AxelPolleres> q+

Axel Polleres: q+ ←

16:42:14 <LeeF> ack AxelPolleres

Lee Feigenbaum: ack AxelPolleres ←

16:42:56 <kasei> AxelPolleres: would it make sense to mention a point in time to decide rec track features?

Axel Polleres: would it make sense to mention a point in time to decide rec track features? ←

16:43:46 <kasei> ... not sure has to be in charter

... not sure has to be in charter ←

16:43:54 <bglimm> q+

Birte Glimm: q+ ←

16:44:10 <LeeF> ack bglimm

Lee Feigenbaum: ack bglimm ←

16:44:13 <kasei> LeeF: don't want entailment work to come back to WG to get response "sorry, that'll be WG note"

Lee Feigenbaum: don't want entailment work to come back to WG to get response "sorry, that'll be WG note" ←

16:45:26 <kasei> bglimm: people interested in entialment regimes won't contribute much to the other query language features

Birte Glimm: people interested in entialment regimes won't contribute much to the other query language features ←

16:45:55 <kendall> There's an obvious denial of service strategy from a disinterested majority against the "time-permitting" work items that's bothersome

Kendall Clark: There's an obvious denial of service strategy from a disinterested majority against the "time-permitting" work items that's bothersome ←

16:46:15 <kasei> LeeF: don't want to sacrifice required features for time-permitting ones, but don't want required features to be unnecessary obstacles to the time-permittings.

Lee Feigenbaum: don't want to sacrifice required features for time-permitting ones, but don't want required features to be unnecessary obstacles to the time-permittings. ←

16:47:04 <kasei> ... open issues on required features shouldn't prevent discussion of time-permitting features

... open issues on required features shouldn't prevent discussion of time-permitting features ←

16:47:18 <bglimm> q+

Birte Glimm: q+ ←

16:47:53 <ericP> +1 to deathmarch

Eric Prud'hommeaux: +1 to deathmarch ←

16:47:59 <SteveH> -1 to deathmarch

Steve Harris: -1 to deathmarch ←

16:48:10 <LeeF> ack bglimm

Lee Feigenbaum: ack bglimm ←

16:49:05 <kasei> bglimm: if people working on required parts can't spend time on coordination of time-permitting features, unlikely to work in the end...

Birte Glimm: if people working on required parts can't spend time on coordination of time-permitting features, unlikely to work in the end... ←

16:50:00 <kasei> ... is it worth working on these features if unlikely to have time to review at the end

... is it worth working on these features if unlikely to have time to review at the end ←

16:50:21 <kendall> fwiw, I don't think it's entirely true that inference people, say, won't work on required features, since implementations count as working on them.

Kendall Clark: fwiw, I don't think it's entirely true that inference people, say, won't work on required features, since implementations count as working on them. ←

16:50:45 <LeeF> kendall, I think that bglimm is mainly speaking for herself

Lee Feigenbaum: kendall, I think that bglimm is mainly speaking for herself ←

16:51:38 <kasei> SteveH: tends to be contentious issues that take up most time

Steve Harris: tends to be contentious issues that take up most time ←

16:51:39 <kendall> as am I

Kendall Clark: as am I ←

16:52:07 <kasei> LeeF: don't mean to imply that people won't have time to review time-permitting features

Lee Feigenbaum: don't mean to imply that people won't have time to review time-permitting features ←

16:52:13 <bglimm> I am mainly speaking for myself

Birte Glimm: I am mainly speaking for myself ←

16:52:26 <kasei> ... is acknowledgement that it's a worthwhile effort

... is acknowledgement that it's a worthwhile effort ←

16:52:47 <SteveH> +1 if I wasn't willing to read it, I wouldn't support it being a feature

Steve Harris: +1 if I wasn't willing to read it, I wouldn't support it being a feature ←

16:53:00 <LeeF> q?

Lee Feigenbaum: q? ←

16:53:01 <kasei> LeeF: also, other source of feedback. imagine that there will be non-trivial feedback re: entialment from outside the WG

Lee Feigenbaum: also, other source of feedback. imagine that there will be non-trivial feedback re: entialment from outside the WG ←

16:53:22 <kendall> steveh, thanks for saying that :)

Kendall Clark: steveh, thanks for saying that :) ←

16:55:17 <kasei> LeeF: asked everyone to look at current feature proposal to see if we're near consensus

Lee Feigenbaum: asked everyone to look at current feature proposal to see if we're near consensus ←

16:55:44 <KjetilK> q+

Kjetil Kjernsmo: q+ ←

16:55:48 <kasei> AndyS: from pov of writing the charter, wondering if its as clear as we can make it

Andy Seaborne: from pov of writing the charter, wondering if its as clear as we can make it ←

16:56:03 <kasei> ... established that there is quite a bit of connection between some features

... established that there is quite a bit of connection between some features ←

16:56:31 <kasei> ... (subqueries, aggregation, proj. exprs.)

... (subqueries, aggregation, proj. exprs.) ←

16:58:28 <kasei> LeeF: won't hash out charter text, but will need to be explicit abotu what will be in charter

Lee Feigenbaum: won't hash out charter text, but will need to be explicit abotu what will be in charter ←

16:59:44 <kasei> ... relatively happy with current list

... relatively happy with current list ←

17:01:05 <kasei> pgearon: happy, but note we haven't discussed update yet.

Paul Gearon: happy, but note we haven't discussed update yet. ←

17:01:12 <AndyS> +1 -- update is underdiscussed

Andy Seaborne: +1 -- update is underdiscussed ←

17:02:05 <kasei> SteveH: ambitious, but can't think of anything to remove

Steve Harris: ambitious, but can't think of anything to remove ←

17:02:45 <kasei> AndyS: ambitious, but don't think it will push out all time-permitting features. also notes lack of update discussion.

Andy Seaborne: ambitious, but don't think it will push out all time-permitting features. also notes lack of update discussion. ←

17:03:18 <kasei> ... re: BasicFederatedQuery, would spend time working on it

... re: BasicFederatedQuery, would spend time working on it ←

17:04:16 <kasei> KjetilK: too bad full text didn't reach consensus (would like a vote as a time-permitting feature)

Kjetil Kjernsmo: too bad full text didn't reach consensus (would like a vote as a time-permitting feature) ←

17:04:17 <KjetilK> Specify a simple, optional freetext query syntax and semantics.

Kjetil Kjernsmo: Specify a simple, optional freetext query syntax and semantics. ←

17:04:18 <kendall> update being underdiscussed, particularly w/r/t security implications, worries me

Kendall Clark: update being underdiscussed, particularly w/r/t security implications, worries me ←

17:04:29 <SteveH> +1 to kendall

Steve Harris: +1 to kendall ←

17:04:42 <KjetilK> +1

Kjetil Kjernsmo: +1 ←

17:04:44 <kasei> LeeF: poll on (possibly simple) full text feature

Lee Feigenbaum: poll on (possibly simple) full text feature ←

17:04:45 <pgearon> +1

Paul Gearon: +1 ←

17:04:48 <AlexPassant> 0

Alex Passant: 0 ←

17:04:49 <LukeWM> 0

Luke Wilson-Mawer: 0 ←

17:04:50 <kasei> 0

0 ←

17:04:52 <SimonS> +1

Simon Schenk: +1 ←

17:04:53 <AxelPolleres> 0

Axel Polleres: 0 ←

17:04:53 <SteveH> -1 too complex

Steve Harris: -1 too complex ←

17:04:53 <bglimm> 0

Birte Glimm: 0 ←

17:04:58 <john-l> +1

John Clark: +1 ←

17:04:58 <ericP> -1

Eric Prud'hommeaux: -1 ←

17:05:01 <kendall> -1

Kendall Clark: -1 ←

17:05:07 <AndyS> +1 only as far as syntax,  -1 for spec results or text QL

Andy Seaborne: +1 only as far as syntax, -1 for spec results or text QL ←

17:05:18 <SteveH> kendall, day 2 has a slot on update, FWIW, but I share your concerns

Steve Harris: kendall, day 2 has a slot on update, FWIW, but I share your concerns ←

17:05:49 <LeeF> 0

Lee Feigenbaum: 0 ←

17:06:17 <kendall> can't shake the thought of sparql injection attacks (and hard to see how we can implement, over http, the standard defense)

Kendall Clark: can't shake the thought of sparql injection attacks (and hard to see how we can implement, over http, the standard defense) ←

17:06:22 <kasei> ... based on previous criteria, doesn't seem to be enough consensus.

... based on previous criteria, doesn't seem to be enough consensus. ←

17:06:57 <AndyS> kendall, agreed - one reson I prefer 2 languages, not one mega language of QL+U

Andy Seaborne: kendall, agreed - one reson I prefer 2 languages, not one mega language of QL+U ←

17:07:12 <pgearon> kendall, I share you concerns. OTOH, the most consistent complaint I hear about SPARQL is the lack of Update

Paul Gearon: kendall, I share you concerns. OTOH, the most consistent complaint I hear about SPARQL is the lack of Update ←

17:07:13 <kasei> KjetilK: lack of consensus is clear. don't need to spend more time on it.

Kjetil Kjernsmo: lack of consensus is clear. don't need to spend more time on it. ←

17:07:32 <kendall> but it doesn't have to be in the language

Kendall Clark: but it doesn't have to be in the language ←

17:07:37 <kendall> it could be in the protocol

Kendall Clark: it could be in the protocol ←

17:07:46 <kendall> or, as andy says, in something entirely separate

Kendall Clark: or, as andy says, in something entirely separate ←

17:07:57 <kendall> (those may be isomorphic, in which case i don't care which)

Kendall Clark: (those may be isomorphic, in which case i don't care which) ←

17:08:36 <kasei> ... possible to have something about DefaultDescribeResults in a note?

... possible to have something about DefaultDescribeResults in a note? ←

17:09:09 <AndyS> q+

Andy Seaborne: q+ ←

17:09:15 <kasei> LeeF: would be willing to consider it, but don't want to publish a note that hasn't had enough WG review.

Lee Feigenbaum: would be willing to consider it, but don't want to publish a note that hasn't had enough WG review. ←

17:09:45 <kasei> AndyS: member submission would be a good route

Andy Seaborne: member submission would be a good route ←

17:09:50 <AndyS> ack me

Andy Seaborne: ack me ←

17:09:58 <LeeF> ack KjetilK

Lee Feigenbaum: ack KjetilK ←

17:09:58 <KjetilK> ack me

Kjetil Kjernsmo: ack me ←

17:10:42 <kasei> AlexP: ok with required. for time-permittion, priority would be entailment extensions.

Alex Passant: ok with required. for time-permittion, priority would be entailment extensions. ←

17:11:17 <kasei> SimonS: ambitious, but ok. if only time to do one time-permittion, want federated query.

Simon Schenk: ambitious, but ok. if only time to do one time-permittion, want federated query. ←

17:11:41 <kendall> KjetilK: as long as we're all a little bit unhappy in roughly the same measure, then that's how we know we're making standards! :>

Kjetil Kjernsmo: as long as we're all a little bit unhappy in roughly the same measure, then that's how we know we're making standards! :> [ Scribe Assist by Kendall Clark ] ←

17:12:09 <kasei> bglimm: fine with the list. priority features is entailment.

Birte Glimm: fine with the list. priority features is entailment. ←

17:12:28 <KjetilK> q+ to ask if we are in the same situation with FunctionLibrary as SurfaceSyntax with regards to IPR

Kjetil Kjernsmo: q+ to ask if we are in the same situation with FunctionLibrary as SurfaceSyntax with regards to IPR ←

17:12:53 <kasei> AxelPolleres: didn't talk much about function library. should we spend more time discussing?

Axel Polleres: didn't talk much about function library. should we spend more time discussing? ←

17:13:37 <kasei> AndyS: nervous about things like restricting to xpath functions.

Andy Seaborne: nervous about things like restricting to xpath functions. ←

17:14:13 <kasei> AxelPolleres: should we scope to looking into only certain functions?

Axel Polleres: should we scope to looking into only certain functions? ←

17:14:23 <kasei> AndyS: no

Andy Seaborne: no ←

17:14:37 <LeeF> "Common functions dealing with core SPARQL types including IRIs, literals, numbers, and strings" ?

Lee Feigenbaum: "Common functions dealing with core SPARQL types including IRIs, literals, numbers, and strings" ? ←

17:15:17 <kasei> Kjetil: if we leave it unscoped, would that be problematic for the charter?

Kjetil Kjernsmo: if we leave it unscoped, would that be problematic for the charter? ←

17:15:46 <AndyS> q+

Andy Seaborne: q+ ←

17:15:52 <LeeF> ack KjetilK

Lee Feigenbaum: ack KjetilK ←

17:15:52 <Zakim> KjetilK, you wanted to ask if we are in the same situation with FunctionLibrary as SurfaceSyntax with regards to IPR

Zakim IRC Bot: KjetilK, you wanted to ask if we are in the same situation with FunctionLibrary as SurfaceSyntax with regards to IPR ←

17:16:03 <kasei> ericP: would make it challenging for IP issues.

Eric Prud'hommeaux: would make it challenging for IP issues. ←

17:16:40 <AxelPolleres> XPath + RIF DTB (has iri-string conversion which can be used for iri construction)

Axel Polleres: XPath + RIF DTB (has iri-string conversion which can be used for iri construction) ←

17:17:26 <kasei> ... motivation to make it easy for new groups to join the WG.

... motivation to make it easy for new groups to join the WG. ←

17:17:57 <AxelPolleres> ISSUE: scope of functions to be clarified further for the charter

ISSUE: scope of functions to be clarified further for the charter ←

17:17:58 <trackbot> Created ISSUE-2 - Scope of functions to be clarified further for the charter ; please complete additional details at http://www.w3.org/2009/sparql/track/issues/2/edit .

Trackbot IRC Bot: Created ISSUE-2 - Scope of functions to be clarified further for the charter ; please complete additional details at http://www.w3.org/2009/sparql/track/issues/2/edit . ←

17:18:47 <AxelPolleres> s/functions/function library/

Axel Polleres: s/functions/function library/ ←

17:18:48 <kasei> LeeF: punt on IP issues until writing charter

Lee Feigenbaum: punt on IP issues until writing charter ←

17:19:16 <LeeF> chimezie, are you around?

Lee Feigenbaum: chimezie, are you around? ←

17:19:20 <LeeF> john-l, are you around?

Lee Feigenbaum: john-l, are you around? ←

17:19:31 <chimezie> I'm here, on IRC at least

Chime Ogbuji: I'm here, on IRC at least ←

17:19:57 <LeeF> chimezie, are you happy (enough) with the proposal for WG features as it currently exists at http://www.w3.org/2009/sparql/wiki/FeatureProposal ?

Lee Feigenbaum: chimezie, are you happy (enough) with the proposal for WG features as it currently exists at http://www.w3.org/2009/sparql/wiki/FeatureProposal ? ←

17:20:57 <LeeF> PROPOSED: To accept the set of required and time-permitting features as specified in http://www.w3.org/2009/sparql/wiki/index.php?title=FeatureProposal&oldid=744 and pending completion of the action listed therein

PROPOSED: To accept the set of required and time-permitting features as specified in http://www.w3.org/2009/sparql/wiki/index.php?title=FeatureProposal&oldid=744 and pending completion of the action listed therein ←

17:21:13 <chimezie> It doesn't include BNode reference (which is important for us), but time-constraints , etc..

Chime Ogbuji: It doesn't include BNode reference (which is important for us), but time-constraints , etc.. ←

17:21:26 <SteveH> seconded

Steve Harris: seconded ←

17:21:31 <AxelPolleres> +1

Axel Polleres: +1 ←

17:21:33 <chimezie> So, yes, looks good  :)

Chime Ogbuji: So, yes, looks good :) ←

17:21:33 <ericP> +1

Eric Prud'hommeaux: +1 ←

17:21:37 <KjetilK> threeonded

Kjetil Kjernsmo: threeonded ←

17:21:37 <LeeF> thanks, chimezie

Lee Feigenbaum: thanks, chimezie ←

17:22:05 <bglimm> Leef, you could call OWL Flavors, OWL Profiles since this is what they are called in the OWL standard

Birte Glimm: Leef, you could call OWL Flavors, OWL Profiles since this is what they are called in the OWL standard ←

17:22:05 <bijan> +1 (before going home)

Bijan Parsia: +1 (before going home) ←

17:22:13 <pgearon> +1

Paul Gearon: +1 ←

17:22:52 <bglimm> +1

Birte Glimm: +1 ←

17:23:03 <kasei> LeeF: does anyone abstain or object to propsal?

Lee Feigenbaum: does anyone abstain or object to propsal? ←

17:23:05 <AndyS> +1

Andy Seaborne: +1 ←

17:23:09 <SimonS> +1

Simon Schenk: +1 ←

17:23:10 <LeeF> RESOLVED: To accept the set of required and time-permitting features as specified in http://www.w3.org/2009/sparql/wiki/index.php?title=FeatureProposal&oldid=744 and pending completion of the action listed therein

RESOLVED: To accept the set of required and time-permitting features as specified in http://www.w3.org/2009/sparql/wiki/index.php?title=FeatureProposal&oldid=744 and pending completion of the action listed therein ←

17:23:15 <LeeF> No abstentions or objections

Lee Feigenbaum: No abstentions or objections ←

<LeeF> topic: Features & Rationale document

3. Features & Rationale document

Summary: Aim for first draft of http://www.w3.org/2009/sparql/docs/features/ at end of first week of June

<LeeF> summary: Aim for first draft of http://www.w3.org/2009/sparql/docs/features/ at end of first week of June

17:24:05 <kasei> LeeF: want to give time to KjetilK and Alex re: rationale document

Lee Feigenbaum: want to give time to KjetilK and Alex re: rationale document ←

17:24:30 <AlexPassant> Features doc currently at: http://www.w3.org/2009/sparql/docs/features/

Alex Passant: Features doc currently at: http://www.w3.org/2009/sparql/docs/features/ ←

17:24:58 <kasei> KjetilK: start puting down description of features on wiki

Kjetil Kjernsmo: start puting down description of features on wiki ←

17:25:28 <kasei> ... will use wiki for collab. environment. at some point will freeze page and put into a more formal document.

... will use wiki for collab. environment. at some point will freeze page and put into a more formal document. ←

17:26:05 <AndyS> q+

Andy Seaborne: q+ ←

17:26:17 <kasei> AlexP: for each feature: motivation, description, proposed syntax, discussion

Alex Passant: for each feature: motivation, description, proposed syntax, discussion ←

17:26:42 <kasei> Steve: we aren't chartered to discuss syntax (?)

Steve Harris: we aren't chartered to discuss syntax (?) ←

17:27:06 <kasei> LeeF: intention is to do a more involved document later on. question  is whether to discuss any syntax now.

Lee Feigenbaum: intention is to do a more involved document later on. question is whether to discuss any syntax now. ←

17:27:32 <kasei> KjetilK: examples are important. useful, but maybe should be "examples" not "proposed syntax"

Kjetil Kjernsmo: examples are important. useful, but maybe should be "examples" not "proposed syntax" ←

17:27:40 <LeeF> +1 to Andy - examples only based on existing implementations is a good idea

Lee Feigenbaum: +1 to Andy - examples only based on existing implementations is a good idea ←

17:27:50 <kasei> AndyS: must be existing implementations, not just "examples".

Andy Seaborne: must be existing implementations, not just "examples". ←

17:28:12 <LeeF> ack AndyS

Lee Feigenbaum: ack AndyS ←

17:28:48 <kasei> ... would help to ask for particular things needed for the document. lots of existing wiki content.

... would help to ask for particular things needed for the document. lots of existing wiki content. ←

17:30:02 <kasei> KjetilK: descriptions might belong before motivations.

Kjetil Kjernsmo: descriptions might belong before motivations. ←

17:31:00 <kasei> LeeF: next issue - naming.

Lee Feigenbaum: next issue - naming. ←

17:31:29 <SimonS> SPARQL 2010

Simon Schenk: SPARQL 2010 ←

17:31:30 <kasei> ... "2.0" and "1.1". are there others?

... "2.0" and "1.1". are there others? ←

17:31:54 <kasei> ... update may have another name, but what name for the core language?

... update may have another name, but what name for the core language? ←

17:32:09 <SteveH> also federated might have a different name...

Steve Harris: also federated might have a different name... ←

17:32:55 <AxelPolleres> Axel: getting back to F+R Schedule

Axel Polleres: getting back to F+R Schedule [ Scribe Assist by Axel Polleres ] ←

17:33:04 <kasei> ... would be great to have something in 4 weeks.

... would be great to have something in 4 weeks. ←

17:33:11 <AxelPolleres> LeeF: reasonable within 4 weeks?

Lee Feigenbaum: reasonable within 4 weeks? [ Scribe Assist by Axel Polleres ] ←

17:33:31 <AxelPolleres> Kjetil&Alex agree.

Axel Polleres: Kjetil&Alex agree. ←

17:33:45 <AlexPassant> +1 first week of june

Alex Passant: +1 first week of june ←

17:34:11 <kasei> KjetilK: have one day a week. telecon + editing document.

Kjetil Kjernsmo: have one day a week. telecon + editing document. ←

17:34:40 <kasei> Alex: 1 day a week.

Alex Passant: 1 day a week. ←

17:35:39 <kasei> LeeF: first draft doesn't need to be huge. touch on everything, but can then hear from the WG and from outside.

Lee Feigenbaum: first draft doesn't need to be huge. touch on everything, but can then hear from the WG and from outside. ←

17:36:32 <kasei> AxelPolleres: don't have to write it all yourselves. ask for content, can discuss on telecon.

Axel Polleres: don't have to write it all yourselves. ask for content, can discuss on telecon. ←

<LeeF> topic: Naming and Modularity

4. Naming and Modularity

Summary: RESOLVED: The whole megillah is called SPARQL, with pieces called SPARQL/Query and SPARQL/Update and possibly others and RESOLVED: (open world) The version of SPARQL worked on by this working group includes SPARQL/Query 1.1 and SPARQL/Update 1.0

<LeeF> summary: RESOLVED: The whole megillah is called SPARQL, with pieces called SPARQL/Query and SPARQL/Update and possibly others and RESOLVED: (open world) The version of SPARQL worked on by this working group includes SPARQL/Query 1.1 and SPARQL/Update 1.0

17:36:52 <kasei> LeeF: back to naming. what do people prefer?

Lee Feigenbaum: back to naming. what do people prefer? ←

17:37:02 <kasei> ericP: don't care

Eric Prud'hommeaux: don't care ←

17:37:09 <AxelPolleres> Axel: "feature champions" should be asked for help to put concrete text, where necessary, editor doesn't imply Alex and Kjetil write all by themselves. Use the wiki!

Axel Polleres: "feature champions" should be asked for help to put concrete text, where necessary, editor doesn't imply Alex and Kjetil write all by themselves. Use the wiki! [ Scribe Assist by Axel Polleres ] ←

17:37:27 <kasei> pgearon: if update is in it, 2.0, otherwise 1.1.

Paul Gearon: if update is in it, 2.0, otherwise 1.1. ←

17:37:38 <kasei> kasei: 1.1, not strong preference.

Greg Williams: 1.1, not strong preference. ←

17:37:38 <AlexPassant> +1 for pgearon

Alex Passant: +1 for pgearon ←

17:38:06 <kasei> ericP: wondering about pgearon's opinion

Eric Prud'hommeaux: wondering about pgearon's opinion ←

17:38:19 <kasei> pgearon: update is a big feature. 2.0 signifies this.

Paul Gearon: update is a big feature. 2.0 signifies this. ←

17:38:27 <kasei> LeeF: 2.0

Lee Feigenbaum: 2.0 ←

17:38:41 <kasei> LukeWM: don't care

Luke Wilson-Mawer: don't care ←

17:39:06 <kasei> SteveH: feel strongly 1.1, update should be a different language (so should federated query)

Steve Harris: feel strongly 1.1, update should be a different language (so should federated query) ←

17:39:24 <kendall> steveh: what marketing point do you want to make with "1.1" name?

Steve Harris: what marketing point do you want to make with "1.1" name? [ Scribe Assist by Kendall Clark ] ←

17:39:31 <kasei> AndyS: agrees with SteveH. had strong input about calling things 2.0 (based on OWL) -- bad idea.

Andy Seaborne: agrees with SteveH. had strong input about calling things 2.0 (based on OWL) -- bad idea. ←

17:39:33 <kendall> (sorry i can't dial-in, feel free to ignore me!)

Kendall Clark: (sorry i can't dial-in, feel free to ignore me!) ←

17:40:09 <kasei> ... keep query language 1.1, wouldn't expect compliance to involve implementing update.

... keep query language 1.1, wouldn't expect compliance to involve implementing update. ←

17:40:19 <kendall> AndyS: calling sparql anything based on OWL is dumb -- +1

Andy Seaborne: calling sparql anything based on OWL is dumb -- +1 [ Scribe Assist by Kendall Clark ] ←

17:40:21 <kasei> KjetilK: 1.1. update as seperate. SPARQL/OWL seperate.

Kjetil Kjernsmo: 1.1. update as seperate. SPARQL/OWL seperate. ←

17:40:50 <kasei> AlexP: 2.0 with update, otherwise 1.1.

Alex Passant: 2.0 with update, otherwise 1.1. ←

17:41:21 <kasei> SimonS: keep update seperate. meant "2010". even if many followup WGs, no problem.

Simon Schenk: keep update seperate. meant "2010". even if many followup WGs, no problem. ←

17:41:53 <kasei> bglimm: no strong opinion. probably 1.1 with update/federated separate. (2.0 if all in one.)

Birte Glimm: no strong opinion. probably 1.1 with update/federated separate. (2.0 if all in one.) ←

17:42:22 <SteveH> q+

Steve Harris: q+ ←

17:42:31 <LeeF> ack SteveH

Lee Feigenbaum: ack SteveH ←

17:42:43 <kasei> AxelPolleres: 1.1 is good, would not keep federation separate, but update separate.

Axel Polleres: 1.1 is good, would not keep federation separate, but update separate. ←

17:43:14 <kasei> SteveH: update should be separate. SQL got this wrong.

Steve Harris: update should be separate. SQL got this wrong. ←

17:43:30 <kasei> LeeF: seems to be consensus on that. does anyone think otherwise?

Lee Feigenbaum: seems to be consensus on that. does anyone think otherwise? ←

17:43:50 <kendall> fwiw, i think "1.1" is a dumb name

Kendall Clark: fwiw, i think "1.1" is a dumb name ←

17:43:57 <john-l> Leef, you prefer 2.0?

John Clark: Leef, you prefer 2.0? ←

17:44:03 <LeeF> vastly

Lee Feigenbaum: vastly ←

17:44:04 <AxelPolleres> Axel: SPARQL 2010 and keeping all in one would be along the lines of SQL 99. I personally like SPARQL1.1 and SPARQL/Update separate.

Axel Polleres: SPARQL 2010 and keeping all in one would be along the lines of SQL 99. I personally like SPARQL1.1 and SPARQL/Update separate. [ Scribe Assist by Axel Polleres ] ←

17:44:15 <LeeF> i'm happy with 2010 also fwiw :)

Lee Feigenbaum: i'm happy with 2010 also fwiw :) ←

17:44:17 <LeeF> q+ yimin

Lee Feigenbaum: q+ yimin ←

17:44:20 <kasei> ericP: worries about what keeping update separate looks like.

Eric Prud'hommeaux: worries about what keeping update separate looks like. ←

17:44:26 <john-l> I prefer 2010.

John Clark: I prefer 2010. ←

17:44:47 <kendall> SPARQL 2010: The Sadistic Satyr

Kendall Clark: SPARQL 2010: The Sadistic Satyr ←

17:44:54 <kasei> ... issues with keeping grammar together or separate.

... issues with keeping grammar together or separate. ←

17:45:32 <kasei> ... trying to work out mechanics of what is meant by "separate language". one doc for query with section for update?

... trying to work out mechanics of what is meant by "separate language". one doc for query with section for update? ←

17:45:37 <AndyS> Much laughter over  "The Speedy Squirrel"

Andy Seaborne: Much laughter over "The Speedy Squirrel" ←

17:45:47 <kasei> ... second document with only additions to grammar?

... second document with only additions to grammar? ←

17:46:26 <kasei> ... care about distinction between sparql and update with protocol and also branding on products.

... care about distinction between sparql and update with protocol and also branding on products. ←

17:47:10 <kasei> SteveH: imagining two langs would share grammar. core sparql would error if you tried to use update.

Steve Harris: imagining two langs would share grammar. core sparql would error if you tried to use update. ←

17:48:05 <AndyS> q+

Andy Seaborne: q+ ←

17:48:12 <kasei> pgearon: was also expecting update to be a strict superset. insert-select, delete-select use the select we've already got.

Paul Gearon: was also expecting update to be a strict superset. insert-select, delete-select use the select we've already got. ←

17:48:44 <AndyS> ack me

Andy Seaborne: ack me ←

17:48:46 <LeeF> ack yimin

Lee Feigenbaum: ack yimin ←

17:49:15 <kasei> yimin:  expereince with users having trouble with many different varieties of OWL (DL, ...). trouble differentiating.

Yimin Wang: expereince with users having trouble with many different varieties of OWL (DL, ...). trouble differentiating. ←

17:49:54 <kasei> ... consideration for ease of users. would like to have update in the same language.

... consideration for ease of users. would like to have update in the same language. ←

17:50:02 <kendall> (what users are these? i don't recognize 'yimin')

Kendall Clark: (what users are these? i don't recognize 'yimin') ←

17:50:20 <kendall> AH

Kendall Clark: AH ←

17:50:22 <pgearon> +q

Paul Gearon: +q ←

17:50:22 <kendall> thanks, LeeF

Kendall Clark: thanks, LeeF ←

17:50:30 <kasei> ericP: SQL has sublanguages, but users don't think of them.

Eric Prud'hommeaux: SQL has sublanguages, but users don't think of them. ←

17:50:39 <LeeF> ack pgearon

Lee Feigenbaum: ack pgearon ←

17:50:41 <kendall> I think that's a pretty awfula analogy

Kendall Clark: I think that's a pretty awfula analogy ←

17:50:56 <ericP> thank you

Eric Prud'hommeaux: thank you ←

17:51:23 <kasei> pgearon: if we didn't split the language into parts, select can't go through the http protocol with http GET.

Paul Gearon: if we didn't split the language into parts, select can't go through the http protocol with http GET. ←

17:51:35 <AndyS> I like "SPARQL" as the overall name and SPARQL/(sub-part)

Andy Seaborne: I like "SPARQL" as the overall name and SPARQL/(sub-part) ←

17:51:51 <kasei> ... delete-select through "PUT"? would be nice through "DELETE", but tricky to resolve proper http methods.

... delete-select through "PUT"? would be nice through "DELETE", but tricky to resolve proper http methods. ←

17:52:10 <kendall> (i'm always amazed people deploy real systems where "users" are expected to write SPARQL by hand. This is cruel and unusual punishment!)

Kendall Clark: (i'm always amazed people deploy real systems where "users" are expected to write SPARQL by hand. This is cruel and unusual punishment!) ←

17:53:15 <AxelPolleres> (kendall, people write a lot of SQL, don't they?)

Axel Polleres: (kendall, people write a lot of SQL, don't they?) ←

17:53:19 <kasei> ... can't put insert, delete through GET. need alignment with protocol. update touches on many things, frustrating that it's last on the schedule.

... can't put insert, delete through GET. need alignment with protocol. update touches on many things, frustrating that it's last on the schedule. ←

17:53:56 <kendall> Axel: no, they don't

Axel Polleres: no, they don't [ Scribe Assist by Kendall Clark ] ←

17:54:04 <kendall> programmers don't even write that much SQL these days

Kendall Clark: programmers don't even write that much SQL these days ←

17:54:33 <SteveH> I like Andy's proposal

Steve Harris: I like Andy's proposal ←

17:54:41 <kasei> AxelPolleres: no particular preference.

Axel Polleres: no particular preference. ←

17:55:13 <AndyS> (was not my proposal - I just liked it)

Andy Seaborne: (was not my proposal - I just liked it) ←

17:55:21 <kasei> SteveH: branding "SPARQL/Query", "SPARQL/Update", ...

Steve Harris: branding "SPARQL/Query", "SPARQL/Update", ... ←

17:55:29 <kendall> +1

Kendall Clark: +1 ←

17:55:32 <kasei> LeeF: do we need a specific name for the work this WG is doing?

Lee Feigenbaum: do we need a specific name for the work this WG is doing? ←

17:55:51 <AxelPolleres> SteveH: SPARQL = SPARQL/Query SPARQL/Update

Steve Harris: SPARQL = SPARQL/Query SPARQL/Update [ Scribe Assist by Axel Polleres ] ←

17:56:33 <AndyS> http://www.w3.org/SPARQL/1.1

Andy Seaborne: http://www.w3.org/SPARQL/1.1 ←

17:56:45 <LeeF> PROPOSED: The whole megillah is called SPARQL, with pieces called SPARQL/Query and SPARQL/Update and possibly others

PROPOSED: The whole megillah is called SPARQL, with pieces called SPARQL/Query and SPARQL/Update and possibly others ←

17:56:49 <SteveH> http://www.w3.org/SPARQL/Query/1.1 surely

Steve Harris: http://www.w3.org/SPARQL/Query/1.1 surely ←

17:56:58 <KjetilK> SPARQL 1.1 = SPARQL/Query 1.1  SPARQL/Update 1.0 etc

Kjetil Kjernsmo: SPARQL 1.1 = SPARQL/Query 1.1 SPARQL/Update 1.0 etc ←

17:57:08 <ericP> +1 to megillah (SP?) proposal

Eric Prud'hommeaux: +1 to megillah (SP?) proposal ←

17:57:12 <kendall> SPARQL/Inference (We can hope!!)

Kendall Clark: SPARQL/Inference (We can hope!!) ←

17:57:57 <SteveH> isn't this WG a megillah?

Steve Harris: isn't this WG a megillah? ←

17:57:58 <AxelPolleres> rdf-sparql-query11/ , rdf-sparql-update/ rdf-sparql-entailments/, rdf-sparql-protocol11/

Axel Polleres: rdf-sparql-query11/ , rdf-sparql-update/ rdf-sparql-entailments/, rdf-sparql-protocol11/ ←

17:58:07 <AndyS> .g seems to agree on spelling

Andy Seaborne: .g seems to agree on spelling ←

17:58:15 <SteveH> federated also

Steve Harris: federated also ←

17:58:20 <KjetilK> +1

Kjetil Kjernsmo: +1 ←

17:58:20 <AndyS> +1

Andy Seaborne: +1 ←

17:58:23 <LeeF> RESOLVED: The whole megillah is called SPARQL, with pieces called SPARQL/Query and SPARQL/Update and possibly others

RESOLVED: The whole megillah is called SPARQL, with pieces called SPARQL/Query and SPARQL/Update and possibly others ←

17:58:29 <SteveH> +1, as long as federated is seperate

Steve Harris: +1, as long as federated is seperate ←

17:58:40 <AxelPolleres> +1

Axel Polleres: +1 ←

17:58:55 <bglimm> +1

Birte Glimm: +1 ←

17:59:10 <kasei> ericP: tempted not to number overall SPARQL.

Eric Prud'hommeaux: tempted not to number overall SPARQL. ←

17:59:11 <AndyS> Are we using Apache Ivy to import all the docs?

Andy Seaborne: Are we using Apache Ivy to import all the docs? ←

17:59:21 <kendall> +[1.1,2.0]

Kendall Clark: +[1.1,2.0] ←

17:59:26 <kendall> hah

Kendall Clark: hah ←

17:59:32 <kasei> LeeF: no number for everything, numbered components (update, query)

Lee Feigenbaum: no number for everything, numbered components (update, query) ←

17:59:46 <LeeF> PROPOSED: The version of SPARQL query lanaguage worked on by this working group is called SPARQL/Query 1.1

PROPOSED: The version of SPARQL query lanaguage worked on by this working group is called SPARQL/Query 1.1 ←

18:00:00 <ericP> i second

Eric Prud'hommeaux: i second ←

18:00:02 <AndyS> +i

Andy Seaborne: +i ←

18:00:05 <KjetilK> +1

Kjetil Kjernsmo: +1 ←

18:00:10 <kendall> why the 1.1 bit?

Kendall Clark: why the 1.1 bit? ←

18:00:10 <pgearon> +1

Paul Gearon: +1 ←

18:00:26 <LeeF> PROPOSED: The version of SPARQL query lanaguage worked on by this working group are called SPARQL/Query 1.1 and SPARQL/Update 1.0

PROPOSED: The version of SPARQL query lanaguage worked on by this working group are called SPARQL/Query 1.1 and SPARQL/Update 1.0 ←

18:00:30 <kendall> previous version "SPARQL", this version "SPARQL/Query"

Kendall Clark: previous version "SPARQL", this version "SPARQL/Query" ←

18:00:34 <ericP> i second

Eric Prud'hommeaux: i second ←

18:00:35 <SteveH> what about federated

Steve Harris: what about federated ←

18:01:25 <LeeF> PROPOSED: The version of SPARQL worked on by this working group includes SPARQL/Query 1.1 and SPARQL/Update 1.0

PROPOSED: The version of SPARQL worked on by this working group includes SPARQL/Query 1.1 and SPARQL/Update 1.0 ←

18:01:33 <ericP> i object

Eric Prud'hommeaux: i object ←

18:02:59 <kasei> ericP: regarding "safety" of implementation. safety means datastore isn't updated. doesn't execute remote queries.

Eric Prud'hommeaux: regarding "safety" of implementation. safety means datastore isn't updated. doesn't execute remote queries. ←

18:03:37 <kasei> SteveH: importantly, doesn't make any GET requests. current standard doesn't force you to GET on a FROM<...>.

Steve Harris: importantly, doesn't make any GET requests. current standard doesn't force you to GET on a FROM<...>. ←

18:03:56 <kasei> ... no network requests from the endpoint.

... no network requests from the endpoint. ←

18:03:59 <AndyS> q+

Andy Seaborne: q+ ←

18:04:26 <kasei> ... concern is around admins installing software and not having to worry about the server making requests.

... concern is around admins installing software and not having to worry about the server making requests. ←

18:04:59 <kasei> ericP: wouldn't that mean addressing FROM?

Eric Prud'hommeaux: wouldn't that mean addressing FROM? ←

18:05:23 <kasei> SteveH: ideally, yes. but there are many stores that don't GET on a FROM.

Steve Harris: ideally, yes. but there are many stores that don't GET on a FROM. ←

18:06:10 <LeeF> ack AndyS

Lee Feigenbaum: ack AndyS ←

18:06:10 <kasei> ... want to implemented federated sparql, but also want to have a public endpoint that doesn't do that.

... want to implemented federated sparql, but also want to have a public endpoint that doesn't do that. ←

18:06:25 <kasei> AndyS: difference between what is in the spec and what compliance with the spec is.

Andy Seaborne: difference between what is in the spec and what compliance with the spec is. ←

18:06:40 <kasei> ... "if you implement feature X, this is what occurs"

... "if you implement feature X, this is what occurs" ←

18:07:55 <kasei> ericP: so you are seeking alignment between the branding name and the security policies?

Eric Prud'hommeaux: so you are seeking alignment between the branding name and the security policies? ←

18:08:36 <KjetilK> +q to say that we need a version number for the megillah to distinguish it from the previous version?

Kjetil Kjernsmo: +q to say that we need a version number for the megillah to distinguish it from the previous version? ←

18:08:48 <kasei> SteveH: bet there are plenty of people who deploy SPARQL servers without realizing the implications

Steve Harris: bet there are plenty of people who deploy SPARQL servers without realizing the implications ←

18:09:51 <AndyS> How about writing specific text in the future docs that says "This set of featurs is safe" +details

Andy Seaborne: How about writing specific text in the future docs that says "This set of featurs is safe" +details ←

18:09:52 <kasei> ericP: if we have an identifier for a "safe" version of SPARQL, should address "FROM" at the same time.

Eric Prud'hommeaux: if we have an identifier for a "safe" version of SPARQL, should address "FROM" at the same time. ←

18:10:45 <kasei> ... should safety be deeper than the branding name, with saddle and configuration options?

... should safety be deeper than the branding name, with saddle and configuration options? ←

18:11:35 <kasei> ... if we identify network safe operations, people can implement/use the safe version.

... if we identify network safe operations, people can implement/use the safe version. ←

18:11:51 <SimonS> +1 to AndyS' proposal of marking safe features

Simon Schenk: +1 to AndyS' proposal of marking safe features ←

18:12:10 <kasei> SteveH: that you have to explicitly ban those features is a security problem.

Steve Harris: that you have to explicitly ban those features is a security problem. ←

18:13:03 <kasei> ericP: suggest SteveH lobby for text that deals with safe operations, a "SPARQL/Safe" name.

Eric Prud'hommeaux: suggest SteveH lobby for text that deals with safe operations, a "SPARQL/Safe" name. ←

18:13:32 <LeeF> SPARQL/DangerDangerDanger

Lee Feigenbaum: SPARQL/DangerDangerDanger ←

18:13:58 <AxelPolleres> would it make sense to define an "endpoint set" similar to "dataset"? would that help?

Axel Polleres: would it make sense to define an "endpoint set" similar to "dataset"? would that help? ←

18:13:59 <kasei> ... what you want requires such detail that we can't address it now.

... what you want requires such detail that we can't address it now. ←

18:14:06 <KjetilK> +1 to not rule it out

Kjetil Kjernsmo: +1 to not rule it out ←

18:14:14 <LeeF> q?

Lee Feigenbaum: q? ←

18:14:27 <LeeF> PROPOSED: (open world) The version of SPARQL worked on by this working group includes SPARQL/Query 1.1 and SPARQL/Update 1.0

PROPOSED: (open world) The version of SPARQL worked on by this working group includes SPARQL/Query 1.1 and SPARQL/Update 1.0 ←

18:14:50 <AxelPolleres> ... and systems have freedom how to treat that as they are free to fix the dataset.

Axel Polleres: ... and systems have freedom how to treat that as they are free to fix the dataset. ←

18:15:22 <AndyS>  Suggest: This WG acknowledges that there are security issues in federated query and the WG will continue to be careful about this.

Andy Seaborne: Suggest: This WG acknowledges that there are security issues in federated query and the WG will continue to be careful about this. ←

18:15:41 <KjetilK> +1

Kjetil Kjernsmo: +1 ←

18:15:49 <kasei> LeeF: any abstentions or objections?

Lee Feigenbaum: any abstentions or objections? ←

18:15:49 <pgearon> +1

Paul Gearon: +1 ←

18:15:52 <AxelPolleres> +1

Axel Polleres: +1 ←

18:15:52 <LeeF> RESOLVED: (open world) The version of SPARQL worked on by this working group includes SPARQL/Query 1.1 and SPARQL/Update 1.0

RESOLVED: (open world) The version of SPARQL worked on by this working group includes SPARQL/Query 1.1 and SPARQL/Update 1.0 ←

18:16:02 <SteveH> can we have an issue along the lines of what AndyS wrote

Steve Harris: can we have an issue along the lines of what AndyS wrote ←

18:16:03 <KjetilK> ack me

Kjetil Kjernsmo: ack me ←

18:16:03 <Zakim> KjetilK, you wanted to say that we need a version number for the megillah to distinguish it from the previous version?

Zakim IRC Bot: KjetilK, you wanted to say that we need a version number for the megillah to distinguish it from the previous version? ←

18:16:06 <bglimm> +1

Birte Glimm: +1 ←

18:16:52 <kasei> KjetilK: what should title of features document be?

Kjetil Kjernsmo: what should title of features document be? ←

18:17:34 <kasei> ... "yeah, I'm happy"

... "yeah, I'm happy" ←

18:18:45 <ericP> topic: response to rdf:text

5. response to rdf:text

Summary: RESOLVED: Send the text on http://www.w3.org/2009/sparql/wiki/index.php?title=Rdf_text_LC_WG_comment&oldid=758 as SPARQL WG feedback to OWL WG and RIF WG regarding rdf:text Last call

<LeeF> summary: RESOLVED: Send the text on http://www.w3.org/2009/sparql/wiki/index.php?title=Rdf_text_LC_WG_comment&oldid=758 as SPARQL WG feedback to OWL WG and RIF WG regarding rdf:text Last call

18:18:30 <kasei> LeeF: next up, response to rdf:text

Lee Feigenbaum: next up, response to rdf:text ←

18:18:41 <kasei> ... tomorrow dive into features

... tomorrow dive into features ←

18:19:09 <AxelPolleres> http://www.w3.org/2009/sparql/wiki/rdf_text_LC_WG_comment

Axel Polleres: http://www.w3.org/2009/sparql/wiki/rdf_text_LC_WG_comment ←

18:19:30 <AxelPolleres> http://www.w3.org/TR/rdf-text/

Axel Polleres: http://www.w3.org/TR/rdf-text/ ←

18:19:37 <kasei> AxelPolleres: current response, based on comments by AndyS.

Axel Polleres: current response, based on comments by AndyS. ←

18:19:48 <kasei> ... interop problems with SPARQL.

... interop problems with SPARQL. ←

18:20:45 <kasei> ... rdf:text a datatype for plain/lang literals useful for OWL/RIF.

... rdf:text a datatype for plain/lang literals useful for OWL/RIF. ←

18:21:12 <kasei> ... with current defintion, too strong regarding semantic equivalence literals

... with current defintion, too strong regarding semantic equivalence literals ←

18:22:10 <kasei> ... document proposes rdf graph serializations do not use rdf:text. AndyS observed also affects SPARQL.

... document proposes rdf graph serializations do not use rdf:text. AndyS observed also affects SPARQL. ←

18:22:34 <kasei> ... str/datatype/lang functions would also be affected

... str/datatype/lang functions would also be affected ←

18:23:19 <kasei> ... point out problems with rdf:text. suggest to editors to add section mentioning interop issues with sparql.

... point out problems with rdf:text. suggest to editors to add section mentioning interop issues with sparql. ←

18:23:52 <kasei> ... suggest clarify interactions with sparql.

... suggest clarify interactions with sparql. ←

18:24:12 <kasei> ... rdf:text should affect D-entailment

... rdf:text should affect D-entailment ←

18:24:22 <ericP> q+ to check a use case

Eric Prud'hommeaux: q+ to check a use case ←

18:24:50 <kasei> LeeF: if not using D-entailment, datatype() would return rdf:text, no lang(), ...

Lee Feigenbaum: if not using D-entailment, datatype() would return rdf:text, no lang(), ... ←

18:25:15 <kasei> AxelPolleres: with D-entailment, rdf:text literals would entail the non-dt literal

Axel Polleres: with D-entailment, rdf:text literals would entail the non-dt literal ←

18:25:21 <ericP> q-

Eric Prud'hommeaux: q- ←

18:25:36 <kasei> AndyS: no such thing as D-entailment. class of entailments.

Andy Seaborne: no such thing as D-entailment. class of entailments. ←

18:25:39 <LeeF> q+ to ask about if rdf:text literals are allowed in SPARQL queries and if so what they mean when

Lee Feigenbaum: q+ to ask about if rdf:text literals are allowed in SPARQL queries and if so what they mean when ←

18:25:54 <SteveH> q+ to ask meta-question

Steve Harris: q+ to ask meta-question ←

18:27:11 <kasei> ... literals have lang or dt, not both. code relies on this.

... literals have lang or dt, not both. code relies on this. ←

18:27:47 <kasei> AxelPolleres: want to say rdf:text is only syntactic.

Axel Polleres: want to say rdf:text is only syntactic. ←

18:28:20 <kasei> AndyS: you've introduced a new problem. haven't heard answers to previously brought up problems

Andy Seaborne: you've introduced a new problem. haven't heard answers to previously brought up problems ←

18:30:33 <kasei> AxelPolleres: if your data doesn't have rdf:text in it, you won't get it out of the functions.

Axel Polleres: if your data doesn't have rdf:text in it, you won't get it out of the functions. ←

18:30:55 <bglimm> q+

Birte Glimm: q+ ←

18:31:45 <kasei> AndyS: i can't sort out based on the current spec what a sparql processor should do

Andy Seaborne: i can't sort out based on the current spec what a sparql processor should do ←

18:32:08 <kasei> LeeF: I keep thinking of rdf:text nodes int he graph

Lee Feigenbaum: I keep thinking of rdf:text nodes int he graph ←

18:32:56 <kasei> ... would you need to prohibit literal constants in queries that are typed as rdf:text?

... would you need to prohibit literal constants in queries that are typed as rdf:text? ←

18:32:56 <LeeF> FILTER(lang("foo@en"^^rdf:text))

Lee Feigenbaum: FILTER(lang("foo@en"^^rdf:text)) ←

18:33:30 <LeeF> INSERT { <a> <b> "foo@en"^^rdf:text } ...

Lee Feigenbaum: INSERT { <a> <b> "foo@en"^^rdf:text } ... ←

18:33:36 <kasei> ericP: no reason somebody would assert such a query in RDF right now

Eric Prud'hommeaux: no reason somebody would assert such a query in RDF right now ←

18:34:02 <kasei> ... we can ignore it if there's no use case for writing some literal has datatype rdf:text.

... we can ignore it if there's no use case for writing some literal has datatype rdf:text. ←

18:34:55 <bglimm> q-

Birte Glimm: q- ←

18:35:13 <LeeF> ack me

Lee Feigenbaum: ack me ←

18:35:13 <Zakim> LeeF, you wanted to ask about if rdf:text literals are allowed in SPARQL queries and if so what they mean when

Zakim IRC Bot: LeeF, you wanted to ask about if rdf:text literals are allowed in SPARQL queries and if so what they mean when ←

18:35:28 <kasei> AndyS: need to give guidance for tools that generate this (data, queries?)

Andy Seaborne: need to give guidance for tools that generate this (data, queries?) ←

18:36:28 <kasei> ... it's legal and generates confusion.

... it's legal and generates confusion. ←

18:36:43 <kasei> ... rdf:text doc doesn't make it clear what to do.

... rdf:text doc doesn't make it clear what to do. ←

18:36:52 <kasei> ... suggestions is to have a section for sparql issues.

... suggestions is to have a section for sparql issues. ←

18:37:13 <kasei> ericP: shouldn't be a "sparql" section

Eric Prud'hommeaux: shouldn't be a "sparql" section ←

18:38:32 <kasei> ... what you can learn from SPARQL you can also find through a graph api

... what you can learn from SPARQL you can also find through a graph api ←

18:39:19 <kasei> AndyS: if you turned it into an RDF graph, you wouldn't see rdf:text

Andy Seaborne: if you turned it into an RDF graph, you wouldn't see rdf:text ←

18:40:08 <kasei> ericP: what behaviour for an owl restriction for things with rdf:text datatype. does it have any members?

Eric Prud'hommeaux: what behaviour for an owl restriction for things with rdf:text datatype. does it have any members? ←

18:40:58 <kasei> AndyS: half the text in the spec tries to stop you from doing that.

Andy Seaborne: half the text in the spec tries to stop you from doing that. ←

18:41:39 <kasei> ... not a sparql-specific issue.

... not a sparql-specific issue. ←

18:42:12 <kasei> ... other than new issues, where are we on current text?

... other than new issues, where are we on current text? ←

18:42:36 <kasei> AxelPolleres: would not require a new section

Axel Polleres: would not require a new section ←

18:43:43 <kasei> AndyS: removing the discussion of codepoints would be a good start

Andy Seaborne: removing the discussion of codepoints would be a good start ←

18:44:24 <AxelPolleres> EricP, are you talking about http://www.w3.org/2009/sparql/wiki/Rdf_text_LC_WG_comment#IRIs_vs._URIs now?

Axel Polleres: EricP, are you talking about http://www.w3.org/2009/sparql/wiki/Rdf_text_LC_WG_comment#IRIs_vs._URIs now? ←

18:44:49 <kasei> ericP: sparql went with IRI for allowable values. would like discussion on iri vs. uris.

Eric Prud'hommeaux: sparql went with IRI for allowable values. would like discussion on iri vs. uris. ←

18:45:09 <kasei> ... sparql made decision on intent of rdf core

... sparql made decision on intent of rdf core ←

18:45:53 <kasei> ... allowing iri resources (kanji, arabic in urls, etc.)

... allowing iri resources (kanji, arabic in urls, etc.) ←

18:46:10 <kasei> ... draw text from sparql spec

... draw text from sparql spec ←

18:46:22 <AndyS> q?

Andy Seaborne: q? ←

18:46:35 <kasei> AxelPolleres: would like concrete suggestion

Axel Polleres: would like concrete suggestion ←

18:46:42 <ericP> http://www.w3.org/TR/rdf-sparql-query/#docTerminology

Eric Prud'hommeaux: http://www.w3.org/TR/rdf-sparql-query/#docTerminology ←

18:47:20 <ericP> \http://www.w3.org/TR/rdf-sparql-query/#QSynIRI

Eric Prud'hommeaux: \http://www.w3.org/TR/rdf-sparql-query/#QSynIRI ←

18:47:58 <ericP> scribenick: ericP

(Scribe set to Eric Prud'hommeaux)

18:48:03 <ericP> ack SteveH

ack SteveH ←

18:48:03 <Zakim> SteveH, you wanted to ask meta-question

Zakim IRC Bot: SteveH, you wanted to ask meta-question ←

18:48:38 <ericP> SteveH: i didn't see how rdf:text solved the problem

Steve Harris: i didn't see how rdf:text solved the problem ←

18:49:10 <ericP> ... the right way to do this was to change RDF and attempt to isolate the other specs from those changes as best you can

... the right way to do this was to change RDF and attempt to isolate the other specs from those changes as best you can ←

18:49:38 <ericP> AxelPolleres: i think only the semantic equivalence is a problem

Axel Polleres: i think only the semantic equivalence is a problem ←

18:50:10 <ericP> ... we started with symbols spaces which were not the same as RDF's

... we started with symbols spaces which were not the same as RDF's ←

18:50:21 <ericP> OWL was doing something similar

OWL was doing something similar ←

18:50:31 <ericP> AxelPolleres, OWL was doing something similar

AxelPolleres, OWL was doing something similar ←

18:51:23 <ericP> SteveH: as it stands, rdf:text changes RDF

Steve Harris: as it stands, rdf:text changes RDF ←

18:51:40 <ericP> ... which means that those hundreds of RDF impls are technically incorrect

... which means that those hundreds of RDF impls are technically incorrect ←

18:52:14 <ericP> AxelPolleres: the alternative serialization is only present in RIF

Axel Polleres: the alternative serialization is only present in RIF ←

18:52:51 <ericP> ... there is a combined semantics of RIF and RDF graphs

... there is a combined semantics of RIF and RDF graphs ←

18:55:12 <ericP> AndyS: by putting the language info into a lexical form, it's not behaving like other datatype [extensions]

Andy Seaborne: by putting the language info into a lexical form, it's not behaving like other datatype [extensions] ←

18:56:02 <SteveH> q-

Steve Harris: q- ←

18:56:11 <ericP> what's FILTER ("@"^^rdf:text == false) ?

what's FILTER ("@"^^rdf:text == false) ? ←

18:56:19 <ericP> or FILTER (""^^rdf:text == false) ?

or FILTER (""^^rdf:text == false) ? ←

18:57:42 <AndyS> http://www.w3.org/2009/sparql/wiki/Rdf_text_LC_WG_comment#FILTERs

Andy Seaborne: http://www.w3.org/2009/sparql/wiki/Rdf_text_LC_WG_comment#FILTERs ←

18:58:36 <AxelPolleres> ""^^rdf:text

Axel Polleres: ""^^rdf:text ←

18:59:50 <AxelPolleres> ""^^xs:integer

Axel Polleres: ""^^xs:integer ←

19:00:05 <AndyS> FILTER(""^^xs:string)

Andy Seaborne: FILTER(""^^xs:string) ←

19:00:10 <AndyS> FILTER("false"^^xs:string)

Andy Seaborne: FILTER("false"^^xs:string) ←

19:00:23 <AxelPolleres> FILTER(""^^xs:integer)

Axel Polleres: FILTER(""^^xs:integer) ←

19:00:46 <AxelPolleres> FILTER ("@"^^rdf:text == false)

Axel Polleres: FILTER ("@"^^rdf:text == false) ←

19:03:32 <AndyS> http://www.w3.org/TR/rdf-sparql-query/#ebv

Andy Seaborne: http://www.w3.org/TR/rdf-sparql-query/#ebv ←

19:16:27 <AxelPolleres> eric, are you typing in http://www.w3.org/2009/sparql/wiki/Rdf_text_LC_WG_comment ?

(No events recorded for 12 minutes)

Axel Polleres: eric, are you typing in http://www.w3.org/2009/sparql/wiki/Rdf_text_LC_WG_comment ? ←

19:17:16 <AndyS> I hope that the replies from the OWL/RIF will include references to specific text

Andy Seaborne: I hope that the replies from the OWL/RIF will include references to specific text ←

19:17:57 <ericP> http://www.w3.org/2009/sparql/wiki/Rdf_text_LC_WG_comment#Proposal

http://www.w3.org/2009/sparql/wiki/Rdf_text_LC_WG_comment#Proposal ←

19:31:41 <LeeF> PROPOSED: Send the text on http://www.w3.org/2009/sparql/wiki/Rdf_text_LC_WG_comment as SPARQL WG feedback to OWL WG and RIF WG regarding rdf:text Last call

(No events recorded for 13 minutes)

PROPOSED: Send the text on http://www.w3.org/2009/sparql/wiki/Rdf_text_LC_WG_comment as SPARQL WG feedback to OWL WG and RIF WG regarding rdf:text Last call ←

19:31:56 <ericP> second

second ←

19:32:08 <AndyS> http://www.w3.org/2009/sparql/wiki/index.php?title=Rdf_text_LC_WG_comment&oldid=753

Andy Seaborne: http://www.w3.org/2009/sparql/wiki/index.php?title=Rdf_text_LC_WG_comment&oldid=753 ←

19:34:55 <LeeF> PROPOSED: Send the text on http://www.w3.org/2009/sparql/wiki/index.php?title=Rdf_text_LC_WG_comment&oldid=754 as SPARQL WG feedback to OWL WG and RIF WG regarding rdf:text Last Call

PROPOSED: Send the text on http://www.w3.org/2009/sparql/wiki/index.php?title=Rdf_text_LC_WG_comment&oldid=754 as SPARQL WG feedback to OWL WG and RIF WG regarding rdf:text Last Call ←

19:44:24 <AxelPolleres> http://www.w3.org/TR/2009/WD-rdf-text-20090421/

(No events recorded for 9 minutes)

Axel Polleres: http://www.w3.org/TR/2009/WD-rdf-text-20090421/ ←

19:44:30 <AndyS> http://www.w3.org/TR/2009/WD-rdf-text-20090421/#Relationship_with_Plain_Literals_and_xs:string

Andy Seaborne: http://www.w3.org/TR/2009/WD-rdf-text-20090421/#Relationship_with_Plain_Literals_and_xs:string ←

19:55:38 <kasei> scribenick: kasei

(No events recorded for 11 minutes)

(Scribe set to Greg Williams)

19:55:55 <kasei> LeeF: suggests sending comments without suggested text

Lee Feigenbaum: suggests sending comments without suggested text ←

19:56:47 <kasei> AndyS: text regarding rdf:text not appearing in sparql xml results should go along with similar text on rdf graph serializations.

Andy Seaborne: text regarding rdf:text not appearing in sparql xml results should go along with similar text on rdf graph serializations. ←

20:00:27 <AxelPolleres>  PROPOSED: Send the text on http://www.w3.org/2009/sparql/wiki/Rdf_text_LC_WG_comment as SPARQL WG feedback to OWL WG and RIF WG regarding rdf:text Last call

Axel Polleres: PROPOSED: Send the text on http://www.w3.org/2009/sparql/wiki/Rdf_text_LC_WG_comment as SPARQL WG feedback to OWL WG and RIF WG regarding rdf:text Last call ←

20:01:10 <AndyS> http://www.w3.org/2009/sparql/wiki/index.php?title=Rdf_text_LC_WG_comment&oldid=758

Andy Seaborne: http://www.w3.org/2009/sparql/wiki/index.php?title=Rdf_text_LC_WG_comment&oldid=758 ←

20:01:33 <LeeF> PROPOSED: Send the text on http://www.w3.org/2009/sparql/wiki/index.php?title=Rdf_text_LC_WG_comment&oldid=758 as SPARQL WG feedback to OWL WG and RIF WG regarding rdf:text Last call

PROPOSED: Send the text on http://www.w3.org/2009/sparql/wiki/index.php?title=Rdf_text_LC_WG_comment&oldid=758 as SPARQL WG feedback to OWL WG and RIF WG regarding rdf:text Last call ←

20:01:48 <AxelPolleres> +1

Axel Polleres: +1 ←

20:01:52 <bglimm> +1

Birte Glimm: +1 ←

20:01:57 <pgearon> +1

Paul Gearon: +1 ←

20:02:11 <LeeF> RESOLVED: Send the text on http://www.w3.org/2009/sparql/wiki/index.php?title=Rdf_text_LC_WG_comment&oldid=758 as SPARQL WG feedback to OWL WG and RIF WG regarding rdf:text Last call

RESOLVED: Send the text on http://www.w3.org/2009/sparql/wiki/index.php?title=Rdf_text_LC_WG_comment&oldid=758 as SPARQL WG feedback to OWL WG and RIF WG regarding rdf:text Last call ←

20:02:41 <kasei> LeeF: either AndyS or LeeF should send the comments

Lee Feigenbaum: either AndyS or LeeF should send the comments ←

20:03:05 <LeeF> ACTION: LeeF to send SPARQL WG response http://www.w3.org/2009/sparql/wiki/index.php?title=Rdf_text_LC_WG_comment&oldid=758 to OWL WG and RIF WG re: rdf:text

ACTION: LeeF to send SPARQL WG response http://www.w3.org/2009/sparql/wiki/index.php?title=Rdf_text_LC_WG_comment&oldid=758 to OWL WG and RIF WG re: rdf:text ←

20:03:05 <trackbot> Created ACTION-15 - Send SPARQL WG response http://www.w3.org/2009/sparql/wiki/index.php?title=Rdf_text_LC_WG_comment&oldid=758 to OWL WG and RIF WG re: rdf:text [on Lee Feigenbaum - due 2009-05-13].

Trackbot IRC Bot: Created ACTION-15 - Send SPARQL WG response http://www.w3.org/2009/sparql/wiki/index.php?title=Rdf_text_LC_WG_comment&oldid=758 to OWL WG and RIF WG re: rdf:text [on Lee Feigenbaum - due 2009-05-13]. ←

<LeeF> Adjourned for the day.

Lee Feigenbaum: Adjourned for the day. ←

20:04:01 <Zakim> -MIT262

Zakim IRC Bot: -MIT262 ←

20:04:07 <Zakim> -Bristol

Zakim IRC Bot: -Bristol ←

20:04:08 <Zakim> SW_(SPRQL-F2F)6:30AM has ended

Zakim IRC Bot: SW_(SPRQL-F2F)6:30AM has ended ←

20:04:10 <Zakim> Attendees were kasei, ericP, LeeF, pgearon, yimin, KjetilK, AlexPassant, AndyS, AxelPolleres, SimonS, bglimm, LukeWM

Zakim IRC Bot: Attendees were kasei, ericP, LeeF, pgearon, yimin, KjetilK, AlexPassant, AndyS, AxelPolleres, SimonS, bglimm, LukeWM ←

Formatted by CommonScribe

This revision (#1) generated 2009-05-19 06:01:17 UTC by 'lfeigenb', comments: 'Initial cleaned up minutes. Thanks to all the scribes.'