13:56:55 <RRSAgent> RRSAgent has joined #sparql
13:56:55 <RRSAgent> logging to http://www.w3.org/2010/06/07-sparql-irc
13:57:07 <Zakim> Zakim has joined #sparql
13:57:17 <LeeF> zakim, room for 10 for 120 minutes?
13:57:19 <Zakim> ok, LeeF; conference Team_(sparql)13:57Z scheduled with code 772775 (SPARQL) for 120 minutes until 1557Z
13:57:30 <AxelPolleres> thnx lee
13:57:43 <Zakim> Team_(sparql)13:57Z has now started
13:57:50 <Zakim> +??P1
13:58:14 <NickH> zakim, ??P1 is me
13:58:14 <Zakim> +NickH; got it
13:58:45 <LeeF> "i have entered an invalid response"
13:58:45 <Zakim> + +03539149aaaa
13:58:53 <AxelPolleres> Zakim, aaaa is me
13:58:53 <Zakim> +AxelPolleres; got it
13:59:00 <Zakim> +[IPcaller]
13:59:20 <LeeF> zakim, IPcaller is me
13:59:20 <Zakim> +LeeF; got it
14:00:03 <Zakim> +[IPcaller]
14:00:17 <AndyS> zakim, IPCaller is me
14:00:17 <Zakim> +AndyS; got it
14:00:38 <LeeF> NickH, can you hear us?
14:01:03 <chimezie> chimezie has joined #sparql
14:01:37 <chimezie_> chimezie_ has joined #sparql
14:01:57 <NickH> LeeF, hello, yes I am Nicholas Humfrey
14:02:04 <NickH> sorry, I just stepped out the room
14:02:11 <Zakim> + +1.216.773.aabb
14:02:28 <chimezie_> Zakim, +1.216.773.aabb is me
14:02:28 <Zakim> +chimezie_; got it
14:02:39 <chimezie_> Zakim, who is here?
14:02:39 <Zakim> On the phone I see NickH, AxelPolleres, LeeF, AndyS, chimezie_
14:02:40 <Zakim> On IRC I see chimezie_, chimezie, Zakim, RRSAgent, NickH, AxelPolleres, SteveH, AndyS, pgearon, LeeF, karl, iv_an_ru, kasei, AlexPassant, sandro, trackbot
14:02:47 <SteveH> LeeF, what's the call?
14:02:53 <LeeF> HTTP RDF Update
14:03:12 <AxelPolleres> Will you join, steve?
14:03:47 <AxelPolleres> sorry, only spotted the missing minutes yesterday ;-)
14:04:34 <SteveH> SteveH has joined #sparql
14:04:50 <AxelPolleres> Zakim, who is on the phone?
14:04:50 <Zakim> On the phone I see NickH, AxelPolleres, LeeF, AndyS, chimezie_
14:05:43 <NickH> I think I need a bit more experience before attempting to scribe
14:05:48 <AxelPolleres> scribe: LeeF
14:05:58 <AxelPolleres> agenda: http://www.w3.org/2009/sparql/wiki/Agenda-2010-06-07
14:06:07 <SteveH> what's the code?
14:06:11 <LeeF> 772775
14:06:27 <Zakim> + +0208439aacc
14:06:36 <SteveH> Zakim, aacc is [Garlik]
14:06:36 <Zakim> +[Garlik]; got it
14:06:57 <SteveH> Zakim, [Garlik] is temporarily me
14:07:00 <Zakim> +SteveH; got it
14:07:41 <LeeF> topic: Base URI for graph=g cases
14:07:49 <AxelPolleres> http://lists.w3.org/Archives/Public/public-rdf-dawg/2010AprJun/0238.html
14:08:22 <AxelPolleres> "In situations where there is no Base URI in the payload and a graph IRI is
14:08:22 <AxelPolleres> embedded, the RDF document that represents [AWWW] the networked RDF
14:08:23 <AxelPolleres> knowledge identified by the embedded graph IRI SHOULD be considered the
14:08:23 <AxelPolleres> retrieval context (5.1.2) [RFC3986].  Thus, the default base URI is the base
14:08:23 <AxelPolleres> URI of that RDF document."
14:09:11 <LeeF> chimezie: (how) can the base URI resolution rules be applied to the HTTP update protocol ?
14:09:28 <AxelPolleres> http://www.w3.org/2009/sparql/docs/http-rdf-update/#base-resolution
14:09:37 <LeeF> .. if you're posting to /endpoint?graph=g what's the base URI?
14:10:51 <LeeF> ... tried to suggest an interpretation that the context of the retrieval is the embedded URI
14:11:43 <chimezie> resolution rules are here: http://www.apps.ietf.org/rfc/rfc3986.html#sec-5.1
14:14:58 <LeeF> My only strong opinion is that we do support a way where graph=g makes g the base URI, but I think we all agree on that
14:15:12 <AxelPolleres> "SHOULD be considered the Base URI of the encapsulating entity"
14:15:43 <AxelPolleres>  leef, yes, I think we just are unsure about wording... 
14:15:59 <AndyS> Like Lee, I care about the outcome.
14:17:55 <chimezie> http://lists.w3.org/Archives/Public/public-rdf-dawg/2010AprJun/0230.html
14:18:21 <chimezie> "I'd like to find a way to make the graph URI the base even if that means 
14:18:21 <chimezie> contorting things a little - after all, this 3rd party service/graph 
14:18:21 <chimezie> naming we are using isn't the primary design space of REST anyway."
14:18:31 <chimezie> "I'd argue that the use of the graph=<abs URI> creates a new URI used to 
14:18:31 <chimezie> retrieve the entity."
14:19:13 <AxelPolleres> ?graph=/y
14:19:14 <AxelPolleres> \
14:19:33 <chimezie> PUT /rdf-graphs/employees?graph=http://otherserver/consultant/56
14:19:34 <chimezie> Host: example.com
14:19:34 <chimezie> <?xml version='1.0' encoding='UTF-8'?>
14:19:34 <chimezie> <rdf:RDF
14:19:34 <chimezie> .... no base named ....
14:19:35 <chimezie> </rdf:RDF>
14:19:55 <chimezie> http://otherserver/consultant/56
14:20:05 <chimezie> http://otherserver/consultant/56
14:20:10 <LeeF> base URI ought to be http://otherserver/consultant/56
14:20:54 <AxelPolleres> What about just accepting Chime's wording plus adding the example?
14:21:28 <NickH> sounds good to me
14:21:31 <SteveH> +1
14:21:34 <AxelPolleres> no objections to the intention...
14:21:36 <AndyS> zakim, who is on the phone?
14:21:36 <Zakim> On the phone I see NickH, AxelPolleres, LeeF, AndyS, chimezie_, SteveH
14:22:10 <AxelPolleres> needs no resuloution.
14:22:56 <AxelPolleres> ACTION: chime to incorporate explaining wording plus example to editor's draft 
14:22:57 <trackbot> Created ACTION-252 - Incorporate explaining wording plus example to editor's draft  [on Chimezie Ogbuji - due 2010-06-14].
14:23:42 <LeeF> topic: "Networked RDF Knowledge"
14:24:11 <LeeF> "Networked RDF knowledge - An information resource identified by a graph IRI and managed by a server that implements this protocol. See [WEBARCH] for further discussion on Resources."
14:24:12 <AxelPolleres> Networked RDF knowledge - An information resource identified by a graph IRI and managed by a server that implements this protocol. See [WEBARCH] for further discussion on Resources.
14:24:56 <LeeF> AxelPolleres: there have been discussions around the term - proposals include RDF data, RDF knowledge, ...
14:25:29 <AxelPolleres> Would "RDF knowledge" work for all?
14:25:53 <LeeF> AndyS: the word "knowledge" in this context doesn't make sense to me 
14:26:16 <LeeF> AndyS: but don't want to hold things up over it
14:26:30 <SteveH> I feel similarly to AndyS
14:26:35 <SteveH> I don't think it's a helpful term
14:27:55 <LeeF> chimezie: original SPARQL not clear about what a graph IRI identifies
14:28:18 <LeeF> ... either identifies something whose characteristics can be transferred over a protocol (vaguely an information resource)
14:28:19 <LeeF> ... or not
14:28:33 <LeeF> ... what the graph IRI represents can be serialized as an RDF document
14:28:44 <LeeF> ... so intuitive what the graph IRI identifies is an IR
14:28:53 <LeeF> s/represents/identifies
14:28:57 <LeeF> s/intuitive/intuitively
14:29:21 <AndyS> "The IRI identifies a resource, and the resource is represented by a  graph (or, more precisely: by a document that serializes a graph). "
14:29:29 <AxelPolleres> RDF Knowledge = IRI identified Document or IRI identifying a resource?
14:30:56 <AxelPolleres> "However, in using a URI in this way, we are not directly identifying an RDF graph but rather the RDF knowledge that is represented by an RDF document, which serializes that graph."
14:31:08 <LeeF> chimezie: this thing needs a name to talk about the protocol model coherently
14:34:33 <LeeF> chimezie: expect to receive scrutiny over this from the TAG
14:34:38 <LeeF> s/over/about
14:35:36 <LeeF> AxelPolleres: maybe we should solicit feedback from the TAG ?
14:36:19 <AxelPolleres> ACTION: chime to change networked RDF knowledge to RDF knowledge
14:36:19 <trackbot> Created ACTION-253 - Change networked RDF knowledge to RDF knowledge [on Chimezie Ogbuji - due 2010-06-14].
14:36:59 <AxelPolleres> http://www.w3.org/2009/sparql/track/issues/49
14:37:49 <LeeF> topic: http-range
14:38:04 <LeeF> chimezie: kjetil wants http-range-14 to be a normative reference 
14:38:14 <LeeF> ... greg shares that feeling
14:38:37 <LeeF> ... My response is that (1) not clear how a REC trac kdocument normatively references a TAG finding
14:38:48 <LeeF> ... (2) http-range-14 meant to address ambiguity about denotation of IRI
14:39:55 <LeeF> ... but there doesn't seem to be an amiguity here to resolve
14:40:05 <LeeF> ... we might get guidance from the TAG here?
14:40:34 <AxelPolleres> we might just point out that "http" resources that respond to a GET request with a 2xx response  used as graph-uris may raise ambiguities?
14:42:12 <AxelPolleres> issue here is twofold... 
14:43:07 <AxelPolleres> for one whether we do/don't want to discourage such URIs as (embedded?) graph URIs, and the second whether how we point to the TAG issue
14:43:08 <LeeF> chimezie: because we say that a graph IRI denotes an IR, it SHOULD get a 200 response
14:43:16 <LeeF> ... unclear if we need it as a normative reference since there's no ambiguity
14:44:22 <AxelPolleres> anyone for discuouraging graph uris that return 200?
14:44:45 <AxelPolleres> -1 with the understanding that warning about possible ambiguities should be enough
14:44:54 <AndyS> most graphs already return 200 (rightly or wrongly)
14:46:19 <AxelPolleres> seems we have agreement about that (-1)
14:47:32 <AxelPolleres> ACTION: Axel to find out whether/how we can refence the TAG issue http://www.w3.org/2001/tag/issues#httpRange-14 in a  rec document with team contacts
14:47:32 <trackbot> Created ACTION-254 - Find out whether/how we can refence the TAG issue http://www.w3.org/2001/tag/issues#httpRange-14 in a  rec document with team contacts [on Axel Polleres - due 2010-06-14].
14:48:14 <AxelPolleres> topic: red box on http-post in Section 5.3 
14:48:16 <AxelPolleres> http://www.w3.org/2009/sparql/docs/http-rdf-update/#http-post
14:48:25 <Zakim> -LeeF
14:49:29 <AxelPolleres> Chime: try to clarify two use cases of POST for creating resources or adding content
14:51:01 <AxelPolleres> ... in order to support that, empty POST to the graphstore shall give you a new resource/iri 
14:51:33 <AndyS> Until this point, "graph store" isn't in the HTTP Update document.
14:53:01 <AxelPolleres> s/graphstore/network-manipulable RDF dataset/
14:54:22 <AxelPolleres> Alternative to Service description would be an extra operation for GET (to get the network-manipulable RDF dataset) 
14:54:36 <AxelPolleres> chime: not sure whether this is the right place...
14:54:55 <AndyS> The terminology has "graph store". My point is that the concept of dataset/graph store is not used except in description.  It's just for the naming.  The operations (except here) never refer to the dataset
14:55:04 <Zakim> -chimezie_
14:55:15 <AxelPolleres> Zakim, who is on the phone?
14:55:15 <Zakim> On the phone I see NickH, AxelPolleres, AndyS, SteveH
14:55:21 <chimezie> sorry about having to leave prematurely
14:55:22 <NickH> sorry I don't have a strong opinion / experience in this
14:56:15 <AxelPolleres> http://www.w3.org/2009/sparql/docs/http-rdf-update/#http-post
14:58:05 <SteveH> Zakim, who's speaking
14:58:05 <Zakim> I don't understand 'who's speaking', SteveH
14:58:09 <SteveH> Zakim, who's speaking?
14:58:19 <Zakim> SteveH, listening for 10 seconds I heard sound from the following: AxelPolleres (9%), AndyS (5%)
14:58:21 <AndyS> I don't see there is an issue.  How do does one find SPARQL query endpoints?
14:58:28 <SteveH> quite
14:59:13 <AndyS> Why?
15:01:17 <AxelPolleres> Andy: Not really clear why/how this is different from finding any document on the Web. 
15:03:50 <AxelPolleres> Seems to be agreement that behaovior is clear (but not what the issue of  the red box really is... shall we just remove it?)
15:04:26 <AxelPolleres> Graph Store - An RDF dataset whose named graphs can be added to or deleted from [SPARQL-UPDATE].
15:04:47 <AxelPolleres> any comments on that?
15:06:21 <AxelPolleres> Andy: why do we need to reference graph store at all?
15:06:49 <AxelPolleres> Axel: is used in Terminology of "Network-manipulable RDF Dataset - A graph store used by an implementation of this protocol whose named RDF graphs can be managed by HTTP operations and their identifiers are either resolvable or can be embedded in the query component of the request URI in a manner described in section 4.2 in this document."
15:08:26 <SteveH> "network-manipulable RDF dataset" is somewhat a synonym of "graph store", no?
15:09:13 <AxelPolleres> not clear why we need a distinction "network-manipulable RDF dataset" and "graphstore"
15:10:38 <AxelPolleres> Axel: network-manipulable RDF dataset has an address, graphstore, doesn't necessarily.
15:11:58 <AxelPolleres> service endpoint for Update is not necessaily equal URI of "network-manipulable RDF dataset" ?
15:12:43 <AxelPolleres> ... network-manipulable RDF dataset seems in that sense more synonymous to service endpoint than to graphstore to me
15:12:50 <AndyS> Surely, service endpoint != dataset URI -- Why not an HTTP Update service?
15:13:28 <AxelPolleres> Andy, you suggest to rename"network-manipulable RDF dataset" to "HTTP Update service"?
15:13:45 <AndyS> Let's wait to discuss this with Chimie so we can understand his concern.
15:14:04 <AxelPolleres> or  (my suggestion) "RDF HTTP Update endpoint"?
15:15:01 <AxelPolleres> needs clarification
15:15:59 <SteveH> not from me
15:16:36 <Zakim> -SteveH
15:17:26 <AxelPolleres> summary: 2 issues left: (i) red box in Section 5.3 , not clear whether it's needed (ii) term "network-manipulable RDF dataset" and distinction from "graph store" and "endpoint" needs clarification
15:17:31 <AxelPolleres> adjourned
15:17:31 <Zakim> -AndyS
15:17:37 <AxelPolleres> thanks all
15:17:42 <Zakim> -AxelPolleres
15:17:49 <AxelPolleres> rrsagent, make records public
15:18:45 <AxelPolleres> rrsagent, make records public
15:18:46 <NickH> AxelPolleres: sorry I am not very useful at the moment - I hope to become more use as I understand the W3C processes and the documents
15:19:02 <AxelPolleres> no problem, nick
15:19:09 <SteveH> SteveH has joined #sparql
15:19:45 <AxelPolleres> best starting point is reading all docs carefully and comment, as you did already in some cases.
15:20:27 <AxelPolleres> ... different people are swapped in on differnt topics, normal.
15:20:39 <Zakim> -NickH
15:20:40 <Zakim> Team_(sparql)13:57Z has ended
15:20:41 <Zakim> Attendees were NickH, +03539149aaaa, AxelPolleres, LeeF, AndyS, chimezie_, +0208439aacc, SteveH
15:21:19 <NickH> ok
15:27:54 <AxelPolleres> AxelPolleres has left #sparql