Chatlog 2012-08-22

See panel, original RRSAgent log or preview nicely formatted version.

Please justify/explain non-obvious edits to this page, in your "edit summary" text.

<sandro> Guest: Alan (alanr) Ruttenberg
14:30:24 <RRSAgent> 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
14:56:18 <ivan> scribenick: tbaker
15:04:29 <ivan> Topic: minutes of last meeting
15:04:44 <ivan> zakim, aaaa is AlexHall
15:04:47 <MacTed> Zakim, [OpenLink] is temporarily me
15:04:49 <MacTed> Zakim, mute me
15:04:57 <ivan> -> 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
15:05:22 <tbaker> 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
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.
15:06:33 <ivan> -> http://www.w3.org/2011/rdf-wg/track/actions/overdue Overdue actions
15:06:36 <tbaker> ... Bunch of overdue actions:
15:07:15 <tbaker> ... Some are a few months old...  Sandro: one from Sept 2011 - still open?
15:07:44 <tbaker> ... ACTION-82 and ACTION-98 still pending.
15:08:08 <tbaker> ... ACTION-100: ask editors of SPARQL...
15:08:21 <tbaker> Sandro: never quite understood that.
15:08:25 <sandro> 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
15:09:02 <tbaker> Ivan: 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
15:09:04 <trackbot> 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
15:09:25 <trackbot> http://www.w3.org/2011/rdf-wg/track/actions/140
15:09:45 <tbaker> ... Propose to close ACTION-140.
15:09:45 <gavinc> close action-140
15:09:45 <trackbot> ACTION-140 Review XSD in RDF and OWL from semantics perspective closed
15:10:11 <tbaker> ... Pat, ACTION-166
15:10:27 <tbaker> Pat: Leave ACTION-166 and ACTION-170 open.
15:10:48 <tbaker> Ivan: 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.
15:11:46 <tbaker> Ivan: Do we want to leave it open until inverse-property sugar issue is closed?
15:11:57 <ivan> close action-180
15:11:57 <trackbot> ACTION-180 Create a proposal for inverse property syntax in Turtle closed
15:12:13 <ivan> close action-181
15:12:13 <trackbot> 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
15:12:58 <PatH> 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.
15:13:06 <gavinc> https://www.w3.org/2011/rdf-wg/track/issues/95
15:13:17 <tbaker> ... Sandro, do we have way to handle remote participation?
15:13:22 <gavinc> Open ISSUE-95
15:13:31 <tbaker> ... We will have a phone, hardware, and line?
15:13:33 <gavinc> I guess that doesn't work from IRC.
15:13:43 <tbaker> Sandro: I think so, but haven't confirmed.
15:13:53 <tbaker> Ivan: Five people already want to come in remotely.
15:14:08 <tbaker> 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].
15:14:30 <ivan> Topic: Next meeting
15:14:45 <tbaker> Ivan: Starting two weeks from now - 5 September - vacations are over.
15:16:08 <tbaker> ... 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.
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.
15:17:37 <tbaker> ... 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,
15:18:09 <tbaker> ... 2) What we do with Semantics.  Some discussion with Antoine, Sandro, etc.
15:18:23 <tbaker> ... 3) General guideline for TRIX syntax for NGs.
15:18:41 <tbaker> ... Do you all agree, or propose something radically different?
15:19:01 <tbaker> ... Will take silence as agreement.
15:19:10 <tbaker> ... Start with things that will end up in Concepts.
15:19:37 <alanr> +1
15:19:46 <tbaker> Pat: Would not start with terminology, then semantics - would reverse the order.
15:19:56 <MacTed> +1 overall to that doc
15:20:06 <tbaker> Sandro: 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.
15:21:20 <alanr> 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.
15:21:39 <tbaker> ... Comments on that issue?
15:21:43 <MacTed> q?
15:21:47 <alanr> 1+
15:21:49 <alanr> q+
15:21:52 <cygri> q+
15:22:00 <ivan> ack alanr 
15:22:29 <tbaker> Alan: 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...
15:23:07 <MacTed> Zakim, unmute me
15:23:13 <gavinc> 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?
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.
15:24:03 <tbaker> ... 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?
15:24:25 <tbaker> ... A flavor of the issues...
15:24:43 <gavinc> 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.
15:25:39 <ivan> ack cygri 
15:25:47 <tbaker> ... [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.
15:26:16 <PatH> +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?
15:27:56 <ivan> q?
15:27:58 <tbaker> ... Different opinions on this.  Difficult to know what we need to do to be successful.
15:28:53 <ivan> 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"
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.
15:29:47 <tbaker> Richard: 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.
15:30:14 <PatH> q+
15:30:20 <ivan> 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
15:30:25 <tbaker> Richard: So even semantics to use [] in default graph.
15:30:35 <alanr> 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.  
15:31:27 <tbaker> ... Will not be clear to people what this means.
15:31:43 <AZ> q+
15:32:01 <ivan> zakim, aacc is dwood
15:32:02 <ivan> \
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.
15:32:08 <ivan> ack PatH 
15:32:28 <tbaker> Pat: 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>
15:32:52 <tbaker> ... 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
15:33:01 <alanr> consistency is good
15:33:15 <ivan> q?
15:33:19 <ivan> ack alanr 
15:33:22 <tbaker> ... 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
15:33:29 <SteveH> FWIW, I've not seen this being discussed in the real world
15:33:31 <MacTed> +1 AndyS
15:34:13 <PatH> 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?
15:35:03 <tbaker> ... Need basics: "mutable" sets, document-like thinks.  Something like class extension - "semantic extension"?
15:35:30 <AndyS> agenda?
15:35:39 <PatH> 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.
15:35:44 <ivan> q+
15:35:48 <cygri> q+
15:35:51 <ivan> ack AZ 
15:35:52 <PatH> is that enough for you?
15:36:22 <MacTed> s/+1 AndyS/+1 PatH/
15:36:23 <MacTed> :-)
15:36:39 <ivan> 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).
15:37:00 <ivan> 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
15:37:14 <alanr> there's a name, and then there's a thing that it names
15:37:19 <alanr> that's the basis of RDF
15:37:34 <PatH> +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?
15:38:16 <PatH> lets do that, indeed.
15:38:22 <alanr> pat: does the idea of a semantic extension that gives a resource a graph extension work?
15:38:23 <tbaker> Ivan: 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.
15:39:02 <PatH> alanr: maybe but it seems like semantic overkill. 
15:39:12 <alanr> 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?
15:39:39 <alanr> compared to the semantic onslaught on graphs it seems relatively easy ;-)
15:39:47 <sandro> 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. 
15:39:55 <tbaker> ... Will put in what David wrote...
15:40:11 <alanr> w.r.t. terminology, there are objectional uses, e.g. "dataset"
15:40:18 <alanr> which means a lot of things 
15:40:21 <tbaker> ... 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.
15:40:42 <davidwood> Right,  should remember our consensus where it exists :)
15:40:46 <alanr> sets are not mutable
15:40:53 <alanr> that's that
15:40:57 <PatH> I think we all agree on this diagram when the labels are erased :-)
15:40:59 <alanr> mathematics defines this
15:41:02 <gavinc> It's just semantics!
15:41:14 <alanr> (I don't like the "pair" business)
15:41:25 <alanr> 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.
15:41:34 <tbaker> Ivan: Straw poll on the proposal?
15:41:38 <ivan> +1
15:41:40 <MacTed> +1
15:41:42 <AndyS> +1
15:41:42 <alanr> david, discussed what?
15:41:43 <tbaker> Thomas Baker: +1
15:41:46 <davidwood> +1
15:41:47 <cgreer> +1
15:41:48 <sandro> +1 Sure, why not
15:41:50 <PatH> +?
15:41:52 <gkellogg> +1
15:41:53 <Souri> +1
15:41:56 <AZ> +1 to section Concepts at least
15:42:03 <gavinc> +1 to uh, whatever the proposal is 
15:42:07 <davidwood> alanr, we all know that math sets are immutable.  
15:42:16 <SteveH> +1
15:42:18 <PatH> +1
15:42:21 <LeeF> +1
15:42:28 <AlexHall> +1
15:42:32 <pchampin_> +1
15:42:35 <cygri> -0.5
15:42:39 <tbaker> Ivan: Guideline on what we discuss.
15:43:11 <tbaker> Richard: Back now.  I don't understand the proposal.
15:43:19 <alanr> not sure why datasets are just not classes of rdf graph
15:43:20 <tbaker> ... What is being proposed?
15:43:33 <MacTed> this is more straw poll than proposal, is it not?
15:43:35 <tbaker> Sandro: 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.
15:44:04 <alanr> eric: for an outsider, completely confusing
15:44:10 <tbaker> Pat: Could Sandro number nodes in that document?  We could cite by number...
15:44:43 <sandro> sandro: that's what gbox/gsnap are.
15:44:45 <sandro> pat: fair enough
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.
15:45:45 <alanr> 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".
15:46:16 <PatH> 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
15:46:26 <tbaker> Ivan: 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.
15:47:14 <alanr> q+
15:47:20 <tbaker> Ivan: So you want to come up with terms different from those used for a long time?
15:47:21 <alanr> q-
15:47:29 <PatH> 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)
15:47:41 <alanr> 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.
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?
15:48:21 <PatH> Im beginning to understand why Moses had a bad temper.
15:49:14 <ericP> 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.  
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.
15:49:33 <gavinc> SO?
15:49:40 <cygri> 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.
15:49:43 <ericP> just need the 3rd term for the grsph label
15:49:44 <ivan> ack alanr 
15:49:44 <Zakim> 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%)
15:50:10 <davidwood> 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.
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.
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
15:51:03 <tbaker> ... If you look at this as six types.
15:51:07 <MacTed> so rather than "mint URIs" you mean "mint opaque URIs"
15:51:09 <tbaker> Ivan: 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.
15:51:21 <ivan> ack cygri 
15:51:21 <Zakim> 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.
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....
15:51:52 <alanr> 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?
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.
15:53:01 <tbaker> Sandro: 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.
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).
15:53:13 <tbaker> 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.
15:53:40 <ivan> 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.
15:54:01 <tbaker> ... Turn around Richard's question: What would you like to see there?
15:54:17 <PatH> zakim, mute me.
15:54:17 <Zakim> 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!].
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?  
15:55:22 <sandro> 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...
15:56:11 <alanr> 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.
15:56:41 <tbaker> ... 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
15:56:58 <PatH> 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.
15:57:31 <ivan> q?
15:57:48 <davidwood> PatH, +1
15:58:18 <davidwood> 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
15:59:25 <ivan> q+
15:59:29 <alanr> so immutable rdf graph (according to document) is analogous to FixedResource
15:59:33 <PatH> 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...
15:59:50 <tbaker> ...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.
16:00:08 <Zakim> -Souri
16:00:15 <tbaker> Richard: 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"
16:00:34 <tbaker> ... Not sure we need Slots and Graph Store, or equivalents.  Lower-right part.
16:00:55 <ivan> ack ivan 
16:00:56 <tbaker> Y: 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.
16:01:14 <alanr> 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.
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.
16:01:53 <cygri> 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?
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.
16:02:19 <ivan> ack cygri 
16:03:23 <sandro> 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...
16:03:38 <PatH> pat has been muted for a while now, guys.
16:03:40 <MacTed> 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...
16:03:58 <gavinc> 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 ;)
16:04:07 <ivan> 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...
16:04:10 <tbaker> ...applicable.  So have reservations.
16:04:10 <ivan> 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.
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.
16:05:20 <tbaker> ... 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?
16:05:45 <cygri> 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.
16:05:55 <ivan> 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
16:06:00 <Zakim> ... 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.
16:06:56 <ivan> ack cygri 
16:07:04 <tbaker> ... Serializations, etc, come from concepts.
16:07:37 <alanr> 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
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.
16:08:49 <sandro> 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...
16:08:58 <tbaker> ...now.  As Pat said earily, stuff will become clearer when we work out semantics.
16:09:02 <MacTed> 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%)
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.
16:09:44 <tbaker> Ivan: 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?
16:10:19 <tbaker> Ivan: Do we agree?
16:10:23 <PatH> +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.
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.
16:11:52 <davidwood> +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.
16:12:06 <PatH> 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
16:12:17 <tbaker> Ivan: 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
16:12:53 <davidwood> +1 to MacTed version
16:13:01 <PatH> +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
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
16:13:19 <cygri> +1
16:13:26 <ivan> +1
16:13:29 <tbaker> X: This diagram is pretty clear.
16:13:29 <SteveH> +0
16:13:34 <davidwood> +1 to final version
16:13:35 <sandro> s/X/ted/
16:13:35 <MacTed> s/X/Ted
16:13:36 <gkellogg> +1
16:13:38 <tbaker> Thomas Baker: +1 - to final
16:13:39 <AZ> +1
16:13:40 <pchampin> +1
16:13:41 <sandro> +1
16:13:59 <PatH> Sorry i have to run..
16:14:05 <sandro> ciao, PatH 
16:14:07 <PatH> +1
16:14:17 <alanr> 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
16:14:22 <alanr> on previous issue
16:14:27 <alanr> 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?
16:15:14 <alanr> q-
16:15:20 <cygri> ISSUE-1?
16:15:21 <trackbot> 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
16:15:35 <tbaker> ... Two grammars: one reproducing TRIG, another taking into account SPARQL influence.
16:15:45 <LeeF> Yes
16:15:47 <tbaker> ... Do we consider ISSUE-1 to be a guideline for TRIG as well?
16:15:49 <sandro> -1   
16:15:56 <ivan> +1
16:15:59 <gavinc> +1 from Editor
16:16:02 <davidwood> +1 
16:16:06 <tbaker> Thomas Baker: 0
16:16:16 <davidwood> Sandro, why?
16:16:29 <LeeF> 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.
16:16:38 <tbaker> Gavin: 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" ? :)
16:17:09 <davidwood> 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.
16:17:38 <gavinc> TriG is less deployed than SPARQL or Turtle
16:17:52 <gavinc> Yes, totally possible!
16:17:52 <tbaker> Sandro: Which is more important?  TriG or SPARQL compatibility?
16:17:55 <LeeF> Agree
16:18:16 <sandro> +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.
16:18:17 <davidwood> 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
16:18:21 <gavinc> Would like = to go away, but that's about it ;)
16:18:22 <pchampin> +1
16:18:26 <gkellogg> +1
16:18:30 <alanr> by all
16:18:33 <gavinc> N3 compatibility is not a feature
16:19:11 <AZ> +1 in general but not with the "=" sign
16:19:35 <gavinc> 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. 
16:20:10 <tbaker> Ivan: Abbrevs for equals and sameas.
16:20:15 <sandro> sandro: = would be bad -- conflicts with N3, given likely semantics
16:20:33 <gavinc> 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
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
16:21:38 <tbaker> Sandro: confused about "two grammars".
16:22:12 <SteveH> -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."
16:22:45 <tbaker> Steve: 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.
16:23:37 <tbaker> Sandro: If someone serves with wrong media type, worse case: errors.
16:24:46 <tbaker> [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?
16:25:05 <davidwood> 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.
16:25:21 <tbaker> Ivan: 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.
16:25:45 <tbaker> ... 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.
16:26:00 <tbaker> Ivan: 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.
16:26:50 <davidwood> 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.  
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.
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.
16:27:31 <tbaker> Gavin: 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
16:28:18 <tbaker> Ivan, closing the meeting: We didn't kill each other!  A result!
# SPECIAL MARKER FOR CHATSYNC.  DO NOT EDIT THIS LINE OR BELOW.  SRCLINESUSED=00000561