Re: Contexts? (again)

> so as far as I can see can only be done in the RDF model something like
> 
> m3{
> 	{S1} -isFrom-> m1
> 	{S2} -isFrom-> m1
> ...
> 	{S1} -isFrom-> m2
> 	{S2} -isFrom-> m2
> }
> 
> which not only is convoluted & long-winded but also involves the dread
> reification.
> 
> Suggestions?

Don't dread reification.  It's just quoting-after-parsing, which is
logically equivalent to quoting.  Ever try to write a computer program
that didn't use strings?  Heck, putting programs and data in the same
kind of place is the essense of the Von Neumann architecture which
basically all computers use!  That doesn't mean you have to write
programs that modify their own object code, especially not the code
for the routine which is currently running!

RDF certainly has the danger of self-reference loops, but until you
introduce a truth predicate, you're okay, and there's been a lot of
work since Kripke to suggest we can have safe truth predicates with
semantics which match our intuitions.   I expect most applications
will handle de-reification in application code, so they probably don't
need a formal solution to this.

My current suggested truth predicate is WellFormedAndTrue, where being
well-formed includes being able to be re-written in a truth-preserving
manner to a form without negated self-references; this is (as far as I
can tell) what KIF3 had, before they took it out as being unnecessary
for the intended apps.

My current reading material is "The Liar: An Essay on Truth and
Circularity" by Jon Barwise and John Etchemendy.  It starts with a bit
of a rebuke to logicians who throw the baby out with the bathwater on
this subject.   I haven't gotten far enough to understand what
different kind of truth predicate they might suggest.

(BTW, I think the proper name for this kind of {...} construct is
"formula literals."  They may function as a kind of context, but
syntactically they denote logical formulas (which are RDF graphs here)
very much like "..."  constructs denote text strings and [0-9]*
constructs denote numbers.)

    -- sandro

Received on Thursday, 21 November 2002 05:24:29 UTC