W3C home > Mailing lists > Public > public-rdf-wg@w3.org > August 2012

Re: A rant about the terminology debate (was: Re: retronyms, Abstract/Maintained Graph)

From: Ivan Herman <ivan@w3.org>
Date: Fri, 24 Aug 2012 11:49:25 +0200
Cc: Sandro Hawke <sandro@w3.org>, RDF Working Group WG <public-rdf-wg@w3.org>
Message-Id: <7FF97956-891B-4239-8408-57717813C956@w3.org>
To: Richard Cyganiak <richard@cyganiak.de>

On Aug 24, 2012, at 11:31 , 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.

I have to agree here, probably because I am, very honestly, extremely tired of the terminological debate.

Coming back to the diagram in the document (and also to our resolution on the last telco that considered that as a guideline): 90% of the terminology there is, in fact, taken over from SPARQL. Whether they are good or bad terms is, in fact, immaterial: they are there, the community uses them (o.k., SPARQL update is not yet that widespread but there *are* usages of it already), have happily survived using them so they are not *that* horrible. We identified one more term that was missing to make the situation more complete, that was the 'RDF Space' in that document. My wish/proposal would be: let us agree in a term for RDF Space (and, frankly, at this moment I do not *really* care what that term is), and let us move on. 

I am sure there will be countless blogs, primers, presentation, etc, that will explain all the niceties. Let them do that. We should just close this.

Ivan


> 
> 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
>>>>>>> 
>>> 
>> 
>> 
> 
> 


----
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
Received on Friday, 24 August 2012 09:50:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:02:06 UTC