SPARQL Working Group Teleconference -- 26 May 2009

<trackbot> Date: 26 May 2009

<AndyS> zakin, who is on the phone?

<SteveH> Zakim: ??P12 is [Garlik]

<LeeF> LukeWM, can you scribe today?

<LeeF> You are the highest person on the scribe list who is here right now :)

sure

<LeeF> thanks

<LeeF> Scribenick: LukeWM

Lee: does anyone know who cory is?

Axel: main focus is talking about update

.Axel: first of all lets approve the minutes from last time & F2F

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

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

<LeeF> PROPOSED: Approve minutes of F2F1, Day1, Day2

<LeeF> http://www.w3.org/2009/sparql/meeting/2009-05-06

AxelPolleres2: lets also do the ones from the F2F meeting

<LeeF> http://www.w3.org/2009/sparql/meeting/2009-05-07

<LeeF> RESOLVED: Approve F2F minutes at http://www.w3.org/2009/sparql/meeting/2009-05-06 and http://www.w3.org/2009/sparql/meeting/2009-05-07

AxelPolleres2: OK, next meeting will be tuesday
... next on the scribe list is Chimezie

Axel: now Liason's. Bijan, anything from Owl?

bijan: rdftext is ongoing
... owl is going to vote tomorrow, so it would be good to know about anything now.

<bijan> Because of the semantic equivalence between typed rdf:text literals and plain RDF literals in datatype interpretations, the rdf:text datatype is "implicitly defined" by the set of all plain RDF literals, and each plain RDF literal can be understood as an idiosyncratic lexical form for the corresponding typed rdf:text literal. In order not to introduce syntactic redundancy in RDF graphs, typed rdf:text literals must not occur explicitly in published RDF content

<AxelPolleres2> http://www.w3.org/2007/OWL/wiki/InternationalizedStringSpec

eric: the form is "quote" bob "quote" en
... the challenge is mixing 2 specs

<AndyS> One thing still missing : need to say that BGP matching exposes rdf forms, not ^^rdf:text.

bijan: if you have an rdf api to e.g. jena, required behaviour is to expose it as a plain literal
... can expose it as a typed literal but not required

ericP: we're on the same page - the form in RDF is a plain literal

AndyS: you must get back the rdf forms

AxelPolleres2: Asks andy a question

AndyS: graph is not the right word.

bijan: Andy, is there something you'd like to include

AndyS: yes

bijan: you prefer that to Sparql saying something about it

AndyS: then you don't end up with a dependency.
... Sparql working group can't do every extension.
... otherwise everything will come back to SPARQL WG

bijan: so, we should include Filter functions etc?

<Zakim> ericP, you wanted to say doubt that BGPs need to be matched

AndyS: section in Sparql spec tells how to bolt in other entailment regimes

<AxelPolleres2> http://www.w3.org/TR/rdf-sparql-query/#bgpExtend talks about well-formed graphs, not well-formed scoping graphs.

eric: if there is no special entailment, then we don't need a specific reference to SPARQL.

AndyS: the case I'm thinking of is SPARQL owl

AxelPolleres2: I agree we should cover this later, and get back on topic
... anything else from other working groups?

<LeeF> me notes that we need to update liaisons list to include socialweb xg

ivan: we're still trying to get the right chair

<AlexPassant> btw, nothing from the SocialWeb XG - might be interesting contact points later when it comes to authentication in SPARUL

AxelPolleres2: should we hold the next face to face in conjunction with the t-pac in california

ericP: there are reasons to have it at the hotel instead of e.g. HP
... Advantage of HP is that we can do a split face to face, advantage of t-pac is running into other folks.
... can do 1 day and 1 day at t-pac

<ivan> I can probably come

<ericP> +1

AxelPolleres2: Who can come?

<AndyS> Too early to be sure.

<pgearon> +1

<AxelPolleres2> +1

<SimonS> +1

<Prateek> Too early to be sure

<AlexPassant> probably not

<SteveH> probably not

<kasei> I can probably attend, but not totally certain at this point.

<bijan> Probably not physically

<john-l> Probably not.

<LeeF> +1

<iv_an_ru> probably via phone only

AxelPolleres2: who can do a 2 site meeting.

<SteveH> depends what the sites were

<bijan> Depends on the site :)

<AlexPassant> 2 sides might be ok - depending on the site as well

AndyS: I thought the point of t-pac was to meet other groups
... so video conference is more irrelevant

LeeF: I hope it's half own work and half working out coordination parts

AxelPolleres2: Maybe at that point more people will have joined the group

ericP: what was the conclusion

AxelPolleres2: to do with time difference

ericP: so we do meet at t-pac

AndyS: 6 people can go, maybe

<AndyS> Are there more on the WBS?

ericP: Attend 2 days at t-pac?

LeeF: Lets figure this out in the next few weeks.

<ericP> RESOLVED: plan A is to meet two days at TPAC, though plan A is at risk

AxelPolleres2: can those who were unsure try to find out.
... Lets talk about update, we already have use cases.

<AxelPolleres2> http://www.w3.org/2009/sparql/wiki/Category:UpdateUseCases

AxelPolleres2: lets go through quickly. First data integration

<AxelPolleres2> http://www.w3.org/2009/sparql/wiki/DataIntegration

AlexPassant: each time a new data is created we send a ping to the triple store
... fetching from ping the semantic web and using LOAD as well.
... needs to load and create graphs...
... are they load, additive or replacing
... the first is replace, second additive, correct
... yes

AndyS: Need to load graphs into store with the name they have in the wild, right?

AlexPassant: yes

AndyS: doing this seems common, so it needs to be natural to do

<SteveH> we do load X into X equivalent a lot too

<AlexPassant> http://www.w3.org/2009/sparql/wiki/PersonalTagging

<AndyS> Looks to me like a replace as well.

AlexPassant: using insert into graphs and uploading them from the web

AxelPolleres2: Syntax is mix of scripting?
... there is a mix of php etc.

AlexPassant: the php was just so you can llook at the sparql query

AxelPolleres2: there is no query part involved either?

AlexPassant: no

<AxelPolleres2> http://www.w3.org/2009/sparql/wiki/DocUpdateTracking

AxelPolleres2: next use case is doc update tracking

pgearon: this has come up a few times with mulgara
... need to be able to do queries and construct new blanknodes for every binding
... creates a template structure that starts out empty and contains a load of blank nodes
... people who use mulgara do alot of updates that create blank nodes on the fly

AxelPolleres2: it is querying, right?

pgearon: it's in TQL
... and sparql update syntax
... uses OPTIONAL/filter !bound to do the equivalent of MINUS

AxelPolleres2: this is the same as a blanknode in a construct?

<SteveH> that's not what CONSTRUCT does

<SteveH> oh, sorry

pgearon: yes

<SteveH> yes, it is

pgearon: looking at insert, construct and this just about covers doing that.

<AndyS> Unfortunately, need both cases of bnodes.

AxelPolleres2: any more questions? Lets go to editing FOAF

<SteveH> LukeWM: talking about http://www.w3.org/2009/sparql/wiki/EditingFoafData

<SimonS> http://www.w3.org/2009/sparql/wiki/EditingFoafData

<SteveH> LukeWM: 2 usecases

<SteveH> LukeWM: 1) delete some triples based around a WHERE, to change name

<SteveH> LukeWM: bare minimun

<AxelPolleres2> (thanks steve)

<SteveH> LukeWM: 2nd usecase, more complicated, changing some details from address

<SteveH> LukeWM: has to delete sub-tree hanging of address

<SteveH> LukeWM: done it with some fancy syntax, like property path syntax

<SteveH> LukeWM: .+ matches any predicate

<SteveH> LukeWM: usecase for prop paths in update

<AxelPolleres2> "replace" values by delete all/insert

<SteveH> LukeWM: intended to be recursive

AxelPolleres2: you would delete all addresses, and replace with just the one, right?

<AxelPolleres2> delete subtrees!

<SteveH> LukeWM: real code just goes a couple of hops, but would like to delete entire tree

<SteveH> LukeWM: seems like it could get complicated

<iv_an_ru> hm, what's constructed is deleted, recursive delete requires recursive query and that's all.

<SteveH> LukeWM: could have other trees that depend on this one

SimonS: you could shoot yourself in the foot with this

AxelPolleres2: the semantics is clear though, right

SimonS: yes, semantics are clear

<AxelPolleres2> http://www.w3.org/2009/sparql/wiki/ResourceTopicPortals

AxelPolleres2: on to the last use case, Resoure Topic Portals

kjetil: we used sparql update with ARQ
... we have a java coder using queries and he wasn't a semantic web enthusiast, hence he's interesting
... second query uses where clause where you bind the variables
... there is also a map editing, where all URIs in system had to be changed
... final query moves data between graphs.
... could simplify the queries probably. But we have 2 cases of where clause to bind variables.

AxelPolleres2: what do you suggest for the last one, they should be easier?

<LeeF> From where I stand as someone surprisingly disinterested in the 'update' part of our work, I hear requirements for both "constant" data loading/replacing and for "query-based" data mutation

kjetil: to do it in a simpler way would be interesting, but should be weighed against other stuff.

<SteveH> it's not a trivial move

kjetil: I don't know if it would be that common to want to move stuff between graphs.

SteveH: based on my limited example of sparql update, only the last one needs a where
... perhaps someone else can correct me on that?

kjetil: In the merge 2 concepts section, the predicate and object are taken out...

<pgearon> LeeF, that exactly covers our user requirements (constant updates and query-based updates)

AxelPolleres2: Basically DELETE is the same as a WHERE, in one case

SteveH: I might be wrong

AndyS: I think SteveH is right in intent.
... If you have unbound variables in the pattern, it's like a CONSTRUCT
... you get into repetition, it's common and ugly.

<AxelPolleres2> andyS: repition is ugly.

<Zakim> AndyS, you wanted to comment on the DELETE P WHERE P form.

<Zakim> SteveH, you wanted to ask about "Insert new concept"

SteveH: I didn't realise DELETE worked like CONSTRUCT

SimonS: I thought WHERE would be the matching part but delete would be like the construct pattern. Is that true?

<ericP> that's how i read it

<SteveH> -1 to convience forms like that

AndyS: that was the intention. If you have to extract the sub pattern, it's pretty ugly.

<SteveH> DELETE { * } maybe

<LeeF> convenience forms the 2nd time around :-)

<AndyS> DELETE * WHERE P

AxelPolleres2: there are use cases for both complex, with needed WHERE clause, as well as more lightweight ones.

<LeeF> the first time around should require lots of pain - if people use it despite the pain, then you can be confident it's important :-D

<LeeF> c.f. optional/!bound

<AndyS> c.f. CONSTRUCT * (which has issues with nested GRAPH but solvable

AxelPolleres2: AndyS suggested a phased approach in a mail.

<iv_an_ru> A side note: what I like in current SPARUL is that it constructs all items to delete and or insert before starting changes (say, by making temporary dictionaries).

<iv_an_ru> At the same time, in many cases it can easily be optimized to insert or delete in a loop, as soon as next binding is found

<SteveH> AndyS, yes, it's a bit messy with GRAPH present

AxelPolleres2: The second thing is PUT, DELETE and POST - simpler
... It seemed that only the first use cases were covered, but not the others.

AndyS: It was a very large problem-space so we need to split it.

<SteveH> I'm not sure that starting with a single graph will actually be simpler

AndyS: we don't want to not do the whole thing, we just need to get some focus

AxelPolleres2: So the 1st phase wouldn't cover all the use cases

<iv_an_ru> SteveH, +1

AndyS: not Alex's, certainly, because we'd have to load data into a graph store with a particular name
... how big a chunk of work to we bite off?

<SteveH> I would got for PUT, POST first

AxelPolleres2: I want to get a sense of whether we do a 2 phased approach or not

<AlexPassant> would like LOAD (or some feature with a similar behavior) to be in the first phase

ericP: all my use cases are for UPDATE on the graph store

AndyS: whole graph operations? Is that what you mean?

<LeeF> I'm less interested in PUT, POST then in a mutation language, personally, but somewhat low priority personally for me as well

ericP: I can't answer until next week. I need to get my head around how awkward things are.

<SteveH> With CONSTRUCT and PUT you can do a lot

<SteveH> abeit inefficiently

<AndyS> PUT? That's replace?

<SteveH> yes

<AndyS> ack

LeeF: I'm more interested in doing everything, like using patterns etc, rather than RESTful stuff

<iv_an_ru> I'd say, LOAD is especially useful when one may selectively DELETE the garbage from the LOADed mess.

LeeF: that was me talking as LeeF

<LeeF> SteveH, I hadn't considered that - is there an example of that anywhere?

SteveH: if we have PUT, which in HTTP is a replace operation and CONSTRUCT, we can do a lot of modifications.

AxelPolleres2: PUT was replacing

SteveH: according to HTTP standard, yes

<pgearon> +q

<AndyS> so the division is changes of a graph and changes of a graph store (whole graph)

<AndyS> ??

SteveH: POST is additive
... not trying to replace INSERT DELETE

<LeeF> Wonders if someone understands this enough to summarize the options in email?

kjetil: main problem is we'd have to have an HTTP server and we don't have that
... WHERE clause is mandatory

<SteveH> +1 to deffering WHERE

kjetil: DELETE WHERE is mandatory but not INSERT WHERE

pgearon: I liked the semantics of HTTP put but

<AndyS> WHERE is in INSERT and DELETE : not in INSERT DATA and DELETE DATA.

pgearon: it could be abused to just do a delete, which would be subverting the semantics

AxelPolleres2: This is a question of priority

<LeeF> +1 to AxelPolleres2 summarizing

<LeeF> :)

AxelPolleres2: Let me try to summarize this, and continue with further discussion later

<AxelPolleres2> ACTION: Axel to summarize priorization issues on update [recorded in http://www.w3.org/2009/05/26-sparql-minutes.html#action01]

<trackbot> Created ACTION-33 - Summarize priorization issues on update [on Axel Polleres - due 2009-06-02].

AxelPolleres2: anyone else want a closing word on this?

<iv_an_ru> When I wrote spec for "my" SPARUL, I did not know that Andy had written similar thing right at the same time. And the only difference between two independently written spec was INSERT IN vs. INSERT INTO spelling. That resembles King Jame's Bible, so that's word of truth ;)

<Zakim> ericP, you wanted to make sure i understand where SPARUL sits

AxelPolleres2: What I got out was this: do we have additive, editing and replacing for insert
... I understand SPARUL as everything, but protocol level stuff is a subset
... do we want just protocol or protocol+language

<AndyS> Submission did not cover protocol - no common agreement

<AndyS> or just language.

<SteveH> +1 PUT and DELETE is not enough

<pgearon> +1 on update language

<SteveH> but standardising it would be good, given that it's common

ericP: there is still demand for an update language - people will ask for it if we just give then PUT and DELETE

<iv_an_ru> (ups, somtehing wrong with phone)

AxelPolleres2: does anyone want just PUT and DELETE?

<AxelPolleres2> Conclusions of today:

<AxelPolleres2> 1) more than PUT DELETE needed

AxelPolleres2: should we have both?

SteveH: I think we need both.

<AxelPolleres2> 2) sitll writing down PUT DELETE would be nice (?)

ericP: Doesn't it just fall out of HTTP?

SteveH: so many people already implement it, it would be a shame not to have it.

<SimonS> +1 to AxelsPolleres2's 2)

AxelPolleres2: lets get this to a mail discussion

ericP: Steve, we'll do this on the phone later and then have a mail discussion.

AxelPolleres2: lets adjourn

scribe is leaving, say what you like!

<SteveH> http://example.com/sparql/http://example.com/data.rdf

<SteveH> PUT http://example.com/sparql/http://example.com/data.rdf

<AxelPolleres2> ACTION: Steve to summarize issue discussed in the end of the telecon regarding PUT [recorded in http://www.w3.org/2009/05/26-sparql-minutes.html#action02]

<trackbot> Created ACTION-34 - Summarize issue discussed in the end of the telecon regarding PUT [on Steve Harris - due 2009-06-02].

- DRAFT -

SPARQL Working Group Teleconference

26 May 2009

Attendees

Contents

Summary of Action Items

Scribe.perl diagnostic output