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

Re: defn of Named Graph

From: Jeremy J Carroll <jjc@syapse.com>
Date: Wed, 18 Sep 2013 11:48:51 -0700
Cc: Sandro Hawke <sandro@w3.org>, Pat Hayes <phayes@ihmc.us>, www-archive <www-archive@w3.org>
Message-Id: <8FBCC2A6-582C-438A-8BEF-104032A7EFEB@syapse.com>
To: Gregg Reynolds <dev@mobileink.com>
I like Sandro's text but it is not appropriate for people outside Gregg's  "very, very small group of technical experts" - in the sense that whatever ends up being said about what the naming in named graphs means in the technical specs should be short - much shorter than Sandro's text.

It hinges on what we say about which new vocab item:
- I have suggested rdfs:Graph, rdf:Graph, rdf:namesGraph … and Sandro suggests rdf:NGDataset

There seems to be a hope that if we can find the right sentence to say about the new vocab item, it will be so transparently obviously web 101 that we don't even need the vocab item.


Jeremy J Carroll
Principal Architect
Syapse, Inc.



On Sep 18, 2013, at 1:29 AM, Gregg Reynolds <dev@mobileink.com> wrote:

> 
> 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.  {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 mathematics. 
> 
> 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 below.
>  
> 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 like.
> 
> 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 hold.
> 
> (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.
> 
> HTH,
> 
> Gregg
> 
Received on Wednesday, 18 September 2013 18:49:23 UTC

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