Some heresies (was Re: Comments on "SPARQL 1.1 Uniform HTTP Protocol for Managing RDF Graphs")

On Fri, Mar 18, 2011 at 7:43 AM, Kjetil Kjernsmo <kjekje@ifi.uio.no> wrote:
...

> So, the key issue and the root of my confusion is the question: "What does
> the
> URI of a information resource consisting of some RDF triples identify?"

...

> So, my issue all boils down to whether the URI of the stuff that people
> have
> been publishing for years identifies RDF Documents or RDF Graphs.
>
> ...

> Now, I've possibly exposed myself as totally confused about core Semantic
> Web
> concepts, but I do so with the confidence that I'm not a n00b, and if I'm
> confused, I'm probably not alone, and the issue should be properly
> explained
>

Howdy Kjetil,

You are definitely not alone.  Personally, I think the fact that after all
these years this stuff is still so ill-defined strongly suggests that the
standard RDF metalanguage has failed and it's time for fresh approaches.
 For what it's worth, here's my list of heresies:

1.  IRIs in isolation have neither denotations nor meanings.  Or rather,
they denote themselves.  They are nonce symbols, with no meanings; another
way to put this is to say that RDF (and the web) has a symbol set but not a
lexicon.  Whatever meanings they may appear to have based on English-like
fragments discernable in their internal structure is fictitious and
irrelevant.  A human-readable IRI may serve as a mnemonic device for the
human reader, but is just as meaningless as a random string to the machine.
  ("Evening star" has meaning and denotes the planet Venus; "ex:EveningStar"
is a meaningless symbol denoting itself.  "Unicorn" has meaning but no
denotation; "ex:Unicorn" is a meaningless symbol denoting itself.)

2.  IRIs used in RDF graph expressions remain meaningless, but they are used
to label (denote) vertices and/or edges.  This use endows them with
denotation but not meaning.  They denote mathematical objects of a semantic
domain (set-theoretic graphs, normally); they do not denote "abstract
syntax". (ex:EveningStar may denote a graph node; it does not mean "Evening
star".  ex:Unicorn may denote a graph node; it does not mean "unicorn".)

3.  RDF is a graph calculus, not a logic calculus.  RDF triple expressions
do not assert propositions, they construct graphs.  Compare tuple
expressions like (a,b,c) or set extension expressions like {1,2,3}, which
function the same way:  they name (set-theoretic) values, not truth-values.
 RDF allows one to construct triples; it does not allow one to assert
propositions.

4.  Since RDF triples are not statements, they do not assert propositions,
so truth-conditional semantics (model theory) is not only inappropriate but
meaningless.

5.  It also follows that RDF inference is not about truth transfer
(entailment) but about data construction.  The inference rules license the
*construction* of data values derived from declared values by rule.  (cf
proof-as-construction)

6.  RDFS-defined terms such as rdf:type and rdfs:Class, etc. do not carry
the meanings of their English-language components.  Their meanings rest
exclusively on the inference (construction) rules defined (implicitly) for
them, which can be expressed succinctly as transitivity rules, or
alternatively as arrow composition rules.  This is purely a matter of the
graph calculus and has nothing to do with the meanings of the
English-language terms "type", "class", "instance", etc. used in the
(in)formal definition of RDF.  Such terms should be viewed as mnemonic
devices, intended to help the user remember which inference rules apply
where.  (cf. Gentzen "rules of use" as definitions of logical constants)

7.  "RDF Document" is ill-defined.  It seems to mean something like "file",
but if RDF is a graph language it only makes sense if taken as a synonym for
"RDF graph" or maybe "named RDF graph".  But it should probably be
discarded.

8.  The logic of RDF is constructive, not classical.  The Law of the
Excluded Middle is disallowed.  It follows that blank nodes cannot be
defined in terms of existential quantification, and they /do/ exist in
graphs, as unlabeled nodes and edges.  (They can be handled with an
"rdf:This" term construction operator of one optional argument.)

9.  There is no such thing as "RDF knowledge".  The "knowledge
representation" aspect of RDF is a pragmatic /use/ of the language that is
parasitic on the base graph semantics.  It may be a good use of RDF, but the
RDF /language/ itself is nothing more than a simple graph calculus.  Any use
of RDF terms to "represent" knowledge is a matter of application pragmatics,
not RDF semantics.

10.  It follows that debates about what IRIs "mean", IRI ambiguity, what
"RDF knowledge" is, etc., while fun, are also irrelevant to the task of
making software that works.  Machines do not understand meanings, they
manipulate meaningless tokens according to rules whose meaning consists
entirely in their "ruleyness".

11.  Debates about whether IRIs have only one meaning, whether it is stable,
etc. are actually debates about policy recommendations, not language
definition.

12.  "Resource" is a whole 'nother hairball that tends to provoke lots of
philosophizing and hand-waving.  I think it can be rigorously and simply
defined using the type/token distinction, category theory, and intensional
sense, but that's another topic.

At the very least, the approaches outlined suggest fresh expository
strategies, e.g. separating the graph stuff from the knowledge
representation stuff, and avoiding altogether questions like "does
louvre:MonaLisa identify a painting, or a cultural phenomenon, or a woman,
or etc. etc." as beyond scope and unproductive.

Cheers,

Gregg Reynolds