Re: the term "named graphs"

On 26 Apr 2012, at 20:10, Sandro Hawke wrote:
> I guess by defining (u,G) as a named graph, we're using a figure of
> speech, a kind of synecdoche.  

I suppose.

> That doesn't seem like a good idea of a formal spec, because of the potential to confuse people.

I think it's actually less of a problem in a formal spec, because the term, no matter how weird it may be, has a precise definition.

(Although I note Pat's objection that if we call it “named” then the precise definition has to be in terms of denotation because there is no place for any other kind of naming in RDF.)

> I suppose no one is going to mock us for it because they have much,
> much greater things to mock us for, but it feels absurd and mock-worthy
> to me.   (Sorry, Carroll et al, I don't think this bit has worked out:
> "To avoid confusion ... we distinguish between Named Graphs and the RDF
> graph that the Named Graph encodes or represents."   People, as I hear
> them talk, are not making that distinction.)
> I think nearly everyone who used the term "named graph" is thinking
> about a graph that has a name, not a binding-pair.    

But for most purposes there is no reason to make that distinction. “Just stuff the triples into a separate named graph” works no matter whether you see it the one way or the other. “Graph with a name” and “Graph-name pair” are isomorphic and hence interchangeable for most purposes. It doesn't matter which one you're thinking about in daily life. It only matters when you're working out the precise formal machinery. And there, I really don't see one quirky term as an obstacle to anything.

> just thinking about terminology, I would be much more comfortable with something like:
> 
>        An RDF Dataset ... comprises ... Zero or more name graph pairs.
>        Each name graph pair is a pair consisting of an IRI (the graph
>        name), and an RDF graph (the named graph).

This *is* better terminology, I acknowledge that.

The question is whether discarding the established name, and re-educating the masses, is worth the effort or even possible. Having two different names for the same thing around will also cause much additional confusion. You also need to change SPARQL, and by the time we're done probably other specs too.

As someone who spends lots of time explaining RDF to noobs, I dread having to explain that a Working Group decided to rename something, or that two different specs use two different names for exactly the same thing. Like, what is the difference between an RDF schema and an RDF vocabulary and an ontology? Compared to that, it's easy to come up with a story that explains a weird choice of name in a way that people just accept. Like why it's called an RDF graph when it's actually not a graph but a set of subject-predicate-object sentence-like triples, or why we insist to call everything “resources”.

> And, to be clear, I don't actually care whether *I* am comfortable with
> this.  It's just that usually when something's bothering me this much,
> it's bothering lots of other people too, whether they mention it or not.
> (I know this because they tell me later.)  I will happily shut up in the
> face of credible data that outsiders understand but are not bothered by
> the fact that, by our definition, named graphs are (u,G) pairs, and the
> graphs in SPARQL stores that have a name are not, themselves, "named
> graphs".

Well, a public poll could settle the question.

> Actually, I'll probably just shut up now, having made my case about as
> well as I can.  

For now let's work out what the actual mechanism should be.

> ... and then I forgot my humorous postscript:
> 
> http://en.wikipedia.org/wiki/Gallery_of_named_graphs
> 
> I particularly like the Ellingham–Horton 54-graph

Let's make that the RDF 1.1 logo then?

Best,
Richard


> 
>    -- Sandro
> 
>>> I don't think wordsmithing this section will productive until/unless we
>>> have a shared understand of what we actually want to say, though.
>> 
>> +1
>> 
>> Richard
>> 
> 
> 
> 

Received on Thursday, 26 April 2012 23:13:27 UTC