Lee, yes. They are a key part, and they are a strong point. But exactly because it is a key part, we have to be very careful when and how we use it in email discussions. Richard, this mail was not against your argument specifically (as I hope I made it clear in my mail). But the term 'objection' has been used several times in various email threads in a way that was unclear on whether this is a formal W3C objection or just in terms of a strong opposition at a specific point in the discussion. This ambivalence did create turmoil in the past. So we should really try to avoid that, and use this term only when we are close to a possible WG resolution at which point, of course, participants should make it clear that they would formally oppose a specific issue resolution.
The discussion in the mailing list has become a bit too controversial in style here and there, at least for my taste. We should all try to keep our heads cool(er)... That is all. Cheers Ivan P.S. Packing and leaving the hotel, may not be able to react on any of your replies any more:-) On Jun 8, 2012, at 07:48 , Lee Feigenbaum wrote: > [moved off of the RDF WG list, included Richard and www-archive@] > > Ivan, > > I'm a little surprised to hear you say this -- the W3C process [1] is very > explicit that objections are a (perhaps the) key part of determining > consensus, and in the face of a lack of consensus understanding the strength > of the objections is how Chairs ought to evaluate competing proposals. Isn't > it helpful than to evaluate current proposals to know as early as possible > which ones would generate strong objections? > > Lee > > [1] http://www.w3.org/2005/10/Process-20051014/policies.html#Consensus > > On 6/8/2012 9:56 AM, Ivan Herman wrote: >> This is a meta-comment, not especially directed at this mail, just triggered >> by it: can we try to be careful about the usage of the term 'object', >> 'formal objections', etc, at this stage of the discussion? This term has a >> very strong meaning in the W3C process, a recorded formal objection is such >> that, if it is maintained in spite of the resolutions of a working group, >> escalates up to the Director for final arbitration, etc. Its usage has >> already created unnecessary confusion (and adverse reactions) on the >> discussions before and we should try to avoid making the current >> deliberations even more difficult... >> >> Thanks >> >> Ivan >> >> >> On Jun 8, 2012, at 01:51 , Richard Cyganiak wrote: >> >> >>> Hi Sandro, >>> >>> >>>>> I've heard you say two mutually incompatible things: >>>>> >>>>> 1. A Turtle file published at <i> containing graph G is an RDF dataset >>>>> with only named graph <i,G> >>>>> >>>>> 2. A Turtle file published at <i> containing graph G is an RDF dataset >>>>> with only a default graph >>>>> >>>>> Which one is it? It can't be both. >>>>> >>>> If I said (1), it was a mistake. >>>> >>>> I would rephrase (1) as a conditional: >>>> >>>> A. If it is true that a turtle file serializing G is what is >>>> published at <i>, >>>> B. Then the dataset consisting of the named graph <i,G> is true. >>>> >>> -1. >>> >>> We can postulate the existence of a *specific* dataset, let's call it the >>> “web dataset”, and can say that under the condition above the g-pair <i,G> >>> is true in the web dataset. (Formally, this could be done as a semantic >>> extension, let's call it W-entailment (for web). So if A is true then >>> *every* dataset W-entails the g-pair <i,G>.) >>> >>> But I will formally object to anything that defines truth *in general* in >>> terms of dereferencing. This is not a negotiable position. >>> >>> >>>> Statement (2) is close to correct, but I'd change it slightly; it's not >>>> that it "is" a dataset, but that it can reasonably be read as a dataset. >>>> It's a type-conversion thing. A triple can be seen as a (trivial) >>>> graph; a character can be seen as a (trivial) string; a graph can be >>>> seen as a (trivial) dataset. >>>> >>> This is sloppy thinking. They are not the same, and by pretending that they >>> are, you are just confusing matters. >>> >>> >>>> In practice, I see this manifesting in the kinds of APIs one uses for >>>> loading and manipulating dataset. Can give the API a graph when it is >>>> expecting a dataset and have it silently promote the graph to being a >>>> dataset with that graph as its default graph? >>>> >>> The much more interesting case is the opposite situation: What happens when >>> you give a dataset to an API that expects a graph? That's after all the >>> status quo; anyone who goes to the web to load a Turtle file expects a >>> graph, and that's how it's been implemented for the last eight years. If we >>> now define that a Turtle parser must also be able to handle datasets, we've >>> deeply broken every existing implementation. >>> >>> >>>> Alternative, we could define a class of things that is the union of the >>>> class of graphs and the class of datasets -- that would be more crisp >>>> and might be as convenient. But I expect people will be find just >>>> using datasets as those things. >>>> >>> I don't see the point of this. If we define truth for datasets, and >>> consider the default graph as asserted, then an RDF graph is semantically >>> equivalent to an RDF dataset with just a default graph and no empty graphs. >>> That's all we need. But they are not the same. >>> >>> Best, >>> Richard >>> >>> >>> >>> >>>> To be clear: this is speculative. My point is not to say we should >>>> standardize this, but I don't think we should rule it out. >>>> >>>> -- Sandro >>>> >>>> >>>>> Best, >>>>> Richard >>>>> >>>> >>>> >>>> >>> >> >> ---- >> Ivan Herman, W3C Semantic Web Activity Lead >> Home: >> http://www.w3.org/People/Ivan/ >> >> mobile: +31-641044153 >> FOAF: >> http://www.ivan-herman.net/foaf.rdf >> >> >> >> >> >> >> >> >> ---- Ivan Herman, W3C Semantic Web Activity Lead Home: http://www.w3.org/People/Ivan/ mobile: +31-641044153 FOAF: http://www.ivan-herman.net/foaf.rdf
