W3C home > Mailing lists > Public > www-archive@w3.org > September 2013

Re: defn of Named Graph

From: Gregg Reynolds <dev@mobileink.com>
Date: Wed, 18 Sep 2013 03:29:18 -0500
Message-ID: <CAO40Mi=-cJDU_QrzECZKm8hL88gQ_cU89+hEoprSqHA2P9KvcA@mail.gmail.com>
To: Sandro Hawke <sandro@w3.org>
Cc: Jeremy J Carroll <jjc@syapse.com>, Pat Hayes <phayes@ihmc.us>, www-archive <www-archive@w3.org>
On Tue, Sep 17, 2013 at 4:51 PM, Sandro Hawke <sandro@w3.org> wrote:

> Following that epiphany I had at the end of my last email, here's what I'd
> love to see everyone agree on, more or less:
> == Named Graphs
> An "RDF Named Graph" is similar to an "RDF Graph", but different in one
> important way.

This just does not work.  What you're effectively trying to do is redefine
the English language.  We all know what a named X is - it's an X that
happens to bear a name.  Compare:

     A named function is similar to a function, but different in one
important way.

Nobody would agree to this.

    1.   λx.x+1
    2.   f(x) = x+1

Without question, f names the same graph named by the lambda expression in

   1.  {1,2,3}
   2.  S = {1,2,3}

Again, S names the same set named by the extension expression in 1.   The
point, which is easy to overlook, is that RDF graph expressions - the stuff
we "write down" - are just like lambda expressions or set extension
expressions.  They are names.  Coining additional names (synonyms) via
equations does not change the thing named.


> Like an RDF Graph, an RDF Named Graph contains zero or more RDF Triples.
>  Unlike an RDF Graph, an RDF Named Graph has an identity distinct from
> those triples.  That is, two Named Graphs remain distinct and
> distinguishable entities even if they happen to contain exactly the same
> RDF Triples.

The suggestion that a pair of mathematical entities with exactly the same
extension are not equal doesn't help - it reads like an attempt to redefine

I think I see what you're trying to accomplish, but in my opinion this is
not a good way to do it.  There is no need to invent a new blob of
metaphysics called an "RDF Named Graph" in order to accomodate the way
named graphs are handled in the wild.  You just need clear language - see

> The term "Named Graph" has historically caused some confusion, as some
> people have read the phrase to mean "an RDF Graph which happens to have a
> name".   This reading is not correct, since RDF Named Graphs are not RDF
> Graphs at all.

At this point you have completely lost this reader, and I suspect virtually
every other reader who is not intimately involved in the discussions of the
very, very small group of technical experts trying to figure out what Named
Graphs are.

> Names Graphs also provide a useful semantics for RDF Datasets.  Some RDF
> Datasets, hereafter NG Datasets, have this intended meaning: each (_name_,
> _graph_) pair is a statement that _name_ is a Named Graph which contains
> exactly the triples in _graph_.

Since _name_ is an IRI, this would mean that a Named Graph is (I think you
mean "denotes"?) an IRI value (in "IR"), unless you're abandoning RDF
Semantics.  Above you said that an RDF Named Graph "contains zero or more
RDF Triples".  But the values in IR are logical individuals with no
substantive properties.  In particular, they are not RDF Triples.  So at
this point we do not know what "RDF Named Graph" is supposed to mean.


The greatest differences between RDF Graphs and RDF Named Graphs appear
> when one considers the possibility of them changing over time.    It is
> nonsensical to consider an RDF Graph changing over time, just like it makes
> no sense to talk about the value of some integer, say seven, changing over
> time.   In contrast, it makes perfect sense to consider Named Graphs
> changing: at one point in time the identifiable thing that is a certain
> Named Graph contains some triples and at another point in time it might
> contain different triples.

To me, at least, it makes no sense to consider "RDF Named Graphs" as any
more mutable thatn "RDF Graphs".   They're either mathematical objects or
not; if they are - and they must be - they are immutable.

To me the problem with Named Graphs is primarily a matter of getting clear
on terminology.  I suppose we're stuck with "Named Graph", but there is no
requirement that "name" be construed as a synonym for "denote".  There are
lots of ways of referring to things that can loosely be considered as kinds
of naming; we can think of these in terms of "modes of referring" or the

In particular, there is one mode of referring that seems to capture more or
less perfectly what is wanted with Named Graphs: metonymy.  It already
accounts for the way RDF properties and classes are construed by RDF
Semantics; we can just do the same thing for graphs.

A refresher for those whose rhetorical vocab is rusty: metonymy is when you
refer to something indirectly by referring to something related to it, such
as using a part to refer to a whole or vice-versa.  Not to be confused with
metaphor, which is based on similarity.  An example is "The White House
announced that blah blah blah."  Here "the White House" denotes a building,
but is used to refer to the administration headquartered in the building:
 "White House" ->  building  =>  administration.

This is exactly what happens with RDF properties.  If :p is a property IRI,
then it denotes an IR value, which is not its extension.  That IR value is
mapped to its extension.  Schematically:

    :p ->  [:p]  =>  [[:p]],  where [[:p]] is the extension (a binary
relation) of :p

This means that it is unacceptable to say that :p names its extension by
denotation, but entirely reasonable to say that it refers to its extension
by metonymy, since what it does denote is related to that extension.

Similar considerations apply to RDF class IRIs.  The same language can be
used to accomodate the various ways that "graph IRIs" are used, without
violating any conventions of either English or mathematics.  Schematically:

   :g ->  [:g] =>  [[:g]],  where [[:g]] is the set of triples that is
refered to metonymously by :g

In particular, it is reasonable to treat "named" as meaning "named by
metonymy, not denotation", just as we treat "the White House" as a name for
the administration.  You might want to go so far as to declare that a graph
IRI is a metonym for the graph it refers to.  In fact you'd probably get
the most clarity if you dropped "name" as a verb from your explanatory text
in favor of "refer by denotation" and "refer by metonymy".  Or use
"designate", "label", etc.  Also, there is no need to claim that named
graphs are or may be distinct even if they "contain" the same triples.  If
two distinct IRIs refer by metonymy to the same set of triples, then they
refer (in that mode) to the same graph.  But that has no bearing on their
denotational referencing, which can be different.

Also on this reading there is no justification for treating "RDF Named
Graphs" as a distinct semantic or ontological category.  Named graphs are
just graphs that have been referred to by names, that's all.

Unfortunately, this only serves to highlight the real problem, which is how
to decide which referent - the denotational or the metonymical - is
intended when you say something about the graph IRI.  Compare:

   1.  The White House announced that blah blah blah.
   2.  The White House has 132 rooms.

Easy for a human to disambiguate, but if you want to state facts about a
graph IRI :g, you need some means of indicating which reference you mean.
 One possibility would be to define something like rdf:graphExtension that
would allow us to designate an IRI that refers to the graph by denotation.
 For example:

  GRAPH :g {  ...   }
 :g rdf:graphExtension :h.
 :h :definedBy  :AcmeCorp.

rdf:graphExtension would amount to the composition of the functions in the
schema above:  => . -> :  first follow -> from :g to get [:g], then follow
=> to get [[:g]], which is the graph, and assign that to :h.

Then if you had something like rdfs:Graph,  :h rdf:type rdfs:Graph would

(Or you could just define rdf:extension, which would then work for
properties and classes as well.)

The other use case, where the graph IRI is treated as a "special"
parameter, falls out naturally from [:g] => [[:g]].  In a previous message
Pat gave the example of "graph names which refer to times or dates, meaning
that the assertions in the graph are indexed to that time."  It seems to me
that if it is legitimate to claim that :a :p :b "means" that :p relates :a
to :b, we ought to be able to claim that GRAPH :g {...} means that :g
"applies to" or "indexes" (or something) the graph it refers to, and thus
its contents.  This would always be the case, by virtue of the semantics.


Received on Wednesday, 18 September 2013 08:29:47 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:44:23 UTC