W3C home > Mailing lists > Public > www-rdf-logic@w3.org > May 2001

Re: What do the ontologists want

From: pat hayes <phayes@ai.uwf.edu>
Date: Sat, 19 May 2001 22:46:19 -0500
Message-Id: <v04210105b729d101c79b@[205.160.76.183]>
To: David Allsopp <dallsopp@signal.dera.gov.uk>
Cc: www-rdf-logic@w3.org
(This message somehow never got sent when I wrote it a few days ago, sorry.)

>pat hayes wrote:
>
> > Well, the central puzzle to me in RDF at present is that
> > RDFeification seems to be used for (at least) two very different
> > purposes, and maybe both are needed, so my suggestion would be to
> > find a way to distinguish them. The two purposes are (1) as a
> > data-structuring technique, especially to create complex expressions
> > out of subexpressions, ie as an abstract-syntax construction device;
> > and (2) as genuine reification, ie as a way to write expressions
> > which denote/refer to/mean other expressions.  The RDF literature
> > seems to intend that RDFeification should have the second meaning,
> > but most of the actual uses of it seem to use the first.
>
>Are these in fact the two uses in the RDF Model and Syntax?
>
>A) Reification is introduced (in section 4.1) in order to make
>statements about other statements, for the purpose of using a statement
>without asserting it (Ralph says that Ora is the creator of
>http://foo/bar...).

Unfortunately that immediately makes the confusion I have been trying 
to disentangle. There are two issues here: using a statement (as part 
of some larger statement, typically) without asserting it, on the one 
hand; and making a statement ABOUT another statement, on the other 
hand. The latter is indeed widely called 'reification', (ie the 
statement about which something is said gets reified so that you can 
say something about it) and the RDF spec. seems to mean to refer to 
that; but the reason it gives for using it refers to the first idea, 
which is a completely different notion. Virtually the whole 
literature on logic, linguistic analysis, programming language 
design, parsing and so on - libraries and libraries full of stuff, 
stretching over more than a century - has managed to not make this 
elementary mistake, and to keep this basic and elementary distinction 
clear, so it is particularly frustrating to find that the formalism 
being touted as the fundamental basis for the entire semantic web has 
managed to screw it up so royally.

When one says (in English): "The cat is not on the mat", one is not 
reifying anything. One is simply writing a sentence with a slightly 
more complex syntactic structure than a simple atomic assertion. The 
logical form of this is:
(not (on cat mat)) . Notice this does not assert that the cat is on 
the mat, and neither does it say anything about the sentence "(cat on 
mat)". It does not involve reification at all. Virtually every 
sentence uttered by anyone, and most logical sentences other than 
database entries, share these characteristics. RDF has managed to 
make itself unable to do this, effectively by outlawing syntax.

The "Ralph says..." example is particularly confusing, in fact, 
because ordinary English is often rather careless about these 
distinctions. But when people are being careful (as for example on 
the witness stand), even in ordinary English there is an important 
distinction between direct and indirect quotation. The former uses (a 
rather simple form of) reification, indicated by the quote marks; the 
latter doesn't use reification at all.

Pat Hayes

>
>B) A second usage is then introduced: that of representing groups of
>statements that form part of the same rdf:Description. These are
>statements which _are_ asserted; they are reified just so the
>association between them can be expressed, not because we want to avoid
>asserting them.
>
>[Are we not still making statements about statements here, i.e. saying
>that each statement belongs to a particular collection?]

No, we are not. Or at least, if we are, then we are not doing it in 
the same language that we are using to make the statements themsleves 
in. For example, suppose I want to assert the disjunction of the 
collection: (or A B C). You could describe *that* by saying it 
consisted of a collection of three sentences in a disjunctive 
wrapper, but that description treats the disjunction expression as an 
object: it doesn't assert it. If you want to assert the disjunction 
itself, you need to *use* the disjunctive expression, not describe it.

> > >As I understand it, you attach a timestamp property to the message
> > >object (a resource of type Message); but I'd assume that we intend to
> > >say that the timestamp applies to all individual statements within that
> > >message.
> > >
> > >If so, how are these statements (the actual message content) 'contained'
> > >by the message object, since it can't point at them without reification?
> > ---- )
> >
> > David seems to be clearly thinking of 'reification' here simply in
> > terms of pointers to access a subexpression. Now,  the use of
> > labelled triplet structures to encode graphs, and hence graphically
> > representable datastructures, and hence abstract syntax, is all
> > accepted good work practice in software design, and has been for many
> > years. However, that usage is of type (1), not type (2).
>
>I'm glad I appear to be thinking clearly; I'm not so sure myself 8-).
>
>My intent above is a little confusing in this context; What I want to do
>is say things about individual statements (the time they were made, and
>by whom); which seems to me to be usage (2).

Actually for something as (logically) simple as timestamping, it 
really doesnt matter very much, you can read it either way.  In one 
sense the sentence is timestamped, in the other sense something like 
the proposition (or maybe the communication event, or some such 
thing) is timestamped.

Pat Hayes

---------------------------------------------------------------------
IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
phayes@ai.uwf.edu 
http://www.coginst.uwf.edu/~phayes
Received on Saturday, 19 May 2001 23:46:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:45:38 UTC