Re: What do the ontologists want

>pat hayes:
> >
> > PS. There seems to be an implicit assumption in some of the RDF
> > literature that the only two things to do with a sentence (triple)
> > are to either assert it or to reify it, so any use that doesnt
> > involve asserting a triple must reify it. This is just wrong. Logical
> > notation is full of examples of sentences being used but not being
> > asserted. The simplest is probably negation: when one writes (not P),
> > P is being used (not mentioned or reified), but it is not being
> > asserted: on the contrary, in fact. Now, it might be that RDF is
> > incapable of making this distinction. So much the worse for RDF, if
> > so.
>
>*light goes off in head*
>
>you are absolutely correct.
>
>note that my use of statements in _fragment identifiers_ is _syntactically
>distinct_ from statements in XML syntax.
>
>The RDF 'model' (in the current RDF usage of the term 'model') is a set of
>triples. No partition is provided that distinguishes triples that are
>asserted vs. merely being used. Current RDF 'reification' is a technique
>that allows a statement to be represented without being directly contained
>(hence asserted) in the model.
>
>by introduction of a distinct syntax, one that allows the formation of a
>_URI reference_ that directly represents, quotes if you will, a triple, such
>a triple is partitioned from the triples that are asserted (hence my thought
>is that this mechanism is compatible with the current RDF abstract syntax)
>
>What you are suggesting appears to require reworking of the RDF model. Any
>suggestions on how to best do this?

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. (For 
example, the use of RDF triplet structures to encode lists in DAML, 
or cf. the remarks from David Allsop's recent message to Jim Hendler 
on 'tagging':
----
>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).

You want suggestions. I would suggest making a distinction between an 
expression, and its encoding as a set of RDF triples, and to add to 
RDF some conventions for 'larger' kinds of expression: that is, give 
it an ability to construct recursive syntax. Maybe this could be done 
in RDFS, leaving RDF alone; the only suggested change then would be 
in the metatheory, rather than the formal language itself. Rather 
than describing RDF triples as having relational meanings, in 
general, one would describe them as encoding (according to some 
accepted conventions, which might allow the single-triple case, of 
course) syntactic structures to which relational meanings can be 
attached. "Reifications" that are being used as pointer structures 
could simply be called pointer structures; complex expressions could 
have subexpressions without getting use and mention confused with one 
another, and the semantics could be made clearer; and still 
everything would in some sense BE just sets of triples, in much the 
way that LISP code is all just lots of dotted pairs. (I would however 
suggest inventing a better surface syntax. It would be hard to come 
up with a worse syntax than RDF; you could do better by throwing 
darts blindfolded. Tim Berner-Lee's N3 is one way to go, for example, 
but there are all kinds of ways to make readable surface syntaxes. It 
could still be XML-compliant.)

A minimal step in this direction would be to distinguish a 
subexpression pointer from a continuation pointer (think car and cdr 
in LISP) from a (genuine) reification reference. Particular kinds of 
expression and subexpression can then be distinguished by their 
'relation' label. (I suspect that  genuine reification will have 
rather limited utility, if these other uses of RDFeification are 
separated out and made explicit, but that is only a prediction and I 
would be happy to be proved wrong. ) For example, one obvious kind of 
syntactic structure might be a bag, encoded as a linear sequence of 
triples each marked as a baggish-subexpression, with pointers to the 
element of the bag and the rest of the bag. This is an instance where 
all the continuing subexpressions have the same syntactic type as the 
main expression; more complex kinds of assertion would require more 
elaborate patterns, but these techniques are all well-known. and 
widely used in interpreters, parsers, and so on.

One thing that is required, by the way, is something like LISP's 
'nil': a universal  end-dongle that is used to terminate structural 
recursions. That ought to be easy to add.

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 Wednesday, 16 May 2001 21:46:58 UTC