RE: Contexts? (again)

>> which not only is convoluted & long-winded but also involves the dread
>> reification.

>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!

A very good point, I should have been a little more accurate in my use of
'dread' - I was referring specifically to RDF reification, particularly  in
the context of Jonathan Borden's recent comments :

[[[
>The RDF Semantics politely gives the reification vocabulary no formal
>meaning -- it is in RDF for 'legacy' purposes, but doesn't add anything to
>RDF. In short -- forget it, don't even try. It has no meaning.
]]]


>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.

Ok, but it strikes me as a bit of a fudge to pass this responsibility onto
applications. (I'm certainly not singling out your comment here!) For
instance, most times Seth Russell's plugged his 'Quads' suggestion it's been
shot down in flames or quietly submerged. Yet to maintain some kind of
provenence facility within an app, something akin to quads will be used
internally through relational tables or whatever. What I'd personally like
to see is this made explicit, with guidelines on how such a facility can be
implemented in a consistent, even standard, fashion. It goes without saying
that some formal logic should be behind it, to tie it into the MT. Graham
Klyne's work come close and I have a similar method (hacky fudge!) of my
own. But if what Jonathan said is the case and reification is being quietly
deprecated, then the obvious mechanism within the MT for this very important
facility goes with it.

>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.

I like it! "the time has come for all WellFormedAndTrue statements to come
to the aid of the model" ;-)
I'll have to think about the implications of your suggestion, but to this
non-logician the truth predicate approach does sound promising.

>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.

Familiar names - I'll have a look, thanks.

>(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.)

heh, thanks for that, but I wasn't trying to be at all 'correct' - if you
can have pseudocode then I don't see why not pseudologic ;-)

Cheers,
Danny.

Received on Thursday, 21 November 2002 07:32:23 UTC