Re: defn of Named Graph

On Wed, Sep 18, 2013 at 9:37 AM, Sandro Hawke <sandro@w3.org> wrote:

>  On 09/18/2013 04:29 AM, Gregg Reynolds wrote:
>
>   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?
>

But that's not what I said.  I agreed that _name_ denotes an IR value, not
that a "Named Graph" does.  If I understand you correctly, you want to
treat a "Named Graph" as a distinct semantic and/or ontological category
disjoint from both IRIs and graphs. That's the crux of the problem, at
least as I see it.  It means you have to introduce another semantic
category into the semantic domain.  All I'm saying is that you don't need
to do that if you treat the relation between a graph IRI and the graph that
it names (refers to, labels, whatever) in the same way you treat property
IRIs and the binary relations they name (refer to, label, whatever).

But even that doesn't complete solve the problem, because the official RDF
semantics, as it stands, cannot accomodate graphs.  It provides for
denotations of IRIs and triples, but not sets of triples.  That make sense,
since the syntax provide no means of expressing graphs.  There's no "graph
extension" syntax - no way to write { :a :b :c. }.  (You might find it
useful to look at the way the Z standard defines set extension syntax (ISO
13568:2002, free at
http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html)).



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

Yes.


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

In fact *every* name has an intension and some - those that denote, i.e.
not "Pegasus" - also have extensions.  Even symbols like '2' or 'x'.  So
"Named Graphs", or as I prefer, names of graphs, are not special.  They're
just like names of properties or classes.  One way - the only way I can see
- to get clarity is to pair an explicit syntax with a formal semantics.
 (And to choose the explanatory language very carefully, of course.)  The
WGs may not be able or willing to do this officially, but if the idea is to
provide some kind of explanation, this is one possibility.

...

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

I'm entirely willing to accept your proposal.  I'm not posting in order to
bend the world to my will, but to try to clearly explain one way of looking
at things, in hopes of reaching mutual understanding.

Anyway, thanks for the response.

Cheers,

Gregg