SV_MEETING_TITLE -- 06 Jul 2011

<AndyS> (maybe)

hello, I'm am here and ready to scribe.

<mischat_> hello

<davidwood> Thanks

<scribe> scribe: cmatheus

<scribe> Scribe: cmatheus

<davidwood> scribe: cmatheus

I was expecting a confirmation from Zakim but haven't seen one.

<davidwood> sandro: We could use your help with the 22 June telecon minutes if you can. Please see email for details.

<AndyS> zakim a bit confused? #41 not working? Very very delayed?

<davidwood> Scribe: Christopher Matheus

is there a way to confirm that am the scribe?

<davidwood> scribenick: cmatheus

<sandro> done, davidwood

<davidwood> cmatheus, That is an RRSAgent function, not a Zakim function.

<davidwood> sandro, thanks!

thanks

<davidwood> np

<sandro> scribe: cmatheus

davidwood: telecom minutes from June 22 -- I don't see them

<davidwood> sandro, URL for the 22 June minutes? I don't see them...

<AndyS> Were there minutes from the graph terminology RDF/SPARQL telecon?

<davidwood> PROPOSED to accept the minutes of the 29 June telecon:

<davidwood> http://www.w3.org/2011/rdf-wg/meeting/2011-06-29

in mean time... propose to accept minutes form June 29

<AndyS> OK - thx davidwood.

does anyone object to them being accepted?

<sandro> davidwood, http://www.w3.org/2011/rdf-wg/meeting/2011-06-22

<sandro> (not cleaned up AT ALL thought)

okay, accpet the June 29 minutes as written

Resolution: minutes June 29 acceptted

<yvesr> i did

davidwood: Richard was going to fix the minutes but is on holiday

typical of summer so we'll leave in his hands

<gavinc> http://www.w3.org/2011/rdf-wg/meeting/2011-06-22 haven't you know read them

I'm no longer in member acl so some things I cannot edit

we now have minutes for 22 June meeting -- please look through them so we can resolve them

no resolutions but thought there were some action items taken

one thing from meeting was we agreed to defer issue 32 until next meeting

discussed on June 29 but no resolution was proposed

<LeeF> I am, but there are people talking in my office

<LeeF> ISSUE-32?

<trackbot> ISSUE-32 -- Can we identify both g-boxes and g-snaps? -- open

<trackbot> http://www.w3.org/2011/rdf-wg/track/issues/32

is Lee here today? do you have any comment on issue 32?

LeeF: I think we discussed it a bunch but we said we had to wait on actions from graph telecomm

things seemed close but there were actions on Righard and a few others to make a proposal to align things

davidwood: with that taken care of are there objections to June 22 minutes?

<AndyS> abstain (was no there)

<AndyS> abstain (was not there)

resolution: accept minutes for June 22

<davidwood> Turtle Editors Draft

<davidwood> http://dvcs.w3.org/hg/rdf/raw-file/tip/rdf-turtle/index.html

<davidwood> ▪ Discuss existing issues, notes.

<davidwood> ▪ Any other issues to raise?

davidwood: move on to turtle discussion

eric or gavin, which would like to go through document in terms of issues and notes?

ericp: gavin more tapped in than me

<davidwood> cygri, hi. Have you been able to create minutes for the RDF/SPARQL telecon?

gavinc: out standing issue 13 around xsd strings and plain literals, some language about it in the draft

issue about escape sequences being allowed

<PatH> david, if that was meant for me, not yet.

and the grammar table has issues

<cygri> davidwood, no, totally forgot about it, sorry. i have the log and will do it first thing tomorrow

in the production of the table (editorial issue)

davidwood: associate issue in doc with working group issues

gavin: I didnt see an issue for the one Eric added?

ericP: I'm not sure there's an issue for that

davidwood: there's an issue that hasn't been openned and we should

<gavinc> AndyS, where?

gavin: if there is one it would be could to be able to link to it

<AndyS> gavinc - in the abstract (in tip)

davidwood: we have 9 issues that have been raised and not openned

<AndyS> gavinc - not a block on FPWD

I'd rather use tracker to track issues so we should raise issues for these

<davidwood> http://www.w3.org/2011/rdf-wg/track/issues/new

<AndyS> ISSUE-13?

<trackbot> ISSUE-13 -- Review RDF XML Literals -- open

<trackbot> http://www.w3.org/2011/rdf-wg/track/issues/13

gavinc: why don't I create a place holder one and we can use that

davidwood: issue 12 has been closed

cygri: issue 12 isn't closed

I JUST LOST MY PHONE CONNECTION -- COULD SOMEONE SCRIBE UNTIL I GET BACK ON?

<mischat> gavinc: : sandro asked about a change to turtle to allow <script> tags to inject turtle into an HTML document

I'm back

<mischat> gavinc: mentions that the examples in the source code of the current working spec is in the format which sandro asked for

davidwood: it's been well supported by browsers but not know by developers -- worth calling out.

<mischat> davidwood: doesn't think that the <script> tag approach isn't that well known by developers, and should be highlighted by this group

gavinc: I can stick it in there

davidwood: we're trying to move this into a working draft -- what's it look like on your schedule as far as moving this into a working draft

gavinc: I'd like to

ericp: I'd like to

<mischat> this is sandro email about the <script/> tag http://www.w3.org/mid/1307483315.2989.75.camel@waldron FWIW

<iand> +1 to publishing turtle draft as wd

<mischat> +1 to the turtle draft as a wd

davidwood: why don't we just do that in this meeing?

<PatH> +1

<davidwood> +1

<yvesr> +1

<mischat> +1

<zwu2> +1

<iand> +1

<mbrunati> +1

<AndyS> +1 to publishing Turtle doc as WD

<ericP> +1

<tomayac> +1

if the editors are ready I propose we move the turtle doc to a working draft today

<AlexHall> +1

<LeeF> +1

cmatheus: +1

<gavinc> +1 to publishing turtle as FPWD

<NickH> +1

davidwood: so resolved

<pchampin> +1

<davidwood> RESOLVED: Move http://dvcs.w3.org/hg/rdf/raw-file/tip/rdf-turtle/index.html to Working Draft.

thank you for that -- it's looking good

cygri: is this a good time to consider doing an editoers draft of RDF COncepts doc

<ericP> Proposed text: Note that Turtle can be embedded in <script></script> or <pre></pre> elements. Embedding in a script element <script type="text/turtle"><CDATA[[ turtle hear ]]></script> will not be displayed by browsers, while <pre class="data"> turtle here </pre>. In the second example, you may use a class to alter display or to signify that it can be parsed as text/turtle.

only some minor changes but in a state to be considered as a working draft

<PatH> surely though the graph terminology should be in Concepts, no?

daivdwood: I agree it's time to move it to a working draft state

<yvesr> PatH, indeed

<gavinc> ericP, that's not exactly accurate, but something like that yeah

I haven't looked at the document in about 10 days

propose we make this a topic for the next meeting, June 20th.

<PatH> july, maybe?

look over the Concepts doc over the next fortnight, is that okay with you?

<gavinc> ericP, pre.example script { display:block; } for example in the turtle spec

cygri: yes that's great

davidwood: I make sure it gets on the agenda

<ericP> gavinc, sounds good

daivdwood: we've now left the tutrle draft and are moving onto graphs

Lee, can you lead this discussion in absence of minutes?

LeeF: I'm sorry, I'm not prepared to lead discussion today.

davidwood: okay.

Richard, it seems you we're asked to create minutes from an ealier telecom. will you be able to do that task?

cygri: it completely fell off my radar so I didn't make minutes from it

will do so first thing tomorrow

<mischat> i too think that the graph terminology should go into the concept document

davidwood: please send a url to the minutes when they are ready

<davidwood> ack \

<davidwood> :)

<gavinc> ack

ericp: if you want something that takes minutes and dumps them as html you can pass them to me

cygri: sounds good, I'll do that

davidwood: in absense of Lee today I suggest we go through things oppened in June 29 telecom, unless someone has better idea for today's time

let's go to issue 14: whats a named graph and what should we call it?

sandro hs proposed the term gbox with we have consensus on

we now ned to align this with SPARQL documents which are much further along

path: we're having discussion on email on this topic - not sure of the state they're in

some progress is being made, not sure what you want to do now

davidwood: everyone seems to want to seem mintues form that telecom.

let's take a quick look down issues list and see if there's one that we can make progress on

<cygri> ISSUE-38?

<trackbot> ISSUE-38 -- What new vocabulary should be added to RDF to talk about graphs? -- raised

<trackbot> http://www.w3.org/2011/rdf-wg/track/issues/38

gavinc: issue 38 hasn't been discussed yet so there's nothing preventing progress on it today

<mischat> list of issues FWIW http://www.w3.org/2011/rdf-wg/track/issues/

davidwood: let's jump into 38 t see where we get

some talk on this but its a biut stale

cygri: rdb2rdf working talking about wheter we have a default graph and can we use that

<mischat> i wonder if there is any consensus with regards to what the default graph is

<ericP> i'm afraid of a graph name for the default graph

<PatH> what is THE default graph?

can we get from the rdf-wf some concept of a default graph that we can use in SPARQL

<ericP> PatH, it's MY default graph

davidwood: conflating issue 29 and 38, but it's a good point, I agree with that

<PatH> There is no notion of default anything in the RDF model.

<gavinc> Mmm, do DataSets need names too? /me ducks

<ericP> file://localhost/~ ?

andys: there isn't a default graph, as Pat's noted

<PatH> Ah. So default is a property of datasets whose value is a g-box.

<PatH> rdf:defaultGraphOf

davidwood: you were vocal about the fact that not every default graph sits in a database

<gavinc> I think so PatH

when the entire graph resides in a file the file's url is the graph -- do you recall this discussion?

andys: no

there isn't a web addressable name for the defualt graph because it's context dependent

<ericP> there are lots of ambiguous URLs

path: it's a property of data sets whose value is a graph

fit's into the rdf model perfectly if its a property

davidwood: I don't ink there's a problem with that. question is is it manditory and if the location changes does the name change?

<AndyS> ericP, not in this sense (I hope!). file://localhost/.. hides context in localhost

path: if the state has changed but the name stays the same here's an issue

<ericP> AndyS, true

<AndyS> ?? :datasetbase rdb2rdf:defaultGraph [ .... ]

davidwood: if you hash a serilization of a graph and you tweak some property of the graph you get a differe3nt has

<ericP> i'd expect that, if i were e.g. reading a test manifest and find n graphs asserted to be the default graph, i'd put them all into the default graph

path: isn't that true of any hashable arguement

davidwood: ture

<mischat> as it stands we can only sign serialisations anyway

<gavinc> really? graphs are madness? ;)

the naming is metadata that's outside of the graph -- get recursion problem of meta data, and metapmeta data and there lies maddness

path: things that are named by uri's but are changeable but we want name to stay the same this raises a lot of issues for rdf that I don't thin we can solve

this would get very difficult

<AndyS> ARQ uses <urn:x-arq:DefaultGraph> which is very poor modeling but very useful (as per rdb2rdf UC) GRAPH<urn:x-arq:DefaultGraph> {...} works :-)

davidwood: if you change a graph you 've go a copy of a grph that's a very different thing

I think I agree with you and it's not an issue

<cygri> AndyS, that would work for us. We use rr:defaultGraph

MacTed: if we say once we name something that it never chances that we've got problems

<AndyS> cygri, as property? As resource?

I've been the same person all my life but I've changed over time

<PatH> Thi sis what we have the g-box/graph distinction for.

the graph that desribes me changes over time but it describes me

<PatH> GRAPHS DO NOT CHANGE.

<cygri> AndyS: <... some mapping rules ...> rr:targetGraph rr:defaultGraph.

this is a problem that needs to be change - immutability of descriptions needs ot come into play soo

need complete set of identifiers that nail down a document at a given point in time

I'm not comfortable I have gbox and gtext names right in my head yet

WHO'S TALKING PLEASE?

<PatH> Andy

thanks

andys: in a perfect snapshot of web (no changes, everyting static) if you give a name to the graph which is a uri it needs to go to the smae place

<PatH> Right, so default-graph is a property even in a static Web.

that concept of the world doesn't work if you use a uri for the default graph

pchampin: I agre with pat about the DF.

<AndyS> cygri - rr:defaultGraph names what resource? GET rr:defaultGraph --> ?

the problem comes from the misue of the default graph

<cygri> AndyS, why presume that you can GET graph names?

if youink of he default graph as a gbox then things work

<cygri> AndyS, GET rr:defaultGraph, you get the R2RML vocabulary document

andys: it can be a gsnap and you can freeze everything

davidwood: makes sense to me in a database context

<ericP> when do we care about naming the totality of a graph?

<PatH> The issue, I think, is that if :Store is labile, then ( :store rdf:defaultGraphIs :graph .) can change truthvalue when :store is updated.

<ericP> defining inferential closure

<mischat> +1 to pchampin explanation, i wonder why the RDF WG are worrying about the default graphs, surely these are triplestore/sparql related. and as far as I can tell are vendor specific in the world of triplestore

not true for rdf users who never use a rdf store

<ericP> writing tests

<AndyS> cygri, conceptually, names can be resolved. I am asking if it is the name of a graph and so is GET <someURL> if it's http://

dange in using erms that don't apply to larger community

andys: we must keep in mind that when we say graph sometimes we mean gbox, something gsnap

in this case I think it means gbox

<mischat> i guess when you execute a sparql query on a sparql store, you are getting results on a g-snap

cygri: reply to Andy from earlier...

I don't think there's an assumption that the graph name has to resolve to the graph

not sure what the basis is for such a presumption

<PatH> RDG graph is (defined to be) a set, in the mathematical sense of "set". Mathematical sets don't change.

from that point of view I don't see problem with assigning a uri to a graph

<cygri> http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs-UC

another point, maybe it's good to think back to use cases

there's a wiki page from monhs ago of really good use cases

<yvesr> +1 to think back of use cases

SPAQRL as it stands can address most of these use case

<pchampin> well, Richard, http://www.w3.org/TR/sparql11-http-rdf-update/ suggests that graph URIs *could*, in some situations, resolve to the content of the graph

might be goog to see which use cases break when we use SPARQL design

<PatH> goog, but not good.

davidwood: this is fundamentally the arguement -- theiry vs. practise

path: I pretty much agree with Richard

<AndyS> (was just about default graph -- different from other naming UCs)

however, if we introduce rdf terminology for DG then we can say something is "DF" then its truth value can change with the datate store is changed

cygri; isn't this always the case?

path: no

<yvesr> linked data changes a lot...

<yvesr> like any other data on the web

<yvesr> look at wikipedia!

if these things are going to be changing their state very rapidly what's the point of creating them

cygri: even if triple is valid for only a few ms that's fine if that's what you need

<AndyS> FROM <graph1> => one default graph ... elsewhere FROM <graph2> ==> different default graph ... even in a fully static world.

path: let me back off and agree

we shouldn't make it illegal but we should draw attention to it and warn people about it

triples that change qucikly is different from the original intended use of RDF

davidwood: five years ago rdf databases were read optimized

we don't see that in the world now at all

<AlexHall> we store a lot of system state in an rdf database, and it's subject to frequent change. we also don't tend to expose that mutable state outside our system.

there are massive deletes, rapid write. this has been a sea change in the way people use rdf in the last few years

path: okay, but if we do this and start using this terminology a lot of people are going to be surprised

<mischat> we are current doing > 2000 queries/updates per second on our live sparql store

<LeeF> I think it might be useful to have test cases that exhibit the difference between these two approaches to terminology -- what actually changes?

path: the gbox and gsnap concepts we have we defined and gsnaps are the mathimatical graphs

davidwood: we mean graph differently when we talk about gbox, gsnap and gtext

cygri: I strongly agree

big problem here. have two conflicting uses of the word graph

rdf graph - an immutable set

named graph in sparql - a graph is soming mutable. can update it and it still has same name

<MacTed> In the Anzo APIs, we use the term "named graph" for the mutable things

confusion in two uses of the word graph

<iand> might be worth considering the sparql graph as being a container of triples

<zwu2> I doubt end users care about these differences. they probably don't even realize the differences

these are fundamentally different in what they mean and we need to do some about this

andys; named graph are not behaving like the default graph

the default graph is realtive to the store and are unlike what uris give us

<iand> yes

davidwood: I might challenge that

iand - can you discuss your expectations on this

<mischat> indeed AndyS and different stores have implemented their defaults graphs in different ways

<PatH> hard to hear

<cygri> AndyS: i think i don't fully agree. <foo> in my graph and in your graph can be different

iand: garble grable...

<AndyS> cygri - true can be different but consider completely static world

what does named graph identifier mean

a tag for the graph or an identified for the graph

<AndyS> ... default graph different - not same info

<AndyS> ... Example: FROM <graph1> => one default graph ... elsewhere FROM <graph2> => different default graph

if its an identifier then you should expect the same graph where ever you are

if it's a tag you don't have the expectation that it the same graph

cygri: what Ian mentioned is different from the one I brought up earlier

regardless of whether you consider the iri in a named graph as an identifier or a tag there's still the fact the named graphs things you can update

rdf graphs are not like that

<AlexHall> problem is, the notion of "default graph" is always relative to some context

<AndyS> mischat - yes - dft graph as union of named graphs shows its different in different places as well.

<pchampin> but we can still name g-snaps and g-boxes, can't we??

rdf graphs are more like gboxs and named graphs are more like gsnaps

<AndyS> ... makes me nervous about it having a URI : property or class, not individual.

sparql doesn't make any assumptions about how you use the graph

I hear a number of people here pushing to the position where a global iri would be used in this name graph

<PatH> RIGHT

davidwood: maybe we need to talk abuot naming gsnaps and gboxes in different ways

pchampin: it sounded like Richard was claiming we could only name one kind of graph but I think we can name both

but we need to keep these notion separat

<mischat> i would like the term graph used in sparql as is, as it is used in practice, and for the RDF WG to use less ambiguous terms as spec'ed out in our previous conversation re: g-*. This discussion should probably be kept to the concepts document, and in any quad based serialisation

I agree that sparql doesn't make an assumption about the use of iri

but if you have control of an iri you can make the graph available when getting the uri

in sparql the iri is homogenous to a resource in the query

we are naming graphs with a resource not a iri

Leef: you can name anythiong with a uri

<gavinc> "A "g-snap" as an idealized snapshot of a g-box; "

davidwood: but do you have to?

<pchampin> you can name a g-snap with a literal (the corresponding g-text)

path: this discussion could have taken place in any context having to do with computer science

we have a dilema

1st - I agree you can name anything with an iri

<iand> are we just saying that there is a property sparql:graph that has a domain of sparql:Dataset and range of rdf:gsnap

<gavinc> Name g-boxes, if you want to name a specific g-snap make a new damn g-box and never change it's contents

most people will use iris to refere to graphs and others with use them for gboxes

<MacTed> the issue seems to be -- "how do we change 'named graph' everywhere to 'named g-box'?"

can't have differnt conventions for naming the two - people won't use it

people will want to use same name for the two types of graph

<MacTed> actually... currently "named graph" is used for both, g-snaps and g-boxes

the ambiguity of naming is going to be with us inthe real world

next thought - may be can have different type of property

<davidwood> PatH: Ambiguity of naming will be with us whether we like it or not.

some apply to the state some apply to the object transending the state

<pchampin> so you mean that property rdf:numberOfTriples would actually mean "number of triples in the current state of that g-box" ?

having coersion for the property isn't going to work

take rdf:type -- would have to have two different types, one for object one for state

<iand> +1 to macted's suggestion of changing "named graph" to "named gbox"

<gavinc> "we should learn to cope with ambiguity in URIs"

if a name is used ambiguously there's nothing we can do about it

<PatH> gavinc :-)

<mischat> jeni blogged about this stuff yesterday, worth a read http://www.jenitennison.com/blog/node/159

cmatheus: I need to end scribing here, sorry

I'll wait until later tomorrow to edit the minutes

<mbrunati> hi guys

<PatH> Current best guess for terminology is 'graph resource' for anything mutable that emits graph representations; 'graph' for snaps, and 'graph representation' for g-texts. THis fits with the REST terminology and allows the use of 'graph' for them all when people are being sloppy.

<gavinc> Process question.... how do we publish a WD of Turtle? :D

<davidwood> Ask Sandro :)

<gavinc> He said not to if we were using Respec ;)

<pchampin> ...but we will however ;)

<AndyS> +1 to PatH (I think ...)

<gavinc> +1 to PatH

<mischat> does the 'graph' for snaps match with the GRAPH verb in sparql

<mischat> i guess it does when thinking about queries, not sure when thinking about updates

<AndyS> query usage and update usage are different ... query world is static so g-box/g-snap binding is fixed

<AndyS> SPARQL 1.0 does not fix GRAPH uri (much careful wording) and the wording is not designed for SPARQL 1.1 update

<gavinc> the GRAPH verb means a graph resource in UPDATE and a graph in SELECT/CONSTRUCT

<gavinc> ?

<AndyS> Best rewording I can make is SPARQL 1.0 "associates" a URI with a g-snap. Different apps associate differently (name of web location for data, unique nema for action of reading).

<gavinc> Anyway, be around later today and will tag a revision for the WD for the Turtle document

<AndyS> In update there is also (URI, g-box) pair which is definitely a g-box in local store.

<davidwood> gavinc, see http://dev.w3.org/2009/dap/ReSpec.js/documentation.html#configuration to change the specStatus to WD

<pchampin> agreed

<AndyS> 'cos if you change it, you see the change but someone else's store does not change (or generally people get upset :-)

<gavinc> Yeah, know how to do that David, what to do AFTER that is somewhat confusing ;)

<gavinc> Will have a tagged HTML document by the end of today

<davidwood> gavinc, is there anything else to do? I think it will auto-update the header.

<davidwood> "The specStatus is used to pick the base style sheet, as well as to configure various parts of the specification's header and Status of this Document. "

<AndyS> gavinc, when you find out how to pub respec, coudl yo ulet me know as I have a respec note to do. There is someway to get pure HTML out apparently.

<gavinc> Yeah, that will just leave it in HG and using javascript

<gavinc> step 2 is get some XHTML to publish

<gavinc> it's First Public Working Draft isn't it?

<gavinc> some process wonk around?

<davidwood> Yes, I suppose so

<davidwood> gavinc, I'm still reading the Respec page...

- DRAFT -

SV_MEETING_TITLE

06 Jul 2011

Attendees

Contents

Summary of Action Items

Scribe.perl diagnostic output