- From: pat hayes <phayes@ai.uwf.edu>
- Date: Wed, 16 May 2001 20:46:58 -0500
- To: "Jonathan Borden" <jborden@mediaone.net>
- Cc: "Graham Klyne" <GK@ninebynine.org>, <www-rdf-logic@w3.org>
>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