Re: defn of Named Graph

On 09/18/2013 04:29 AM, Gregg Reynolds wrote:
>
> On Tue, Sep 17, 2013 at 4:51 PM, Sandro Hawke <sandro@w3.org 
> <mailto: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.

There are lots of words and phrases in English that mean something 
different from what the words, taken literal and individually, should mean.

They suck, but they exist, and this would be adding one more. Pat tried 
to call it a Surface.  I tried to call it a Layer or a G-Box.   But the 
world calls it a Named Graph.

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

Maybe.

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

Right, a Named Graph is in IR.     We need some term for the class of 
things (in IR) which are denoted by the IRIs used as graph names in 
dataset.  What would you propose to call that class of things?

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

I'm in over my head here.   Making some guesses....

So the the URI "http://xmlns.com/foaf/0.1/knows" is a string.  That 
string denotes a property I('http://xmlns.com/foaf/0.1/knows'). That 
property has an extension which is the set of pairs of people who know 
each other.

Sure, that construct makes sense and is what we want.   In particular, 
if it turns out there's a property foaf:hates which HAPPENS to have 
exactly the same extension as foaf:knows, we kind of hope that doesn't 
mean {foaf:knows owl:equivalentProperty foaf:hates}, even if happens to 
be technically true.  I think that's the extensional/intensional 
distinction.

And yes, 'named graphs' are intensional while 'graphs' are 
extensional.    The question is how do we codify and explain that 
behavior in way everyone can understand.


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

I can't blame you for not being willing/able to accept my proposal, but 
I suspect that was my last one, so I'm probably done now. Hopefully one 
of you can sort this all out.    If not, I suppose the world will go on.

        -- Sandro

>
> Gregg
>