SPARQL Working Group Teleconference -- 31 Mar 2009

<trackbot> Date: 31 March 2009

<LeeF> oh well, that was close

<ivan> :-)

<LeeF> just no one else there yet

<LeeF> i imagine :)

<bijan> Except me :)

<bijan> LeeF: Another mancuian shall be joining the group soon

<bijan> So we'll have more consistent coverage from here

<LeeF> bijan, excellent

<AndyS> Very quiet on the phone or is it my connection?

<chimezie> Zakim: passcode?

<kasei> AndyS: no, it's very quiet

noones talking, AFAICT

<iv_an_ru> something strange with my phone :|

<LeeF> Scribenick: SteveH

administrivia

<LeeF> PROPOSED: Approve minutes at http://www.w3.org/2009/sparql/meeting/2009-03-24

LeeF: PROPOSED approved mins from last week

<kjetil> +1

SteveH: 2nd

<iv_an_ru> Nth

<scribe> scribenick: SteveH

<scribe> scribe: SteveH

<LeeF> RESOLVED: Approve minutes at http://www.w3.org/2009/sparql/meeting/2009-03-24

F2F

LeeF: set for F2F on 7th, cambridge and bristol

<LeeF>

LeeF: do we prefer web survey to wiki

<ericP> looks like the3 wiki has it

LeeF: everybody to add status to wiki
... need to juggle scibe list for 7th april
... compliments on not messing up time change

<Zakim> bijan, you wanted to ask about HTML5

bijan: on CURIEs, don't think there's anything to talk about, WG has setup dependency on SPARQL re. CURIEs

AndyS: confused, SPARQL does not depend on CURIE

LeeF: OWL also does not

bijan: suggest not to delegate to CURIE spec

<ericP> SPARQL grammar with CURIEs

<Zakim> ericP, you wanted to say i implemented the SPARQL grammar with curis

ericP: ralph asked would they work, turns out they do

<john-l> We would support prefix:path/to/something with curies, right?

ericP: ~103 changes a bit

LeeF: move to ML

ivan: from now on OWL makes normative ref. to SPARQL as far as prefix is concerned
... is SPARQL wants to change that we have to be careful

bijan: HTML5 WG is considering RDFA, this group might have some input, it's in some sense relevent, wanted to raise

<bijan> Specifically on production [98], [99], [100]

<ericP> bijan, hints as to what we might want to sniff at?

<bijan> Well, for example, if RDFa is in HTML5 we might want to support querying it directly

LeeF: disucuss on ML if you have an opinion on HTML5+RDFa

<LeeF> tracker for SPARQL WG

LeeF: we have tracker setup that keeps track of actions, ala DAWG v1

<LeeF> open actions

<LeeF> trackbot, close action-1

<trackbot> ACTION-1 Ask EricP to setup a WBS for the F2F closed

<LeeF> action-4: http://lists.w3.org/Archives/Public/public-rdf-dawg/2009JanMar/0186.html

<trackbot> ACTION-4 Summarise the vocabularies (DARQ, SADDLE, voiD) notes added

<LeeF> trackbot, close action-4

<trackbot> ACTION-4 Summarise the vocabularies (DARQ, SADDLE, voiD) closed

<LeeF> trackbot, close action-5

<trackbot> ACTION-5 Add security issues to query by reference feature closed

<kjetil> action-2: http://www.w3.org/2009/sparql/wiki/RedundandFeature:Parameterised_queries#Use_cases

<trackbot> ACTION-2 Update the wiki page with his experience (caveat: kjetil may be delayed in doing it) notes added

LeeF: features

<kjetil> trackbot, close action-2

<trackbot> ACTION-2 Update the wiki page with his experience (caveat: kjetil may be delayed in doing it) closed

ExecCommentsAndWarning

LeeF: exec comments and warnings feature...

Features

Orri: runtime exceptions, any possible number of errors, would like to be able to stream the results, with errors inline
... would like to be able to send first row of results, but put errors after
... we have cases where we need to stream the results

<LeeF> SteveH: Two of our internal engines do this using an ASCII-based result format

<kjetil> action-2: Whoops, wrong link, this is it: http://www.w3.org/2009/sparql/wiki/Feature:ReturnFormatKeyword#Related_Use_Cases.2FExtensions

<trackbot> ACTION-2 Update the wiki page with his experience (caveat: kjetil may be delayed in doing it) notes added

LeeF: my concern is that we don't have a lot of impl. experience, would need to play within the existing result format, dont see strainghtforward way to do that

AndyS: I can see straightforward way

iv_an_ru: I don't think it's difficult

LeeF: how about CONSTRUCT

<AndyS> Not me - that's Orri

Orri: could include triples in dedicated namespace, some kind of convention with triples

<LeeF> SteveH: we do it in RDF/XML using XML comments

AndyS: for SELECT, if it is a change to format to put in something other than a row, would be changing schema, so people may be affected

also we do same in SPARQL XML res

(comment that i)

LeeF: straw poll

-1, too early, compatibility issues

<bijan> +1

<kasei> 0; but might support standarizing an xml ns URI for this use (outside spec)

<kjetil> 0

<AlexPassant> 0

<john-l> 0

<chimezie> 0

<AndyS> 0 (-1 if it includes deciding errors that can be reported)

<ericP> 0

<LukeWM> -1

<ivan> 0

<bijan> er.. -

<JanneS> 0

<bijan> 0

<SimonS> 0

<LeeF> Orri: +1

<bijan> REAL VOTE: +0

<LeeF> 0

query response linking

<bijan> I would go +1 probably after examining the existing implementations

<LeeF>

SimonS: the idea is to add something to protocol to set links to additional information, eg. a licencse to an endpoint that prodiced, endpoint etc.
... can do it in SELECT, but not typed
... similar to HTML link tag
... has a number of relationship types that are listed, but we could do something else
... so it can be in CONSTRUCT

<SimonS> yes, was me

ivan: dont know all details, but there were discussions in HTML for categorising, wouldn't that cover it

<SimonS> +q

ivan: do we have to do anything, or rely on HTTP

<kasei> setting the http headers of a response is generally harder than changing the body content.

LeeF: would be a bit strange to do it in HTTP header for more expresivity

<chimezie> Isn't there a clog in the process of registering HTTP Link header?

SimonS: I think having it in protocol would be better, we should have something like the thing in HTML4, should have something based on URIs

<LeeF> SteveH: having this in the result format is wacky since it only applies to SELECT results, but nothing mandates that SPARQL be over HTTP

<LeeF> ... on balance I'd rather see it in protocol

LeeF: if we accept this, we still have plenty of lattitude, so discussion could come later

<kasei> the wiki page gives an example of using it in an RDF response (construct/describe)

orri: I think the usecase is has to do with data being returned, might be licencing, eg. if we repurpose, then sth like CC you have to reference source, it's probably better in protocol than HTTP

kjetil: I think that I would have done it by having graph names for the licence, so this could be doe mostly at the endpoint without change to protocol
... not in the general case, but for many it doesn't need to go in

LeeF: 1 argument is for having a standard place to look
... is there value in specific types of metadata

kjetil: thats a general problem with data discovery, a licence is just another triple

<AndyS> If in protocol, it will likely get split from the results if stored or passed on.

<LeeF> SteveH: a bit concerned about oversimplification - consider the case in which an end point is serving data from multiple sources with multiple licenses

<kasei> +1

<LukeWM> 0

<kjetil> -1

<chimezie> +1

<SimonS> +1

<dnewman2> 0

<john-l> 0

<AndyS> -1

<AlexPassant> +1

<ivan> -1 (trying to set priorities)

<LeeF> Orri: 0

<JanneS> -1

<ericP> -1

<LeeF> 0

<bijan> 0

query language features

<LeeF> subtopic: assignment

assignment

<LeeF>

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
... implemented in ARQ, it's quite popular

LeeF: is assingment purely syntactic if we have susbselect and named projection

AndyS: not sure about scoping, but they're clearly related

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

<LeeF> SteveH: ...given my background

AndyS: similar thing is the ability to put an expression inline, syntactic sugar for putting a [something] in there
... it doesn't introduce a binding, but it's in the same space

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

ericP: I would argue that creating a varaible is doable in SQL, but you name it with the expression name

<bijan> XQuery has lots of variables :)

<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

<bijan> For...Let...

ericP: in SPARQL we would just name it with a bound variable name

AndyS: you cant write a recursive expression

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

chimezie: doesn't it depend on evaluation model, you could assign to an expression that is refered to outside

AndyS: the proposal doesnt cover that

<Zakim> SteveH, you wanted to reply

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

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

<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

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

<ericP> ... worried about user expectations

AndyS: can have functions on RHS
... these issues will all arise, but now talking about details of mechanism, quaestion is do we want this feature

<Zakim> bijan, you wanted to ask for pointers to examples

bijan: wondering if andy has pointers to examples from users, having trouble wrapping mind around standard functions

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

bijan: looking for app examples, where used in anger

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

AndyS: used particularly in the case where there's a CONTRCUT

<chimezie> Holger's commets

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

<JanneS> yup

LeeF: anyone else implemented it

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

SimonS: we did it internally, but can't say anything about user requirements

LeeF: straw poll

-1

<kjetil> +1

<kasei> +1

<AlexPassant> +1

<chimezie> -1

<LukeWM> 0

<john-l> 0

<ericP> +1

<bijan> +0

<SimonS> +1

<AndyS> +1

<ivan> 0

<JanneS> +1

<dnewman2> 0

<LeeF> Orri: -1 un-query-language like

<LeeF> 0

LeeF: fan of feature, but happy to be able to do it other ways

accesing rdf lists

subtopic: accessing rdf lists

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

AndyS: desire i to access all memers of a list in a length-neutral way
... can do it with fixed length lists in some caes, but it gets burdensome
... 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
... so you get duplicates
... implemented in ARQ, looks like rdfs:member, but applies to lists

AndyS, used where you don't have closed lists

Orri: we have general transitive subquery, maybe be macro expanded into subquery
... no special syntax

<john-l> Is that transitive subquery feature listed on the Wiki?

Orri: we would not mid making shorthand

<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

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

<ericP> members(?x) ordered("1" "2") unordered("2" "1")

<ericP> +1 to ivan's point

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

<AlexPassant> +1 wrt vocabulary design

ivan: so had negative effect on the way vocabs were defined

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

<chimezie> since the tail is always rdf:nil

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

AndyS: it's not the rdf:nil that's that issue

LeeF: any subset of the list, looks like a list

<ericP> (1 2 3) => (2 3) => (3) => ()

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

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

LeeF: my experiance has been that I'm mostly querying for a specific menber

+1 to LeeF

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

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

<bijan> Redundant answers can also be a problem

SimonS: can you give an example of realworld query where don't know the head
... whenever I query a list I know the head

AndyS: to some extent it's a corner case, but can produce a lot of questions
... if you try to get into explaining then it causes confusion

bijan: I would have thought that problem is that when you think you have the query, you're actually punching into the middle
... you could end up querying the tail, that would be a worry

<ivan> +1

<kjetil> +1

<ericP> +1

<bijan> +1

<AlexPassant> +1

LeeF: strawpoll on rdf lists query mechanism

<LukeWM> +1

<AndyS> +1

<john-l> +1

<kasei> +1

<JanneS> +1

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

<dnewman2> +1

<bijan> (and I hate rdf:lists :))

<SimonS> -1 ack with chimezie

<LeeF> Orri: +1

<LeeF> -1 (with Simon & Chime)

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

?: if it doesn't I would

LeeF: I'm indifferent if we do property paths or not

thanks

<bijan> I had Ivan's question :)

ericP: +1 on having list access as a requirement, however we do it

ivan: if property paths work, then I happy to sump special syntax

<bijan> Though, special syntax should be evaluated separately

orri: it seems that property paths would have to be extended
... email about that on the list

<bijan> Property Paths are way more heavyweight than special list handling

<bijan> +1 SteveH

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

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

<bijan> I could see implementations wanting to support lists but not property paths

yup

LeeF: things that don't cleanly fall into nice boxes, bijan asked if anyone would object to moving feature pages so they're not in feature:

<ericP> don't all of our features start with F?

<JanneS> sorry, could only do 60mins today - cu

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

<ericP> +!

<ericP> +1

<bijan> MediaWiki is good that way

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

<ericP> +ℑ

<kjetil> +1 only if there is redirect, -1 if not

AndyS: I like them all coming up together

LeeF: inclined to say I don't really care
... bijan, if you want to do it go ahead
... 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
... aroudn end of next telecon, want survey for a couple of weeks to get formal positions on pioritising features

<kjetil> condorcet voting

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

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
... telecon is a contraint

<bijan> Task forces!

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
... task force of 1-3 people not always best

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

<bijan> AndyS, for sure

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

<bijan> I was being somewhat ironic

LeeF: we've clearly indentifed some important features

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

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

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

- DRAFT -

SPARQL Working Group Teleconference

31 Mar 2009

Attendees

Contents

administrivia

F2F

ExecCommentsAndWarning

Features

query response linking

query language features

assignment

accesing rdf lists

Summary of Action Items

Scribe.perl diagnostic output