Re: A rant about the terminology debate

On 08/24/2012 07:32 AM, Kingsley Idehen wrote:
> On 8/24/12 7:10 AM, Sandro Hawke wrote:
>> On 08/24/2012 05:31 AM, Richard Cyganiak wrote:
>>> Sandro,
>>>
>>> On 24 Aug 2012, at 03:53, Sandro Hawke wrote:
>>>> People will need some way linguistically to distinguish X from Y
>>>> People will instinctively say X to clarify they mean Y
>>>> People rarely mean to only be talking about X, and when they do, 
>>>> they should put the word Y in there
>>>> People should be able to use X when they want to clarify they're 
>>>> talking about Y
>>> That kind of argument is irrelevant. People talk the way they talk. 
>>> They won't pay attention to what we write anyways for the most part. 
>>> We're not in the business of helping them to express themselves.
>>>
>>> We are in the business of extending an existing technical 
>>> specification with clear definitions of a few additional concepts in 
>>> order to promote consistency between W3C specifications and to 
>>> promote interoperability between implementations that already use 
>>> these concepts in some form.
>>>
>>> We'll never get anywhere with this discussion if we entertain the 
>>> crazy notion that we can magically solve all uncertainty and 
>>> enlighten the RDF community with a Great Global Renaming.
>>
>> That's a strawman.  I'm not saying names will magically solve 
>> anything.  It sounds like our disagreement is a matter of degree. I 
>> believe our choice of terms will affect the quality & uptake of our 
>> specs by X%, while you believe it is a smaller amount Y%. Perhaps 
>> X=30 and Y=10.
>>
>> This is complicated by the fact that names interact with mental 
>> models, so sometimes when we're discussing names, I think it turns 
>> out to be a proxy for mental models.     And as we change our models, 
>> our opinions on the best names are likely to change.
>>
>> So, let's put this back in the box for now, and hopefully when we've 
>> got the model solved, we can spend one telecon talking over proposals 
>> and make a final decision.   (I suppose we should give it an ISSUE 
>> number, or broaden ISSUE-14 to include this.)
>>
>> I updated http://www.w3.org/2011/rdf-wg/wiki/Graph_Terminology and made
>> http://www.w3.org/2011/rdf-wg/wiki/Graph_Terminology/Options and I'm 
>> quite happy to let the matter drop for as long as possible.
>>
>>       -- Sandro
>
> Sandro,
>
> How would you map g-box, g-snap, and g-text in formal relational DBMS 
> terminology? Such a mapping would help many. Basically, mapping to 
> relations, sets of tuples, and notation.
>

I'm not really fluent in RDBMS theory terminology.   I do know the 
terminology database app developers use, though, I think -- the kind of 
stuff you find in the Oracle or MySQL manuals (talking about "tables" 
instead of "relations").   In that terminology, I'd say:

   g-box: table (or view)
   g-snap: dump of a table (or view)
   g-snap: not something one normally deals with; either:
       - a state of a table; or
       - a value which is the set of all the rows in a table.

This is more of an analogy than a real correspondence, since a table row 
is not the same thing as an RDF triple, in general.    (You could make a 
Subject/Property/Value table, but the data typing of the value wouldn't 
work right, in general.)

     -- Sandro

> Kingsley
>>
>>> Best,
>>> Richard
>>>
>>>
>>> On 24 Aug 2012, at 03:53, Sandro Hawke wrote:
>>>
>>>> On 08/23/2012 11:22 AM, Richard Cyganiak wrote:
>>>>> On 23 Aug 2012, at 16:00, Sandro Hawke wrote:
>>>>>>> You proposed to redefine "graph" by splitting it into two 
>>>>>>> separate concepts, a mutable and an immutable one.
>>>>>>>
>>>>>>> I propose to instead redefine "named graph" in the same way, by 
>>>>>>> splitting it into two separate concepts, a mutable and immutable 
>>>>>>> one.
>>>>>> You lost me here, sorry.   What's the use case for an immutable 
>>>>>> named graph?
>>>>> I guess I should have said "abstract named graph", sorry if that 
>>>>> caused confusion. Abstract IRI-graph-pairs. The thing that SPARQL 
>>>>> queries operate over.
>>>>>
>>>>>> And it sounds like you're suggesting "mutable named graph" as the 
>>>>>> official term for g-box.  Is that right?
>>>>> Almost. My definition of "mutable named graph" would be:
>>>>>
>>>>> "A *mutable named graph* is a resource, denoted by an IRI, that 
>>>>> has a mutable association with an (abstract, immutable) RDF graph. 
>>>>> The RDF graph is also known as the *state* of the mutable named 
>>>>> graph."
>>>>>
>>>>> The key points are:
>>>>>
>>>>> 1) we insist that it is a resource, so the kind of thing denoted 
>>>>> by IRIs
>>>>> 2) we insist that it is actually denoted by some IRI
>>>>> 3) it essentially has a mutable slot that contains an RDF graph
>>>>>
>>>>> This means it can cover both the terms "RDF space/g-box" and the 
>>>>> term "(name, slot) pair" from the diagram in [1].
>>>>>
>>>>> I repeat my assertion that there is no need to ever talk about 
>>>>> unnamed g-boxes.
>>>> Yeah, this makes sense, but it's not my first or second choice in 
>>>> naming proposals.   Probably wouldn't help to go into why/why not 
>>>> at this point.
>>>>
>>>>>>>> I think the key elements are : (1) we stop using "RDF Graph" as 
>>>>>>>> the
>>>>>>>> canonical, precise term for a g-snap;
>>>>>>> I disagree; "RDF graph" is a perfectly fine term.
>>>>>> I wish.   I can live with it, but I think it's hardly "fine". 
>>>>>> People use it wrong all the time; they say "RDF graph" and mean a 
>>>>>> mutable and/or distinct set of RDF triples.
>>>>> I think by actually defining proper terms for these other things, 
>>>>> and by clarifying that "graph" can mean "any of the above", we 
>>>>> make a solid step towards improving the situation.
>>>> I think you're saying "RDF graph"==g-snap; "graph"=g-snap/or/g-box.
>>>>
>>>> I have a problem with this.  I think people will need some way 
>>>> linguistically to distinguish "graph" in the RDF world from "graph" 
>>>> in the wider world, and the natural way to do that is to add the 
>>>> modifier, "RDF".   So people will instinctively say "RDF graph" to 
>>>> clarify they mean "graph" in the RDF sense (not a bar chart or 
>>>> something).    But with your proposal, they've now accidentally 
>>>> changed to talking about g-snaps.
>>>>
>>>> I think people rarely mean to only be talking about g-snaps, and 
>>>> when they do, they can/should put the word "abstract" in there.   I 
>>>> also think the presence or absence of the modifier "RDF" shouldn't 
>>>> affect the semantics of the term -- people should be able to use it 
>>>> when they want to clarify they're talking about RDF, without it 
>>>> otherwise affecting the meaning.
>>>>
>>>>    -- Sandro
>>>>
>>>>> Best,
>>>>> Richard
>>>>>
>>>>> [1] http://www.w3.org/2012/08/RDFNG.html#fig1
>>>>>
>>>>>
>>>>>
>>>>>> I'm not saying we have to solve this problem, or that we can, but 
>>>>>> I think it would be helpful if we could and I think this proposal 
>>>>>> is our best bet.
>>>>>>
>>>>>>       -- Sandro
>>>>>>
>>>>>>> But we can stress that "RDF graph" is an abstract, unnamed, 
>>>>>>> immutable graph, and that when we talk about "graphs" in general 
>>>>>>> then we may sometimes mean named ones that may or may not be 
>>>>>>> mutable.
>>>>>>>
>>>>>>>> (2) we pick terms for g-box and g-snap that convey the idea 
>>>>>>>> that they are two different kinds of "graphs";
>>>>>>> I disagree; I believe that there is never any need to talk about 
>>>>>>> *unnamed* g-boxes; all the g-boxes we want to talk about are 
>>>>>>> named. Therefore, a term like "mutable named graph" is 
>>>>>>> sufficient to say all that needs to be said about g-boxes.
>>>>>>>
>>>>>>>> (3) we use "graph" if/when we don't mind being ambiguous about 
>>>>>>>> g-box/g-snap.
>>>>>>> I'd rephrase that: We can use "graph" if/when we don't mind 
>>>>>>> being ambiguous about 
>>>>>>> g-snap/abstract-named-graph/mutable-named-graph. For example 
>>>>>>> when we say, "SPARQL Update can be used to copy data from one 
>>>>>>> graph to another". In that case we mean mutable-named-graph.
>>>>>>>
>>>>>>>> On your details....  let me start with:  to you, can you have a 
>>>>>>>> named
>>>>>>>> graph that's not in a dataset (or graph store)?
>>>>>>> As defined in SPARQL (named graph == IRI-graph-pair), no.
>>>>>>>
>>>>>>> But if we allow a term such as "mutable named graph", then yes. 
>>>>>>> A Turtle document on the Web is a "mutable named graph", in that 
>>>>>>> sense. It doesn't have to be in any particular dataset. Well, 
>>>>>>> it's in the Web, and for me it makes sense to speak of the 
>>>>>>> entire web as a "mutable RDF dataset".
>>>>>>>
>>>>>>> Best,
>>>>>>> Richard
>>>>>>>
>>>>>>>
>>>>>>>> I don't usually hear the term used outside SPARQL, so I don't 
>>>>>>>> have much of an ear for that usage.
>>>>>>>       -- Sandro
>>>>>>>
>>>>>>>> Best,
>>>>>>>> Richard
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 22 Aug 2012, at 18:07, Sandro Hawke wrote:
>>>>>>>>
>>>>>>>>> On 08/21/2012 03:33 AM, Andy Seaborne wrote:
>>>>>>>>>> On 20/08/12 16:30, Sandro Hawke wrote:
>>>>>>>>>>> If it wouldn't cause SPARQL too many problems, I'd suggest 
>>>>>>>>>>> we should do
>>>>>>>>>>> the same with dataset, and even allow a dataset to be a kind 
>>>>>>>>>>> of graph, I
>>>>>>>>>>> think, so that the world at large can use the word term "RDF 
>>>>>>>>>>> dataset"
>>>>>>>>>>> for any collection of RDF data (whether or not it's 
>>>>>>>>>>> segmented into named
>>>>>>>>>>> graphs).
>>>>>>>>>> That would be problematic.  "RDF Dataset" is a specifically 
>>>>>>>>>> defined term.  "Dataset" we can be loose about (c.f. VoiD) ; 
>>>>>>>>>> "RDF Dataset" is stressing the tie to a particular 
>>>>>>>>>> definition. You might as well mix properties and triples if 
>>>>>>>>>> you're going to mix things of different "shape".
>>>>>>>>> In the telecon, I mentioned on irc the term "bacronym" but 
>>>>>>>>> what I meant was "retronym". These are terms like "cow milk" 
>>>>>>>>> that arise once some term ("milk") becomes ambiguous (eg 
>>>>>>>>> because of soy milk, almond milk, rice milk, etc).  See
>>>>>>>>>
>>>>>>>>> I take the "radical proposal" to be the recognition that some 
>>>>>>>>> terms are ambiguous and we need to make retronyms to 
>>>>>>>>> disambiguate them.
>>>>>>>>>
>>>>>>>>> Here's a revised proposal:
>>>>>>>>>
>>>>>>>>>    - We pick terms like "Abstract RDF Graph" (gsnap) and 
>>>>>>>>> "Maintained RDF Graph" (gbox) that fit the retronym model.   
>>>>>>>>> It makes it easy, when someone says "graph" or "RDF Graph", to 
>>>>>>>>> think/ask, "do you mean abstract or maintained?"     (I don't 
>>>>>>>>> find these terms quite as ontologically comfortable as g-snap 
>>>>>>>>> and g-box/space/data-source, because it makes them both be 
>>>>>>>>> subclasses of "graph", but I think this approach  works better 
>>>>>>>>> for the community.)
>>>>>>>>>
>>>>>>>>>    - We clarify that in all W3C specs to date, "RDF Graph" 
>>>>>>>>> means "Abstract RDF Graph"
>>>>>>>>>
>>>>>>>>>    - Going forward, we avoid using the term "RDF Graph", using 
>>>>>>>>> either Abstract Graph or Maintained Graph  (with or without 
>>>>>>>>> "RDF" in there).   Or just "graph" when we don't care which kind.
>>>>>>>>>
>>>>>>>>> I think that much of the confusion around the term "named 
>>>>>>>>> graph" comes from a lack of clarity around whether what is 
>>>>>>>>> meant is a "named abstract graph" or a "named maintained 
>>>>>>>>> graph".   I think the latter is much more common; the 
>>>>>>>>> difference doesn't manifest in SPARQL 1.0 because it doesn't 
>>>>>>>>> consider the idea of data changing. In my mind, this proposal 
>>>>>>>>> is our best chance for being able to coherently keep using the 
>>>>>>>>> term "named graph", which seems to be very popular.
>>>>>>>>>
>>>>>>>>> BTW, I think we might also want to define "Frozen" graph, 
>>>>>>>>> which is a maintained graph in the sense that it exists in a 
>>>>>>>>> computer's storage, but which is required to never change.    
>>>>>>>>> This is, I think, mostly what PROV wants to use.
>>>>>>>>>
>>>>>>>>>      -- Sandro
>>>>>>>>>
>>>>
>>>
>>
>>
>>
>>
>
>

Received on Friday, 24 August 2012 16:10:30 UTC