<sandro> Guest: Alan (alanr) Ruttenberg
14:30:24 <RRSAgent> logging to http://www.w3.org/2012/08/22-rdf-wg-irc
RRSAgent IRC Bot: logging to http://www.w3.org/2012/08/22-rdf-wg-irc ←
14:30:29 <trackbot> Meeting: RDF Working Group Teleconference
14:30:29 <trackbot> Date: 22 August 2012
14:30:34 <ivan> Chair: Ivan
14:31:25 <ivan> Agenda: http://www.w3.org/2011/rdf-wg/wiki/Meetings:Telecon2012.08.22
14:47:56 <ivan> Regrets: Arnaud, Yves, Scott, Zhe
14:56:01 <ivan> Scribe: Thomas Baker
(No events recorded for 25 minutes)
(Scribe set to Thomas Baker)
14:56:18 <ivan> scribenick: tbaker
15:04:29 <ivan> Topic: minutes of last meeting
(No events recorded for 8 minutes)
15:04:44 <ivan> zakim, aaaa is AlexHall
Ivan Herman: zakim, aaaa is AlexHall ←
15:04:47 <MacTed> Zakim, [OpenLink] is temporarily me
Ted Thibodeau: Zakim, [OpenLink] is temporarily me ←
15:04:49 <MacTed> Zakim, mute me
Ted Thibodeau: Zakim, mute me ←
15:04:57 <ivan> -> http://www.w3.org/2011/rdf-wg/meeting/2012-08-08 last meeting's minutes
Ivan Herman: -> http://www.w3.org/2011/rdf-wg/meeting/2012-08-08 last meeting's minutes ←
15:05:19 <PatH> I'll be on the call in a few mins
Patrick Hayes: I'll be on the call in a few mins ←
15:05:22 <tbaker> RESOLVED: accepted last week's minutes http://www.w3.org/2011/rdf-wg/meeting/2012-08-08
RESOLVED: accepted last week's minutes http://www.w3.org/2011/rdf-wg/meeting/2012-08-08 ←
15:05:31 <ivan> Topic: review of actions
15:05:42 <ivan> zakim, aabb is Souri
Ivan Herman: zakim, aabb is Souri ←
15:06:28 <tbaker> Ivan: See one action from Pat - discussion of Provenance - he's not yet on call. Propose to postpone - he needs resolution on draft identification issue before we can proceed.
Ivan Herman: See one action from Pat - discussion of Provenance - he's not yet on call. Propose to postpone - he needs resolution on draft identification issue before we can proceed. ←
15:06:33 <ivan> -> http://www.w3.org/2011/rdf-wg/track/actions/overdue Overdue actions
Ivan Herman: -> http://www.w3.org/2011/rdf-wg/track/actions/overdue Overdue actions ←
15:06:36 <tbaker> ... Bunch of overdue actions:
... Bunch of overdue actions: ←
15:07:15 <tbaker> ... Some are a few months old... Sandro: one from Sept 2011 - still open?
... Some are a few months old... Sandro: one from Sept 2011 - still open? ←
15:07:44 <tbaker> ... ACTION-82 and ACTION-98 still pending.
... ACTION-82 and ACTION-98 still pending. ←
15:08:08 <tbaker> ... ACTION-100: ask editors of SPARQL...
... ACTION-100: ask editors of SPARQL... ←
15:08:21 <tbaker> Sandro: never quite understood that.
Sandro Hawke: never quite understood that. ←
15:08:25 <sandro> close action-100
Sandro Hawke: close ACTION-100 ←
15:08:25 <trackbot> ACTION-100 Ask editors of SPARQL Entailment Regimes what they'd suggest RDF specs says about their work. closed
Trackbot IRC Bot: ACTION-100 Ask editors of SPARQL Entailment Regimes what they'd suggest RDF specs says about their work. closed ←
15:09:02 <tbaker> Ivan: Pat, action on your for past year to modify RDF semantics... (ACTION-120)
Ivan Herman: Pat, action on your for past year to modify RDF semantics... (ACTION-120) ←
15:09:04 <sandro> action-120?
15:09:04 <trackbot> ACTION-120 -- Patrick Hayes to modify RDF Semantics appropriately to hard-code the class extension of rdf:langString to the set of all pairs of strings and language tags -- due 2011-11-16 -- OPEN
Trackbot IRC Bot: ACTION-120 -- Patrick Hayes to modify RDF Semantics appropriately to hard-code the class extension of rdf:langString to the set of all pairs of strings and language tags -- due 2011-11-16 -- OPEN ←
15:09:04 <trackbot> http://www.w3.org/2011/rdf-wg/track/actions/120
Trackbot IRC Bot: http://www.w3.org/2011/rdf-wg/track/actions/120 ←
15:09:25 <sandro> action-140?
15:09:25 <trackbot> ACTION-140 -- Patrick Hayes to review XSD in RDF and OWL from semantics perspective -- due 2012-02-08 -- OPEN
Trackbot IRC Bot: ACTION-140 -- Patrick Hayes to review XSD in RDF and OWL from semantics perspective -- due 2012-02-08 -- OPEN ←
15:09:25 <trackbot> http://www.w3.org/2011/rdf-wg/track/actions/140
Trackbot IRC Bot: http://www.w3.org/2011/rdf-wg/track/actions/140 ←
15:09:45 <tbaker> ... Propose to close ACTION-140.
... Propose to close ACTION-140. ←
15:09:45 <gavinc> close action-140
Gavin Carothers: close ACTION-140 ←
15:09:45 <trackbot> ACTION-140 Review XSD in RDF and OWL from semantics perspective closed
Trackbot IRC Bot: ACTION-140 Review XSD in RDF and OWL from semantics perspective closed ←
15:10:11 <tbaker> ... Pat, ACTION-166
... Pat, ACTION-166 ←
15:10:27 <tbaker> Pat: Leave ACTION-166 and ACTION-170 open.
Patrick Hayes: Leave ACTION-166 and ACTION-170 open. ←
15:10:48 <tbaker> Ivan: ACTION-179 for Sandro - what was that?
Ivan Herman: ACTION-179 for Sandro - what was that? ←
15:11:23 <tbaker> Sandro: We included test cases in namespace. Waiting for Ian to return from vacation.
Sandro Hawke: We included test cases in namespace. Waiting for Ian to return from vacation. ←
15:11:46 <tbaker> Ivan: Do we want to leave it open until inverse-property sugar issue is closed?
Ivan Herman: Do we want to leave it open until inverse-property sugar issue is closed? ←
15:11:57 <ivan> close action-180
Ivan Herman: close ACTION-180 ←
15:11:57 <trackbot> ACTION-180 Create a proposal for inverse property syntax in Turtle closed
Trackbot IRC Bot: ACTION-180 Create a proposal for inverse property syntax in Turtle closed ←
15:12:13 <ivan> close action-181
Ivan Herman: close ACTION-181 ←
15:12:13 <trackbot> ACTION-181 Start wiki page for F2F closed
Trackbot IRC Bot: ACTION-181 Start wiki page for F2F closed ←
15:12:25 <ivan> Topic: F2F meeting
15:12:39 <ivan> -> http://www.w3.org/2011/rdf-wg/wiki/FTF3 Wiki page for f2f
Ivan Herman: -> http://www.w3.org/2011/rdf-wg/wiki/FTF3 Wiki page for f2f ←
15:12:58 <PatH> zakim, mute me
Patrick Hayes: zakim, mute me ←
15:13:04 <tbaker> Ivan: Urge you to sign up for right category - whether you intend to come, or come in remotely.
Ivan Herman: Urge you to sign up for right category - whether you intend to come, or come in remotely. ←
15:13:06 <gavinc> https://www.w3.org/2011/rdf-wg/track/issues/95
Gavin Carothers: https://www.w3.org/2011/rdf-wg/track/issues/95 ←
15:13:17 <tbaker> ... Sandro, do we have way to handle remote participation?
... Sandro, do we have way to handle remote participation? ←
15:13:22 <gavinc> Open ISSUE-95
Gavin Carothers: Open ISSUE-95 ←
15:13:31 <tbaker> ... We will have a phone, hardware, and line?
... We will have a phone, hardware, and line? ←
15:13:33 <gavinc> I guess that doesn't work from IRC.
Gavin Carothers: I guess that doesn't work from IRC. ←
15:13:43 <tbaker> Sandro: I think so, but haven't confirmed.
Sandro Hawke: I think so, but haven't confirmed. ←
15:13:53 <tbaker> Ivan: Five people already want to come in remotely.
Ivan Herman: Five people already want to come in remotely. ←
15:14:08 <tbaker> ACTION: Sandro to check on hardware for meeting.
ACTION: Sandro to check on hardware for meeting. ←
15:14:08 <trackbot> Created ACTION-182 - Check on hardware for meeting. [on Sandro Hawke - due 2012-08-29].
Trackbot IRC Bot: Created ACTION-182 - Check on hardware for meeting. [on Sandro Hawke - due 2012-08-29]. ←
15:14:30 <ivan> Topic: Next meeting
15:14:45 <tbaker> Ivan: Starting two weeks from now - 5 September - vacations are over.
Ivan Herman: Starting two weeks from now - 5 September - vacations are over. ←
15:16:08 <tbaker> ... We're done with admin actions.
... We're done with admin actions. ←
15:16:09 <ivan> Topic: Graph identification
15:16:22 <tbaker> Ivan: Just for the record: http://www.w3.org/2012/08/RDFNG.html proposal document.
Ivan Herman: Just for the record: http://www.w3.org/2012/08/RDFNG.html proposal document. ←
15:17:04 <tbaker> ... You all got this mail. Probably nobody is completely happy. We try to find consensus at some level and move out of current deadlock.
... You all got this mail. Probably nobody is completely happy. We try to find consensus at some level and move out of current deadlock. ←
15:17:37 <tbaker> ... Three major areas. David tried to get agreement on fundamentals. If accepted, a bunch of details. Gives us guidelines.
... Three major areas. David tried to get agreement on fundamentals. If accepted, a bunch of details. Gives us guidelines. ←
15:17:57 <tbaker> ... Proposal to focus on 3 issues first: 1) terminology around NGs that would end up in Concepts,
... Proposal to focus on 3 issues first: 1) terminology around NGs that would end up in Concepts, ←
15:18:09 <tbaker> ... 2) What we do with Semantics. Some discussion with Antoine, Sandro, etc.
... 2) What we do with Semantics. Some discussion with Antoine, Sandro, etc. ←
15:18:23 <tbaker> ... 3) General guideline for TRIX syntax for NGs.
... 3) General guideline for TRIX syntax for NGs. ←
15:18:41 <tbaker> ... Do you all agree, or propose something radically different?
... Do you all agree, or propose something radically different? ←
15:19:01 <tbaker> ... Will take silence as agreement.
... Will take silence as agreement. ←
15:19:10 <tbaker> ... Start with things that will end up in Concepts.
... Start with things that will end up in Concepts. ←
15:19:37 <alanr> +1
Alan Ruttenberg: +1 ←
15:19:46 <tbaker> Pat: Would not start with terminology, then semantics - would reverse the order.
Patrick Hayes: Would not start with terminology, then semantics - would reverse the order. ←
15:19:56 <MacTed> +1 overall to that doc
Ted Thibodeau: +1 overall to that doc ←
15:20:06 <tbaker> Sandro: It was that we would decide to decide terminology.
Sandro Hawke: It was that we would decide to decide terminology. ←
15:20:37 <tbaker> Ivan: Not the specific terms to use. We try to identify the missing bit of terminology. Most of the things are coming from SPARQL documents.
Ivan Herman: Not the specific terms to use. We try to identify the missing bit of terminology. Most of the things are coming from SPARQL documents. ←
15:21:20 <alanr> can there be a summary of the points of contention?
Alan Ruttenberg: can there be a summary of the points of contention? ←
15:21:22 <tbaker> ... In that document, we coined RDF Spaces, or GBox (coined ages ago) - by trying to find the right term for that - don't want to go there now - we have some sort of symmetry of concepts that could go into Concepts.
... In that document, we coined RDF Spaces, or GBox (coined ages ago) - by trying to find the right term for that - don't want to go there now - we have some sort of symmetry of concepts that could go into Concepts. ←
15:21:39 <tbaker> ... Comments on that issue?
... Comments on that issue? ←
15:21:43 <MacTed> q?
Ted Thibodeau: q? ←
15:21:47 <alanr> 1+
Alan Ruttenberg: 1+ ←
15:21:49 <alanr> q+
Alan Ruttenberg: q+ ←
15:21:52 <cygri> q+
Richard Cyganiak: q+ ←
15:22:00 <ivan> ack alanr
Ivan Herman: ack alanr ←
15:22:29 <tbaker> Alan: Coming in to see if I can help. Could someone summarize history of points of contention?
Alan Ruttenberg: Coming in to see if I can help. Could someone summarize history of points of contention? ←
15:22:47 <tbaker> Ivan: "Short" overview of past 18 months would be complicated...
Ivan Herman: "Short" overview of past 18 months would be complicated... ←
15:23:07 <MacTed> Zakim, unmute me
Ted Thibodeau: Zakim, unmute me ←
15:23:13 <gavinc> Everyone disagrees, but ends up not disagreeing and we end up talking about g-boxes a lot.
Gavin Carothers: Everyone disagrees, but ends up not disagreeing and we end up talking about g-boxes a lot. ←
15:23:20 <tbaker> ... Volunteers for 2-minute overview?
... Volunteers for 2-minute overview? ←
15:23:48 <tbaker> Pat: I'll give it a shot... SPARQL has provided constructions - graphs with URIs attached - and we have been debating what this means in RDF terms.
Patrick Hayes: I'll give it a shot... SPARQL has provided constructions - graphs with URIs attached - and we have been debating what this means in RDF terms. ←
15:24:03 <tbaker> ... Basic issues: whether graph names really name the graph, or name something else.
... Basic issues: whether graph names really name the graph, or name something else. ←
15:24:15 <tbaker> ... If they do name something, what do they name?
... If they do name something, what do they name? ←
15:24:25 <tbaker> ... A flavor of the issues...
... A flavor of the issues... ←
15:24:43 <gavinc> Zakim, mute me
Gavin Carothers: Zakim, mute me ←
15:24:50 <tbaker> ... This bundle of issues got mixed up with notion that people think of graphs, often, as something that is mutable.
... This bundle of issues got mixed up with notion that people think of graphs, often, as something that is mutable. ←
15:25:39 <ivan> ack cygri
Ivan Herman: ack cygri ←
15:25:47 <tbaker> ... [Pat lists the over 4-5 alternative suggestions for what a graph URI could denote]
... [Pat lists the over 4-5 alternative suggestions for what a graph URI could denote] ←
15:26:15 <tbaker> Richard: ONe of the reasons why this graph discussion is difficult: we don't really have agreement on the big-picture goal of this effort.
Richard Cyganiak: ONe of the reasons why this graph discussion is difficult: we don't really have agreement on the big-picture goal of this effort. ←
15:26:16 <PatH> +1 to richard
Patrick Hayes: +1 to richard ←
15:27:30 <tbaker> ... At the end of the day, we don't _have_ to do anything. SPARQL has already standardized solutions to the problems we are trying to solve - pretty good. So why is RDFWG dealing with this? Yes, in charter, but what does it mean for us to be successful in this work? Do we create point of reference for multigraph work? Use cases we want to address?
... At the end of the day, we don't _have_ to do anything. SPARQL has already standardized solutions to the problems we are trying to solve - pretty good. So why is RDFWG dealing with this? Yes, in charter, but what does it mean for us to be successful in this work? Do we create point of reference for multigraph work? Use cases we want to address? ←
15:27:56 <ivan> q?
Ivan Herman: q? ←
15:27:58 <tbaker> ... Different opinions on this. Difficult to know what we need to do to be successful.
... Different opinions on this. Difficult to know what we need to do to be successful. ←
15:28:53 <ivan> q+
Ivan Herman: q+ ←
15:28:55 <tbaker> Sandro: Think - second of Richard's options - should define things such that more use cases become tractable. In Use Case document, federated phone book. Many people want to express "change over time"
Sandro Hawke: Think - second of Richard's options - should define things such that more use cases become tractable. In Use Case document, federated phone book. Many people want to express "change over time" ←
15:29:35 <tbaker> ... Someone could come along and define that vocabulary. Terminology and model for how to work with multiple graphs in interoperable way. Easy to come up with stand-alone solution. Challenge: exchange with others.
... Someone could come along and define that vocabulary. Terminology and model for how to work with multiple graphs in interoperable way. Easy to come up with stand-alone solution. Challenge: exchange with others. ←
15:29:47 <tbaker> Richard: What is missing from what SPARQL already standardizes?
Richard Cyganiak: What is missing from what SPARQL already standardizes? ←
15:30:12 <tbaker> Sandro: The metadata - a way to hook URIs - this thing has this property - currently not clear what you are talking about.
Sandro Hawke: The metadata - a way to hook URIs - this thing has this property - currently not clear what you are talking about. ←
15:30:14 <PatH> q+
Patrick Hayes: q+ ←
15:30:20 <ivan> ack ivan
Ivan Herman: ack ivan ←
15:30:24 <alanr> Classes have extensions. RDF Graphs have things that look at lot like extensions. Classes can be closed. RDF Graphs sees to want to be either open or closed. I wonder whether a) an extension to the ref semantics that adds a graph extension in addition to a property and class extension. b) Any of the use cases for using the graph name to mean other than the extension can not be handled by (a) and the fact that the domain of discourse of RDF is ref:Resource = any
Alan Ruttenberg: Classes have extensions. RDF Graphs have things that look at lot like extensions. Classes can be closed. RDF Graphs sees to want to be either open or closed. I wonder whether a) an extension to the ref semantics that adds a graph extension in addition to a property and class extension. b) Any of the use cases for using the graph name to mean other than the extension can not be handled by (a) and the fact that the domain of discourse of RDF is ref:Resource = any ←
15:30:25 <tbaker> Richard: So even semantics to use [] in default graph.
Richard Cyganiak: So even semantics to use [] in default graph. ←
15:30:35 <alanr> q+ to discuss my comment
Alan Ruttenberg: q+ to discuss my comment ←
15:31:15 <tbaker> Ivan: Also think - agree with Richard that most things we need have been defined by SPARQL. That said, need place clearly referenceable for this, and only this, topic, that is not bounced to the query language.
Ivan Herman: Also think - agree with Richard that most things we need have been defined by SPARQL. That said, need place clearly referenceable for this, and only this, topic, that is not bounced to the query language. ←
15:31:27 <tbaker> ... Will not be clear to people what this means.
... Will not be clear to people what this means. ←
15:31:43 <AZ> q+
Antoine Zimmermann: q+ ←
15:32:01 <ivan> zakim, aacc is dwood
Ivan Herman: zakim, aacc is dwood ←
15:32:02 <ivan> \
Ivan Herman: \ ←
15:32:07 <tbaker> ... Reason why SPARQL terminology would be taken into Concept document - to be in line with SPARQL, but also to extract and put somewhere that people can cite.
... Reason why SPARQL terminology would be taken into Concept document - to be in line with SPARQL, but also to extract and put somewhere that people can cite. ←
15:32:08 <ivan> ack PatH
Ivan Herman: ack PatH ←
15:32:28 <tbaker> Pat: Disagree. Don't think SPARQL has indeed defined these constructions.
Patrick Hayes: Disagree. Don't think SPARQL has indeed defined these constructions. ←
15:32:28 <ericP> alan, one issue is whether our not my graph <foo> corresponds to your graph <foo>
Eric Prud'hommeaux: alan, one issue is whether our not my graph <foo> corresponds to your graph <foo> ←
15:32:52 <tbaker> ... To amplify what Sandro says: Difficult to come up with framework that can be extended for notions of time, etc.
... To amplify what Sandro says: Difficult to come up with framework that can be extended for notions of time, etc. ←
15:32:53 <alanr> it does, by the approach I propose. That would be consistent with use of all other URIs
Alan Ruttenberg: it does, by the approach I propose. That would be consistent with use of all other URIs ←
15:33:01 <alanr> consistency is good
Alan Ruttenberg: consistency is good ←
15:33:15 <ivan> q?
Ivan Herman: q? ←
15:33:19 <ivan> ack alanr
Ivan Herman: ack alanr ←
15:33:22 <tbaker> ... People using RDF at edges - BBC, etc - important to clarify this big issue to help these people.
... People using RDF at edges - BBC, etc - important to clarify this big issue to help these people. ←
15:33:23 <alanr> tbaker: time needs to be its own project - very involved
Thomas Baker: time needs to be its own project - very involved [ Scribe Assist by Alan Ruttenberg ] ←
15:33:29 <SteveH> FWIW, I've not seen this being discussed in the real world
Steve Harris: FWIW, I've not seen this being discussed in the real world ←
15:33:31 <MacTed> +1 AndyS
Ted Thibodeau: +1 PatH ←
15:34:13 <PatH> zakim, mute me
Patrick Hayes: zakim, mute me ←
15:34:32 <tbaker> Alan: So shouldn't be a competition, but ability to cover cases - want to re-use as much as possible. In semantic extensions for RDF - class extensions in RDFS - a URI can have several different "attachments". One of these should be for RDF graph. Has this been discussed?
Alan Ruttenberg: So shouldn't be a competition, but ability to cover cases - want to re-use as much as possible. In semantic extensions for RDF - class extensions in RDFS - a URI can have several different "attachments". One of these should be for RDF graph. Has this been discussed? ←
15:35:03 <tbaker> ... Need basics: "mutable" sets, document-like thinks. Something like class extension - "semantic extension"?
... Need basics: "mutable" sets, document-like thinks. Something like class extension - "semantic extension"? ←
15:35:30 <AndyS> agenda?
Andy Seaborne: agenda? ←
15:35:39 <PatH> graphs can be in the rdf universe, so there can be classes of them.
Patrick Hayes: graphs can be in the rdf universe, so there can be classes of them. ←
15:35:43 <tbaker> ... If you have an RDF resource that can mean essentially anything - if it has a graph extension - this would give you possibility of extending graphs to additional, more restrictive things.
... If you have an RDF resource that can mean essentially anything - if it has a graph extension - this would give you possibility of extending graphs to additional, more restrictive things. ←
15:35:44 <ivan> q+
Ivan Herman: q+ ←
15:35:48 <cygri> q+
Richard Cyganiak: q+ ←
15:35:51 <ivan> ack AZ
Ivan Herman: ack AZ ←
15:35:52 <PatH> is that enough for you?
Patrick Hayes: is that enough for you? ←
15:36:22 <MacTed> s/+1 AndyS/+1 PatH/
15:36:23 <MacTed> :-)
Ted Thibodeau: :-) ←
15:36:39 <ivan> q-
Ivan Herman: q- ←
15:36:56 <tbaker> Antoine: Agree with Pat when he says lots of things not defined by SPARQL. Doesn't explain what conclusions you can draw from dataset. We know what to draw from one graph, but not from a pair of Name-Graph. This is needed (in answer to Richard).
Antoine Zimmermann: Agree with Pat when he says lots of things not defined by SPARQL. Doesn't explain what conclusions you can draw from dataset. We know what to draw from one graph, but not from a pair of Name-Graph. This is needed (in answer to Richard). ←
15:37:00 <ivan> ack cygri
Ivan Herman: ack cygri ←
15:37:05 <alanr> I don't see the need for "pair" any more than we need "pair" for describing the URI, resource it refers to
Alan Ruttenberg: I don't see the need for "pair" any more than we need "pair" for describing the URI, resource it refers to ←
15:37:14 <alanr> there's a name, and then there's a thing that it names
Alan Ruttenberg: there's a name, and then there's a thing that it names ←
15:37:19 <alanr> that's the basis of RDF
Alan Ruttenberg: that's the basis of RDF ←
15:37:34 <PatH> +1 alanr
Patrick Hayes: +1 alanr ←
15:38:09 <tbaker> Ted: What Alan said re: basics - agree. We need mutable container and immutable set which might be held in a container - those basics are in the proposed document. Why do we have to re-hash instead of focusing on proposed document?
Ted Thibodeau: What Alan said re: basics - agree. We need mutable container and immutable set which might be held in a container - those basics are in the proposed document. Why do we have to re-hash instead of focusing on proposed document? ←
15:38:16 <PatH> lets do that, indeed.
Patrick Hayes: lets do that, indeed. ←
15:38:22 <alanr> pat: does the idea of a semantic extension that gives a resource a graph extension work?
Patrick Hayes: does the idea of a semantic extension that gives a resource a graph extension work? [ Scribe Assist by Alan Ruttenberg ] ←
15:38:23 <tbaker> Ivan: Lost Richard?
Ivan Herman: Lost Richard? ←
15:39:02 <tbaker> ... Agree with Ted. Feel that document contains what we can agree upon now. Fills in one hole - the mutable Something.
... Agree with Ted. Feel that document contains what we can agree upon now. Fills in one hole - the mutable Something. ←
15:39:02 <PatH> alanr: maybe but it seems like semantic overkill.
Alan Ruttenberg: maybe but it seems like semantic overkill. [ Scribe Assist by Patrick Hayes ] ←
15:39:12 <alanr> document will do as a name - that's what is used in other contexts
Alan Ruttenberg: document will do as a name - that's what is used in other contexts ←
15:39:30 <tbaker> ... Would appreciate agreement that this is the right direction?
... Would appreciate agreement that this is the right direction? ←
15:39:39 <alanr> compared to the semantic onslaught on graphs it seems relatively easy ;-)
Alan Ruttenberg: compared to the semantic onslaught on graphs it seems relatively easy ;-) ←
15:39:47 <sandro> q?
Sandro Hawke: q? ←
15:39:55 <ivan> PROPOSED: The WG agrees to close the loop on RDF terminology, reflecting the mutability/non mutability issue as also raised by the SPARQL 1.1. What we mean by "closing" is reflected in the symmetry of Figure 1 in the RDF Graph Identification proposal document.
PROPOSED: The WG agrees to close the loop on RDF terminology, reflecting the mutability/non mutability issue as also raised by the SPARQL 1.1. What we mean by "closing" is reflected in the symmetry of Figure 1 in the RDF Graph Identification proposal document. ←
15:39:55 <tbaker> ... Will put in what David wrote...
... Will put in what David wrote... ←
15:40:11 <alanr> w.r.t. terminology, there are objectional uses, e.g. "dataset"
Alan Ruttenberg: w.r.t. terminology, there are objectional uses, e.g. "dataset" ←
15:40:18 <alanr> which means a lot of things
Alan Ruttenberg: which means a lot of things ←
15:40:21 <tbaker> ... Emphasizing that the terminology used in that section is not final.
... Emphasizing that the terminology used in that section is not final. ←
15:40:39 <tbaker> Sandro: So we will find a way to talk about GBox and GSnap.
Sandro Hawke: So we will find a way to talk about GBox and GSnap. ←
15:40:42 <davidwood> Right, should remember our consensus where it exists :)
David Wood: Right, should remember our consensus where it exists :) ←
15:40:46 <alanr> sets are not mutable
Alan Ruttenberg: sets are not mutable ←
15:40:53 <alanr> that's that
Alan Ruttenberg: that's that ←
15:40:57 <PatH> I think we all agree on this diagram when the labels are erased :-)
Patrick Hayes: I think we all agree on this diagram when the labels are erased :-) ←
15:40:59 <alanr> mathematics defines this
Alan Ruttenberg: mathematics defines this ←
15:41:02 <gavinc> It's just semantics!
Gavin Carothers: It's just semantics! ←
15:41:14 <alanr> (I don't like the "pair" business)
Alan Ruttenberg: (I don't like the "pair" business) ←
15:41:25 <alanr> that shouldn't bet there imo
Alan Ruttenberg: that shouldn't bet there imo ←
15:41:27 <davidwood> Alanr, we have discussed this to death and is why we have the current understanding of mutable and immutable terms.
David Wood: Alanr, we have discussed this to death and is why we have the current understanding of mutable and immutable terms. ←
15:41:34 <tbaker> Ivan: Straw poll on the proposal?
Ivan Herman: Straw poll on the proposal? ←
15:41:38 <ivan> +1
Ivan Herman: +1 ←
15:41:40 <MacTed> +1
Ted Thibodeau: +1 ←
15:41:42 <AndyS> +1
Andy Seaborne: +1 ←
15:41:42 <alanr> david, discussed what?
Alan Ruttenberg: david, discussed what? ←
15:41:43 <tbaker> Thomas Baker: +1
Thomas Baker: +1 ←
15:41:46 <davidwood> +1
David Wood: +1 ←
15:41:47 <cgreer> +1
Charles Greer: +1 ←
15:41:48 <sandro> +1 Sure, why not
Sandro Hawke: +1 Sure, why not ←
15:41:50 <PatH> +?
Patrick Hayes: +? ←
15:41:52 <gkellogg> +1
Gregg Kellogg: +1 ←
15:41:53 <Souri> +1
Souripriya Das: +1 ←
15:41:56 <AZ> +1 to section Concepts at least
Antoine Zimmermann: +1 to section Concepts at least ←
15:42:03 <gavinc> +1 to uh, whatever the proposal is
Gavin Carothers: +1 to uh, whatever the proposal is ←
15:42:07 <davidwood> alanr, we all know that math sets are immutable.
David Wood: alanr, we all know that math sets are immutable. ←
15:42:16 <SteveH> +1
Steve Harris: +1 ←
15:42:18 <PatH> +1
Patrick Hayes: +1 ←
15:42:21 <LeeF> +1
Lee Feigenbaum: +1 ←
15:42:28 <AlexHall> +1
15:42:32 <pchampin_> +1
15:42:35 <cygri> -0.5
Richard Cyganiak: -0.5 ←
15:42:39 <tbaker> Ivan: Guideline on what we discuss.
Ivan Herman: Guideline on what we discuss. ←
15:43:11 <tbaker> Richard: Back now. I don't understand the proposal.
Richard Cyganiak: Back now. I don't understand the proposal. ←
15:43:19 <alanr> not sure why datasets are just not classes of rdf graph
Alan Ruttenberg: not sure why datasets are just not classes of rdf graph ←
15:43:20 <tbaker> ... What is being proposed?
... What is being proposed? ←
15:43:33 <MacTed> this is more straw poll than proposal, is it not?
Ted Thibodeau: this is more straw poll than proposal, is it not? ←
15:43:35 <tbaker> Sandro: We will use GBox and GSnap for now. Reaffirming.
Sandro Hawke: We will use GBox and GSnap for now. Reaffirming. ←
15:43:57 <davidwood> PatH, I'm glad to hear that we all agree on the diagram modulo the terms.
David Wood: PatH, I'm glad to hear that we all agree on the diagram modulo the terms. ←
15:44:04 <alanr> eric: for an outsider, completely confusing
Eric Prud'hommeaux: for an outsider, completely confusing [ Scribe Assist by Alan Ruttenberg ] ←
15:44:10 <tbaker> Pat: Could Sandro number nodes in that document? We could cite by number...
Patrick Hayes: Could Sandro number nodes in that document? We could cite by number... ←
15:44:43 <sandro> sandro: that's what gbox/gsnap are.
Sandro Hawke: that's what gbox/gsnap are. [ Scribe Assist by Sandro Hawke ] ←
15:44:45 <sandro> pat: fair enough
Patrick Hayes: fair enough [ Scribe Assist by Sandro Hawke ] ←
15:45:32 <tbaker> Ivan: More to that, to be fair. One year ago, we invented new terms only when they did not clearly exist in SPARQL. That document: 90% SPARQL + only one term not defined and used by SPARQL. If we could find a proper English term for what we are calling RDF Spaces, we could close this and move on.
Ivan Herman: More to that, to be fair. One year ago, we invented new terms only when they did not clearly exist in SPARQL. That document: 90% SPARQL + only one term not defined and used by SPARQL. If we could find a proper English term for what we are calling RDF Spaces, we could close this and move on. ←
15:45:45 <alanr> gavinc +1
Alan Ruttenberg: gavinc +1 ←
15:46:09 <tbaker> Sandro: No. Two problems: the term we agree on. But also the problem that the world uses terminology inconsistently. E.g., "RDF Graph".
Sandro Hawke: No. Two problems: the term we agree on. But also the problem that the world uses terminology inconsistently. E.g., "RDF Graph". ←
15:46:16 <PatH> lets not go there now.
Patrick Hayes: lets not go there now. ←
15:46:19 <alanr> odd to be writing a standard for people who won't read standards to figure out what technical terms mean
Alan Ruttenberg: odd to be writing a standard for people who won't read standards to figure out what technical terms mean ←
15:46:26 <tbaker> Ivan: But we can't go back and tell SPARQL they need to re-write.
Ivan Herman: But we can't go back and tell SPARQL they need to re-write. ←
15:47:05 <tbaker> Ted: No way to dodge ongoing confusing because terms used in ambiguous ways by alot of people. So that group uses terminology in an obsolete fashion.
Ted Thibodeau: No way to dodge ongoing confusing because terms used in ambiguous ways by alot of people. So that group uses terminology in an obsolete fashion. ←
15:47:14 <alanr> q+
Alan Ruttenberg: q+ ←
15:47:20 <tbaker> Ivan: So you want to come up with terms different from those used for a long time?
Ivan Herman: So you want to come up with terms different from those used for a long time? ←
15:47:21 <alanr> q-
Alan Ruttenberg: q- ←
15:47:29 <PatH> q-
Patrick Hayes: q- ←
15:47:40 <AndyS> It's not the SPARQL-WG - it's the community. SPARQL 1.0 followed community. It will continue. As PatH said "be loose about it" (can't remember the exact phrase)
Andy Seaborne: It's not the SPARQL-WG - it's the community. SPARQL 1.0 followed community. It will continue. As PatH said "be loose about it" (can't remember the exact phrase) ←
15:47:41 <alanr> q+ to proposed minting URIs, then creating definitions, then assigning terms.
Alan Ruttenberg: q+ to proposed minting URIs, then creating definitions, then assigning terms. ←
15:48:08 <tbaker> Ted: Only terms we have used consistently: GBox and GSnap. Every term we come up with that incorporates the word graph maintains confusing because it has so many meanings. Leads to interoperability failure.
Ted Thibodeau: Only terms we have used consistently: GBox and GSnap. Every term we come up with that incorporates the word graph maintains confusing because it has so many meanings. Leads to interoperability failure. ←
15:48:13 <AZ> I don't agree: can you point to a place where "RDF Graph" is misused in the last 6 months in our WG?
Antoine Zimmermann: I don't agree: can you point to a place where "RDF Graph" is misused in the last 6 months in our WG? ←
15:48:21 <PatH> Im beginning to understand why Moses had a bad temper.
Patrick Hayes: Im beginning to understand why Moses had a bad temper. ←
15:49:14 <ericP> the gbox /gsnap terms are hard to improve upon
Eric Prud'hommeaux: the gbox /gsnap terms are hard to improve upon ←
15:49:14 <davidwood> "RDF Graph" is defined in RDF Concepts. We could change that, but I don't see the point. Someone will object to any term. At some point, we just need to adopt a set of terms and use them consistently.
David Wood: "RDF Graph" is defined in RDF Concepts. We could change that, but I don't see the point. Someone will object to any term. At some point, we just need to adopt a set of terms and use them consistently. ←
15:49:29 <tbaker> Andy: My point: think we're using SPARQL WG as symbol for "general community". Even SPARQL 1.0 was reacting to the community. "Graph" will be used loosely - will not change.
Andy Seaborne: My point: think we're using SPARQL WG as symbol for "general community". Even SPARQL 1.0 was reacting to the community. "Graph" will be used loosely - will not change. ←
15:49:33 <gavinc> SO?
Gavin Carothers: SO? ←
15:49:40 <cygri> q+ to ask whether fixing use of terminology is a goal of this WG
Richard Cyganiak: q+ to ask whether fixing use of terminology is a goal of this WG ←
15:49:41 <tbaker> Y: Except RDF graph is used inconsistency too.
Yves Raimond: Except RDF graph is used inconsistency too. ←
15:49:43 <ericP> just need the 3rd term for the grsph label
Eric Prud'hommeaux: just need the 3rd term for the grsph label ←
15:49:44 <ivan> ack alanr
Ivan Herman: ack alanr ←
15:49:44 <Zakim> alanr, you wanted to proposed minting URIs, then creating definitions, then assigning terms.
Zakim IRC Bot: alanr, you wanted to proposed minting URIs, then creating definitions, then assigning terms. ←
15:49:50 <Zakim> sandro, listening for 10 seconds I heard sound from the following: AndyS (25%), MacTed (28%), Alan_Ruttenberg (42%), Ivan (50%)
Zakim IRC Bot: sandro, listening for 10 seconds I heard sound from the following: AndyS (25%), MacTed (28%), Alan_Ruttenberg (42%), Ivan (50%) ←
15:50:10 <davidwood> We should *not* borrow trouble by pretending that we know who in reader space might find a consistent term confusing.
David Wood: We should *not* borrow trouble by pretending that we know who in reader space might find a consistent term confusing. ←
15:50:14 <tbaker> Alan: In order to not get stuck on names, Gavin has suggesting giving [] - seems sensible.
Alan Ruttenberg: In order to not get stuck on names, Gavin has suggesting giving [] - seems sensible. ←
15:50:51 <tbaker> ... I agree that in the way we try to build ontologies, we are all types. We assign URIs then work hard on definitions. Then when we're done we can worrry about names.
... I agree that in the way we try to build ontologies, we are all types. We assign URIs then work hard on definitions. Then when we're done we can worrry about names. ←
15:50:56 <AZ> The concept of "Graph" is not part of the RDF concepts, it's normal that it can be misused in the RDF community
Antoine Zimmermann: The concept of "Graph" is not part of the RDF concepts, it's normal that it can be misused in the RDF community ←
15:51:03 <tbaker> ... If you look at this as six types.
... If you look at this as six types. ←
15:51:07 <MacTed> so rather than "mint URIs" you mean "mint opaque URIs"
Ted Thibodeau: so rather than "mint URIs" you mean "mint opaque URIs" ←
15:51:09 <tbaker> Ivan: They are not necessarily types.
Ivan Herman: They are not necessarily types. ←
15:51:17 <PatH> fwiw, my recent prposal was to bless the sloppiness of the general usage. Think of it as RDF Unitarianism.
Patrick Hayes: fwiw, my recent prposal was to bless the sloppiness of the general usage. Think of it as RDF Unitarianism. ←
15:51:21 <ivan> ack cygri
Ivan Herman: ack cygri ←
15:51:21 <Zakim> cygri, you wanted to ask whether fixing use of terminology is a goal of this WG
Zakim IRC Bot: cygri, you wanted to ask whether fixing use of terminology is a goal of this WG ←
15:51:27 <tbaker> Alan: Why not? Each term refers to something that has properties. That is what a type is.
Alan Ruttenberg: Why not? Each term refers to something that has properties. That is what a type is. ←
15:51:49 <tbaker> Richard: Lots of terms that we use and that needed to be agreed, and do not correspond to types - e.g., subject, predicate....
Richard Cyganiak: Lots of terms that we use and that needed to be agreed, and do not correspond to types - e.g., subject, predicate.... ←
15:51:52 <alanr> a type is precisely a bunch of things that share properties
Alan Ruttenberg: a type is precisely a bunch of things that share properties ←
15:52:30 <alanr> pat: hate to disagree, but really, do you think that will help interoperability?
Patrick Hayes: hate to disagree, but really, do you think that will help interoperability? [ Scribe Assist by Alan Ruttenberg ] ←
15:52:40 <tbaker> ... Am I hearing from some that they have the ambition to fix the misuse of terminology in the community? Do we want to come up with a terminology that my include, or deviate from, existing terminology? Is this a requirement for WG to succeed.
... Am I hearing from some that they have the ambition to fix the misuse of terminology in the community? Do we want to come up with a terminology that my include, or deviate from, existing terminology? Is this a requirement for WG to succeed. ←
15:53:01 <tbaker> Sandro: Btw goal and requirement. Hard to succeed if we don't get the terminology.
Sandro Hawke: Btw goal and requirement. Hard to succeed if we don't get the terminology. ←
15:53:04 <sandro> sandro: I think good terminology will help us a lot.
Sandro Hawke: I think good terminology will help us a lot. [ Scribe Assist by Sandro Hawke ] ←
15:53:08 <davidwood> The goal is, IMO, to align our new documents with terms that are used in other W3 documents and extend as needed (but only as needed).
David Wood: The goal is, IMO, to align our new documents with terms that are used in other W3 documents and extend as needed (but only as needed). ←
15:53:13 <tbaker> Scribe notes that someone said "Trying to get new set not prone to misuse".
Scribe notes that someone said "Trying to get new set not prone to misuse". ←
15:53:31 <PatH> alanr, i dont think terminology is relevant to interoperation much at all.
Patrick Hayes: alanr, i dont think terminology is relevant to interoperation much at all. ←
15:53:40 <ivan> q?
Ivan Herman: q? ←
15:53:45 <tbaker> Ivan: That train may be gone. I would now be happy if we could document exactly the way terminology used out there, and only add terminology where needed to make things clear.
Ivan Herman: That train may be gone. I would now be happy if we could document exactly the way terminology used out there, and only add terminology where needed to make things clear. ←
15:54:01 <tbaker> ... Turn around Richard's question: What would you like to see there?
... Turn around Richard's question: What would you like to see there? ←
15:54:17 <PatH> zakim, mute me.
Patrick Hayes: zakim, mute me. ←
15:54:17 <Zakim> PatH should now be muted
Zakim IRC Bot: PatH should now be muted ←
15:54:43 <tbaker> Richard: Would like to see, eventually, the bits of SPARQL - RDF datasets definition - the upper half of [this circle in the diagram - URL please!].
Richard Cyganiak: Would like to see, eventually, the bits of SPARQL - RDF datasets definition - the upper half of [this circle in the diagram - URL please!]. ←
15:55:01 <alanr> pat: I interpreted "sloppiness of general usage" to mean no distinct set of names, each of which means a specific sort of thing. Did you mean something different?
Patrick Hayes: I interpreted "sloppiness of general usage" to mean no distinct set of names, each of which means a specific sort of thing. Did you mean something different? [ Scribe Assist by Alan Ruttenberg ] ←
15:55:22 <sandro> Diagram appears here: http://www.w3.org/2012/08/RDFNG.html#concepts
Sandro Hawke: Diagram appears here: http://www.w3.org/2012/08/RDFNG.html#concepts ←
15:55:43 <tbaker> ... in the lower half of the document, mutable RDF dataset, then slot that binds [x]. Both not particularly happy with terms there now and not 100% convinced why we need them all. Hence: what are we trying to achieve? Do we want to...
... in the lower half of the document, mutable RDF dataset, then slot that binds [x]. Both not particularly happy with terms there now and not 100% convinced why we need them all. Hence: what are we trying to achieve? Do we want to... ←
15:56:11 <alanr> you need a glossary and translation guide.
Alan Ruttenberg: you need a glossary and translation guide. ←
15:56:22 <tbaker> ... SPARQL Update defines Graph Store - do we want to cover that? If we want to cover all relevant concepts from RDF specs, then we need. But if goal is to cover use cases, then unclear whether needed.
... SPARQL Update defines Graph Store - do we want to cover that? If we want to cover all relevant concepts from RDF specs, then we need. But if goal is to cover use cases, then unclear whether needed. ←
15:56:41 <tbaker> ... The GBox thing: we need to define something. The rest: not sure we need.
... The GBox thing: we need to define something. The rest: not sure we need. ←
15:56:47 <alanr> tbaker: according to the diagram "mutable rdf dataset" is a contradiction in terms
Thomas Baker: according to the diagram "mutable rdf dataset" is a contradiction in terms [ Scribe Assist by Alan Ruttenberg ] ←
15:56:58 <PatH> alanr, not exactly. See http://lists.w3.org/Archives/Public/public-rdf-wg/2012Aug/0075.html
Patrick Hayes: alanr, not exactly. See http://lists.w3.org/Archives/Public/public-rdf-wg/2012Aug/0075.html ←
15:57:31 <tbaker> ... Will need something for GBox - explain how this concept relates to real world where things change.
... Will need something for GBox - explain how this concept relates to real world where things change. ←
15:57:31 <ivan> q?
Ivan Herman: q? ←
15:57:48 <davidwood> PatH, +1
David Wood: PatH, +1 ←
15:58:18 <davidwood> Please note that this WG never changes :)
David Wood: Please note that this WG never changes :) ←
15:58:48 <alanr> pat: concur in general, and note FixedResource in web document language. Ability to subclass is essential, which is why I'm surprised these aren't considered types. Then they could be organized
Patrick Hayes: concur in general, and note FixedResource in web document language. Ability to subclass is essential, which is why I'm surprised these aren't considered types. Then they could be organized [ Scribe Assist by Alan Ruttenberg ] ←
15:59:25 <ivan> q+
Ivan Herman: q+ ←
15:59:29 <alanr> so immutable rdf graph (according to document) is analogous to FixedResource
Alan Ruttenberg: so immutable rdf graph (according to document) is analogous to FixedResource ←
15:59:33 <PatH> davidwood, lol.
Patrick Hayes: davidwood, lol. ←
15:59:48 <tbaker> Y: Things which change over time - exists in nature. If you have to express this concept, must be able to discuss State A and State B - name them. I'd like to think these are Datasets (in current). Prefer to call GSnap. Temporal snapshot of a thing which changes over time (usefully called GBox). If we didn't need, we wouldn't have come up with them and used them so consistently. We...
Yves Raimond: Things which change over time - exists in nature. If you have to express this concept, must be able to discuss State A and State B - name them. I'd like to think these are Datasets (in current). Prefer to call GSnap. Temporal snapshot of a thing which changes over time (usefully called GBox). If we didn't need, we wouldn't have come up with them and used them so consistently. We... ←
15:59:50 <tbaker> ...have demonstrated that we need these.
...have demonstrated that we need these. ←
15:59:52 <davidwood> Perhaps we should add the terms g-box, g-box and g-snap to the diagram, if only temporarily.
David Wood: Perhaps we should add the terms g-box, g-box and g-snap to the diagram, if only temporarily. ←
16:00:08 <Zakim> -Souri
Zakim IRC Bot: -Souri ←
16:00:15 <tbaker> Richard: I said GBox - we will need. So we're not disagreeing about that.
Richard Cyganiak: I said GBox - we will need. So we're not disagreeing about that. ←
16:00:22 <alanr> pat: also note that in web arch, we don't sanction just *any* change. We say that "cool uris don't change"
Patrick Hayes: also note that in web arch, we don't sanction just *any* change. We say that "cool uris don't change" [ Scribe Assist by Alan Ruttenberg ] ←
16:00:34 <tbaker> ... Not sure we need Slots and Graph Store, or equivalents. Lower-right part.
... Not sure we need Slots and Graph Store, or equivalents. Lower-right part. ←
16:00:55 <ivan> ack ivan
Ivan Herman: ack ivan ←
16:00:56 <tbaker> Y: Hear what you are saying. I think those things make the picture clearer.
Yves Raimond: Hear what you are saying. I think those things make the picture clearer. ←
16:01:03 <PatH> But when they do, we dont say that a definition has been violated.
Patrick Hayes: But when they do, we dont say that a definition has been violated. ←
16:01:14 <alanr> This person who hasn't been part,will be rather shocked at this diagram
Alan Ruttenberg: This person who hasn't been part,will be rather shocked at this diagram ←
16:01:21 <davidwood> To me, the symmetry of the diagram proves that all the concepts should be represented. That helps comprehension.
David Wood: To me, the symmetry of the diagram proves that all the concepts should be represented. That helps comprehension. ←
16:01:47 <tbaker> Ivan: Agree with Ted. When we came up with this diagram, things became clearer - i.e., concepts that are already out there. I personally think the lower half of the doc is necessary.
Ivan Herman: Agree with Ted. When we came up with this diagram, things became clearer - i.e., concepts that are already out there. I personally think the lower half of the doc is necessary. ←
16:01:53 <cygri> q+
Richard Cyganiak: q+ ←
16:02:02 <alanr> you have a perfectly good set of tools to define and relate terms (RDF/OWL) and instead you decide to use ad-hoc stuff. Eat your own dogfood?
Alan Ruttenberg: you have a perfectly good set of tools to define and relate terms (RDF/OWL) and instead you decide to use ad-hoc stuff. Eat your own dogfood? ←
16:02:17 <tbaker> ... Not sure about changing existing terms, where we might create more harm by changing than by using terms that are sloppily used.
... Not sure about changing existing terms, where we might create more harm by changing than by using terms that are sloppily used. ←
16:02:19 <ivan> ack cygri
Ivan Herman: ack cygri ←
16:03:23 <sandro> q+
Sandro Hawke: q+ ←
16:03:25 <MacTed> q+ reason for new terms is for unambiguous discussion. ambiguity can be resolved by using the unambiguous term. ambiguous terms cannot be used to resolve ambiguity...
Ted Thibodeau: q+ reason for new terms is for unambiguous discussion. ambiguity can be resolved by using the unambiguous term. ambiguous terms cannot be used to resolve ambiguity... ←
16:03:38 <PatH> pat has been muted for a while now, guys.
Patrick Hayes: pat has been muted for a while now, guys. ←
16:03:40 <MacTed> q- reason
Ted Thibodeau: q- reason ←
16:03:49 <MacTed> q+ to say reason for new terms is for unambiguous discussion. ambiguity can be resolved by using the unambiguous term. ambiguous terms cannot be used to resolve ambiguity...
Ted Thibodeau: q+ to say reason for new terms is for unambiguous discussion. ambiguity can be resolved by using the unambiguous term. ambiguous terms cannot be used to resolve ambiguity... ←
16:03:58 <gavinc> I agree with cygri, I am confused that my website has become a graph store
Gavin Carothers: I agree with cygri, I am confused that my website has become a graph store ←
16:04:01 <alanr> unambiguity can never be resolved by "terms". URIs do better, I hear ;)
Alan Ruttenberg: unambiguity can never be resolved by "terms". URIs do better, I hear ;) ←
16:04:07 <ivan> q?
Ivan Herman: q? ←
16:04:08 <tbaker> Richard: Sounds okay - makes sense. One thing: Graph Store - I am unsure - unlike other terms, this is only in SPARQL Update - not used widely in community. To change that would not be as disruptive. As for named GBoxes - I can sort of see "Collection of Named GBoxes" but Web is simply not a Graph Store. Makes sense for SPARQL update, but too specific to that use case to be generally...
Richard Cyganiak: Sounds okay - makes sense. One thing: Graph Store - I am unsure - unlike other terms, this is only in SPARQL Update - not used widely in community. To change that would not be as disruptive. As for named GBoxes - I can sort of see "Collection of Named GBoxes" but Web is simply not a Graph Store. Makes sense for SPARQL update, but too specific to that use case to be generally... ←
16:04:10 <tbaker> ...applicable. So have reservations.
...applicable. So have reservations. ←
16:04:10 <ivan> ack sandro
Ivan Herman: ack sandro ←
16:04:37 <davidwood> The point is, we need a term for g-box, which the document calls a space. The term is not important, but the concept is critical. All other terms exist elsewhere. Why argue about terms? Terminology is even less important than syntax, as long as they are used consistently.
David Wood: The point is, we need a term for g-box, which the document calls a space. The term is not important, but the concept is critical. All other terms exist elsewhere. Why argue about terms? Terminology is even less important than syntax, as long as they are used consistently. ←
16:04:58 <tbaker> Sandro: Guess I wonder if - one issue unresolved: whether we stick - for RDF Graph and Dataset - to SPARQL, or consider changing because the community uses with other definitions.
Sandro Hawke: Guess I wonder if - one issue unresolved: whether we stick - for RDF Graph and Dataset - to SPARQL, or consider changing because the community uses with other definitions. ←
16:05:20 <tbaker> ... Rather than us sharing perceptions - could we do a survey?
... Rather than us sharing perceptions - could we do a survey? ←
16:05:31 <PatH> ivan, do you see why i suggested putting the terminology discussion second?
Patrick Hayes: ivan, do you see why i suggested putting the terminology discussion second? ←
16:05:45 <cygri> q+
Richard Cyganiak: q+ ←
16:05:51 <tbaker> ... Ask what people mean by "graph". How would you interpret...? We would find perhaps that we ourselves do not use consistently.
... Ask what people mean by "graph". How would you interpret...? We would find perhaps that we ourselves do not use consistently. ←
16:05:55 <ivan> ack MacTed
Ivan Herman: ack MacTed ←
16:05:55 <Zakim> MacTed, you wanted to say reason for new terms is for unambiguous discussion. ambiguity can be resolved by using the unambiguous term. ambiguous terms cannot be used to resolve
Zakim IRC Bot: MacTed, you wanted to say reason for new terms is for unambiguous discussion. ambiguity can be resolved by using the unambiguous term. ambiguous terms cannot be used to resolve ←
16:06:00 <Zakim> ... ambiguity...
Zakim IRC Bot: ... ambiguity... ←
16:06:37 <tbaker> Ted: Reason for new terms - not to replace old. But to have unambiguous term where you mean unambiguous things. "Do you mean X?" We have been doing with GBox and GSnap. We need for all the points on diagram.
Ted Thibodeau: Reason for new terms - not to replace old. But to have unambiguous term where you mean unambiguous things. "Do you mean X?" We have been doing with GBox and GSnap. We need for all the points on diagram. ←
16:06:56 <ivan> ack cygri
Ivan Herman: ack cygri ←
16:07:04 <tbaker> ... Serializations, etc, come from concepts.
... Serializations, etc, come from concepts. ←
16:07:37 <alanr> q+ to mention OBO approach re: community specific labels
Alan Ruttenberg: q+ to mention OBO approach re: community specific labels ←
16:07:41 <sandro> +1 ted: it makes sense to define precise terms for the terms that are often ambiguous
Sandro Hawke: +1 ted: it makes sense to define precise terms for the terms that are often ambiguous ←
16:08:25 <PatH> Ted, there is a strategy which is widely used. Foo is ambiguous, so we define an A-Foo and a B-Foo, and still let people be sloppy using Foo when it doesn't matter. Relling them to say Baz some of the time forces them to think in a new way, and they resist this.
Patrick Hayes: Ted, there is a strategy which is widely used. Foo is ambiguous, so we define an A-Foo and a B-Foo, and still let people be sloppy using Foo when it doesn't matter. Relling them to say Baz some of the time forces them to think in a new way, and they resist this. ←
16:08:49 <sandro> See "backronym"
Sandro Hawke: See "backronym" ←
16:08:56 <tbaker> Richard: Agree with Ted - makes sense to define new terms that is really unambiguous, but not intend that people use everyday. As for survey? Unsure. Even terms like "set" and "table" - mutable or immutable? Can be used either way. My preference: acknowledge that certain concepts exist and probably need to be defined in Concepts and will need to be defined, but work with placeholders for...
Richard Cyganiak: Agree with Ted - makes sense to define new terms that is really unambiguous, but not intend that people use everyday. As for survey? Unsure. Even terms like "set" and "table" - mutable or immutable? Can be used either way. My preference: acknowledge that certain concepts exist and probably need to be defined in Concepts and will need to be defined, but work with placeholders for... ←
16:08:58 <tbaker> ...now. As Pat said earily, stuff will become clearer when we work out semantics.
...now. As Pat said earily, stuff will become clearer when we work out semantics. ←
16:09:02 <MacTed> Zakim, who's noisy?
Ted Thibodeau: Zakim, who's noisy? ←
16:09:13 <Zakim> MacTed, listening for 10 seconds I heard sound from the following: AndyS (24%), MacTed (32%), Ivan (61%)
Zakim IRC Bot: MacTed, listening for 10 seconds I heard sound from the following: AndyS (24%), MacTed (32%), Ivan (61%) ←
16:09:22 <alanr> +1 to PatH, and note we can defined foo as the disjoint union of foo-a and foo-b (assuming we are using the tools available to us) and make this "sloppy" usage precise.
Alan Ruttenberg: +1 to PatH, and note we can defined foo as the disjoint union of foo-a and foo-b (assuming we are using the tools available to us) and make this "sloppy" usage precise. ←
16:09:44 <tbaker> Ivan: Need proposal: the diagram itself is something that will end up in the Concept document plus exact English terms.
Ivan Herman: Need proposal: the diagram itself is something that will end up in the Concept document plus exact English terms. ←
16:10:15 <tbaker> Ted: So this proposal makes the right distinctions but does not provide the terms?
Ted Thibodeau: So this proposal makes the right distinctions but does not provide the terms? ←
16:10:19 <tbaker> Ivan: Do we agree?
Ivan Herman: Do we agree? ←
16:10:23 <PatH> +1 agree on that
Patrick Hayes: +1 agree on that ←
16:10:37 <alanr> why isn't a proposal being written to the IRC and then voted on if you are seeking agreement.
Alan Ruttenberg: why isn't a proposal being written to the IRC and then voted on if you are seeking agreement. ←
16:11:28 <tbaker> Richard: Comfortable using diagram as basis for discussion, acknowledging that it is reasonable to use these concepts. Would like to see how - as an editor, would not want to decide that this diagram should be in final spec. Seems premature to decide that.
Richard Cyganiak: Comfortable using diagram as basis for discussion, acknowledging that it is reasonable to use these concepts. Would like to see how - as an editor, would not want to decide that this diagram should be in final spec. Seems premature to decide that. ←
16:11:52 <davidwood> +1 to include the diagram. It is clear from this discussion that we need to help readers relate the terms.
David Wood: +1 to include the diagram. It is clear from this discussion that we need to help readers relate the terms. ←
16:11:58 <tbaker> ... Would be happy to see it there as working document, as placeholder.
... Would be happy to see it there as working document, as placeholder. ←
16:12:06 <PatH> All our decisions are working :-)
Patrick Hayes: All our decisions are working :-) ←
16:12:15 <sandro> PROPOSAL: The WG thinks a diagram like http://www.w3.org/2012/08/rdf-spaces-relationships.svg is very helpful, and we should probably have something like that (with different terms) in RDF Concepts
PROPOSED: The WG thinks a diagram like http://www.w3.org/2012/08/rdf-spaces-relationships.svg is very helpful, and we should probably have something like that (with different terms) in RDF Concepts ←
16:12:17 <tbaker> Ivan: Put that as proposal we can refer to?
Ivan Herman: Put that as proposal we can refer to? ←
16:12:36 <MacTed> + PROPOSAL: The WG thinks a diagram like http://www.w3.org/2012/08/rdf-spaces-relationships.svg is very helpful, and we should probably have something like that (possibly with different terms) in RDF Concepts
Ted Thibodeau: + PROPOSAL: The WG thinks a diagram like http://www.w3.org/2012/08/rdf-spaces-relationships.svg is very helpful, and we should probably have something like that (possibly with different terms) in RDF Concepts ←
16:12:53 <davidwood> +1 to MacTed version
David Wood: +1 to MacTed version ←
16:13:01 <PatH> +1 to whatever wording we decideo on here.
Patrick Hayes: +1 to whatever wording we decideo on here. ←
16:13:06 <alanr> I don't vote, but I would think that that resolution would be very hard to follow up on without disagreement
Alan Ruttenberg: I don't vote, but I would think that that resolution would be very hard to follow up on without disagreement ←
16:13:09 <sandro> PROPOSAL: The WG thinks a diagram like http://www.w3.org/2012/08/rdf-spaces-relationships.svg is very helpful, and we should probably have something like that (probably with different terms) in RDF Concepts
PROPOSED: The WG thinks a diagram like http://www.w3.org/2012/08/rdf-spaces-relationships.svg is very helpful, and we should probably have something like that (probably with different terms) in RDF Concepts ←
16:13:19 <cygri> +1
Richard Cyganiak: +1 ←
16:13:26 <ivan> +1
Ivan Herman: +1 ←
16:13:29 <tbaker> X: This diagram is pretty clear.
Ted Thibodeau: This diagram is pretty clear. ←
16:13:29 <SteveH> +0
Steve Harris: +0 ←
16:13:34 <davidwood> +1 to final version
David Wood: +1 to final version ←
16:13:35 <sandro> s/X/ted/
16:13:35 <MacTed> s/X/Ted
16:13:36 <gkellogg> +1
Gregg Kellogg: +1 ←
16:13:38 <tbaker> Thomas Baker: +1 - to final
Thomas Baker: +1 - to final ←
16:13:39 <AZ> +1
Antoine Zimmermann: +1 ←
16:13:40 <pchampin> +1
16:13:41 <sandro> +1
Sandro Hawke: +1 ←
16:13:59 <PatH> Sorry i have to run..
Patrick Hayes: Sorry i have to run.. ←
16:14:05 <sandro> ciao, PatH
Sandro Hawke: ciao, PatH ←
16:14:07 <PatH> +1
Patrick Hayes: +1 ←
16:14:17 <alanr> i was on q
Alan Ruttenberg: i was on q ←
16:14:19 <tbaker> RESOLVED: The WG thinks a diagram like http://www.w3.org/2012/08/rdf-spaces-relationships.svg is very helpful, and we should probably have something like that (probably with different terms) in RDF Concepts
RESOLVED: The WG thinks a diagram like http://www.w3.org/2012/08/rdf-spaces-relationships.svg is very helpful, and we should probably have something like that (probably with different terms) in RDF Concepts ←
16:14:22 <alanr> on previous issue
Alan Ruttenberg: on previous issue ←
16:14:27 <alanr> q?
Alan Ruttenberg: q? ←
16:15:11 <tbaker> Ivan: At beginning of WG life, resolution to issue 1 that Turtle syntax should be as close as possible to SPARQL. Same resolution applies to what we do in TRIG? Or not?
Ivan Herman: At beginning of WG life, resolution to ISSUE-1 that Turtle syntax should be as close as possible to SPARQL. Same resolution applies to what we do in TRIG? Or not? ←
16:15:14 <alanr> q-
Alan Ruttenberg: q- ←
16:15:20 <cygri> ISSUE-1?
16:15:21 <trackbot> ISSUE-1 -- Is TURTLE the same as SPARQL 1.1 triple syntax? -- closed
Trackbot IRC Bot: ISSUE-1 -- Is TURTLE the same as SPARQL 1.1 triple syntax? -- closed ←
16:15:21 <trackbot> http://www.w3.org/2011/rdf-wg/track/issues/1
Trackbot IRC Bot: http://www.w3.org/2011/rdf-wg/track/issues/1 ←
16:15:35 <tbaker> ... Two grammars: one reproducing TRIG, another taking into account SPARQL influence.
... Two grammars: one reproducing TRIG, another taking into account SPARQL influence. ←
16:15:45 <LeeF> Yes
Lee Feigenbaum: Yes ←
16:15:47 <tbaker> ... Do we consider ISSUE-1 to be a guideline for TRIG as well?
... Do we consider ISSUE-1 to be a guideline for TRIG as well? ←
16:15:49 <sandro> -1
Sandro Hawke: -1 ←
16:15:56 <ivan> +1
Ivan Herman: +1 ←
16:15:59 <gavinc> +1 from Editor
Gavin Carothers: +1 from Editor ←
16:16:02 <davidwood> +1
David Wood: +1 ←
16:16:06 <tbaker> Thomas Baker: 0
Thomas Baker: 0 ←
16:16:16 <davidwood> Sandro, why?
David Wood: Sandro, why? ←
16:16:29 <LeeF> I took it the 2nd way :)
Lee Feigenbaum: I took it the 2nd way :) ←
16:16:32 <sandro> I think TriG is a decent starting point, but when it conflicts with SPARQL and other deployed things, TriG shouldn't have a lot of weight.
Sandro Hawke: I think TriG is a decent starting point, but when it conflicts with SPARQL and other deployed things, TriG shouldn't have a lot of weight. ←
16:16:38 <tbaker> Gavin: That can be taken two ways: Keep existing TRIG and align with SPARQL?
Andy Seaborne: That can be taken two ways: Keep existing TRIG and align with SPARQL? ←
16:16:46 <gavinc> s/Gavin/AndyS
16:17:03 <LeeF> Why doesn't TriG (a deployed thing) have a lot of weight against "other deployed things" ? :)
Lee Feigenbaum: Why doesn't TriG (a deployed thing) have a lot of weight against "other deployed things" ? :) ←
16:17:09 <davidwood> Please note that my proposal in the agenda had the words, "where possible" and ensured backward compatibility.
David Wood: Please note that my proposal in the agenda had the words, "where possible" and ensured backward compatibility. ←
16:17:30 <tbaker> Ivan: When I said "align with SPARQL" = in a way that keeps compatibility with existing TRIG data. Main issue: biggest difference between two: in TRIG, default graph must be enclosed in curly brackets. In SPARQL, not.
Ivan Herman: When I said "align with SPARQL" = in a way that keeps compatibility with existing TRIG data. Main issue: biggest difference between two: in TRIG, default graph must be enclosed in curly brackets. In SPARQL, not. ←
16:17:38 <gavinc> TriG is less deployed than SPARQL or Turtle
Gavin Carothers: TriG is less deployed than SPARQL or Turtle ←
16:17:52 <gavinc> Yes, totally possible!
Gavin Carothers: Yes, totally possible! ←
16:17:52 <tbaker> Sandro: Which is more important? TriG or SPARQL compatibility?
Sandro Hawke: Which is more important? TriG or SPARQL compatibility? ←
16:17:55 <LeeF> Agree
Lee Feigenbaum: Agree ←
16:18:16 <sandro> +1 making GRAPH and { } around default graph optional.
Sandro Hawke: +1 making GRAPH and { } around default graph optional. ←
16:18:17 <tbaker> Ivan: Putting default graph in curly brackets is optional. And SPARQL is valid TriG.
Ivan Herman: Putting default graph in curly brackets is optional. And SPARQL is valid TriG. ←
16:18:17 <davidwood> I trust Andy on all things parser related
David Wood: I trust Andy on all things parser related ←
16:18:20 <SteveH> I have big concerns about possible Turtle documents that are also valid TriG
Steve Harris: I have big concerns about possible Turtle documents that are also valid TriG ←
16:18:21 <gavinc> Would like = to go away, but that's about it ;)
Gavin Carothers: Would like = to go away, but that's about it ;) ←
16:18:22 <pchampin> +1
16:18:26 <gkellogg> +1
Gregg Kellogg: +1 ←
16:18:30 <alanr> by all
Alan Ruttenberg: by all ←
16:18:33 <gavinc> N3 compatibility is not a feature
Gavin Carothers: N3 compatibility is not a feature ←
16:19:11 <AZ> +1 in general but not with the "=" sign
Antoine Zimmermann: +1 in general but not with the "=" sign ←
16:19:35 <gavinc> There are implementations in the wild that do not support it today
Gavin Carothers: There are implementations in the wild that do not support it today ←
16:19:48 <tbaker> Richard: TriG does not allow equals sign. First versions did not support.
Richard Cyganiak: TriG does not allow equals sign. First versions did not support. ←
16:20:10 <tbaker> Ivan: Abbrevs for equals and sameas.
Ivan Herman: Abbrevs for equals and sameas. ←
16:20:15 <sandro> sandro: = would be bad -- conflicts with N3, given likely semantics
Sandro Hawke: = would be bad -- conflicts with N3, given likely semantics [ Scribe Assist by Sandro Hawke ] ←
16:20:33 <gavinc> Zakim, unmute me
Gavin Carothers: Zakim, unmute me ←
16:21:11 <gavinc> PROPOSAL: As Turtle has been brought together with SPARQL as a result of WG the resolution of ISSUE-1, similar argument can hold for TriG grammar: try to ensure, as much as possible, compatibility with SPARQL
PROPOSED: As Turtle has been brought together with SPARQL as a result of WG the resolution of ISSUE-1, similar argument can hold for TriG grammar: try to ensure, as much as possible, compatibility with SPARQL ←
16:21:14 <ivan> PROPOSED: the guideline for the definition of TriG would be the second grammar in http://www.w3.org/2012/08/RDFNG.html#trig
PROPOSED: the guideline for the definition of TriG would be the second grammar in http://www.w3.org/2012/08/RDFNG.html#trig ←
16:21:38 <tbaker> Sandro: confused about "two grammars".
Sandro Hawke: confused about "two grammars". ←
16:22:12 <SteveH> -1 - I will object to any text along that line
Steve Harris: -1 - I will object to any text along that line ←
16:22:28 <tbaker> Scribe notes that someone said "The grammar is specific. The resolution should be language introducing that grammar."
Scribe notes that someone said "The grammar is specific. The resolution should be language introducing that grammar." ←
16:22:45 <tbaker> Steve: From my quick reading, looks like a Turtle doc would be a legal TriG doc.
Steve Harris: From my quick reading, looks like a Turtle doc would be a legal TriG doc. ←
16:23:11 <tbaker> Ivan: Grammar-wise, true, but we say media-type must be different from TriG and Turtle.
Ivan Herman: Grammar-wise, true, but we say media-type must be different from TriG and Turtle. ←
16:23:37 <tbaker> Sandro: If someone serves with wrong media type, worse case: errors.
Sandro Hawke: If someone serves with wrong media type, worse case: errors. ←
16:24:46 <tbaker> [Exchange between Sandro and Gavin re: resolving to default graph].
[Exchange between Sandro and Gavin re: resolving to default graph]. ←
16:24:54 <cygri> take sparql compatibility to the max and require INSERT DATA { ... } in TriG?
Richard Cyganiak: take sparql compatibility to the max and require INSERT DATA { ... } in TriG? ←
16:25:05 <davidwood> File extensions, media types, common syntax, common semantics. I don't see a practical problem.
David Wood: File extensions, media types, common syntax, common semantics. I don't see a practical problem. ←
16:25:19 <sandro> SteveH: some systems (our system) will behave differently with a turtle document vs a trig document with just the default graph, and we are not willing to trust the media type or the filename to guide our systems in this -- the syntax must also be disjoint.
Steve Harris: some systems (our system) will behave differently with a turtle document vs a trig document with just the default graph, and we are not willing to trust the media type or the filename to guide our systems in this -- the syntax must also be disjoint. [ Scribe Assist by Sandro Hawke ] ←
16:25:21 <tbaker> Ivan: Single biggest issue: in SPARQL, query with graph is same as query without a graph (?).
Ivan Herman: Single biggest issue: in SPARQL, query with graph is same as query without a graph (?). ←
16:25:34 <davidwood> Probably also common parser, in many cases.
David Wood: Probably also common parser, in many cases. ←
16:25:45 <tbaker> ... Biggest issue aligning TriG with SPARQL - what to do about the default graph. Steve's biggest problem.
... Biggest issue aligning TriG with SPARQL - what to do about the default graph. Steve's biggest problem. ←
16:25:49 <tbaker> Steve: One of several.
Steve Harris: One of several. ←
16:26:00 <tbaker> Ivan: Steve, I was hoping this would be solved by media type.
Ivan Herman: Steve, I was hoping this would be solved by media type. ←
16:26:48 <tbaker> Sandro: If people give you incorrect data, their problem. Their giving you incorrect filetype is comparable.
Sandro Hawke: If people give you incorrect data, their problem. Their giving you incorrect filetype is comparable. ←
16:26:50 <davidwood> File extensions are the most often used mechanism to cover in absence of media types.
David Wood: File extensions are the most often used mechanism to cover in absence of media types. ←
16:27:23 <tbaker> Ivan: We must close. Steve, if you think it can be resolved, write it up.
Ivan Herman: We must close. Steve, if you think it can be resolved, write it up. ←
16:27:28 <sandro> steve: My preference is to have the error of an incorrect media type result in a failed parse, instead of invoking the wrong behavior.
Steve Harris: My preference is to have the error of an incorrect media type result in a failed parse, instead of invoking the wrong behavior. [ Scribe Assist by Sandro Hawke ] ←
16:27:29 <cygri> sandro, incorrect media types are incredibly common, especially for new file formats. lots of good content served with bad content-type.
Richard Cyganiak: sandro, incorrect media types are incredibly common, especially for new file formats. lots of good content served with bad content-type. ←
16:27:31 <tbaker> Gavin: I don't think this is the biggest issue.
Gavin Carothers: I don't think this is the biggest issue. ←
16:27:42 <pchampin> what about keeping enclosing brackets around the whold TRIG file? that would make it SPARQLish, and not compatible with Turtle
Pierre-Antoine Champin: what about keeping enclosing brackets around the whold TRIG file? that would make it SPARQLish, and not compatible with Turtle ←
16:28:18 <tbaker> Ivan, closing the meeting: We didn't kill each other! A result!
Ivan, closing the meeting: We didn't kill each other! A result! ←
Formatted by CommonScribe