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