Re: Proposals? Re: use/mention and reification

Dan,

Thanks for your comments ... this is really helping me to understand 
(something).

I now see where I was going wrong, and I agree that reification + deductive 
closure rules isn't going to solve this problem.

However, I'm still deeply suspicious of quotation as the right mechanism, 
and with my new understanding I am now having ideas about how to address 
this problem in a way that doesn't involve using quotation to hide the 
denotation of a URI (-labelled node).  I need to go away and think some 
more... in the final analysis, it may be not-so-different from what you've 
been doing.  I'll come back when I've something more helpful to say.

(Remaining responses below are passing comments on your various points, but 
add nothing of any great significance...)

At 09:10 AM 1/25/02 -0600, Dan Connolly wrote:
>On Fri, 2002-01-25 at 06:31, Graham Klyne wrote:
> > At 06:01 PM 1/24/02 -0600, Dan Connolly wrote:
>[...]
> > Roughly, how I propose to make sense of this is to "contain" reified
> > statements in some kind of context structure and provide some additional
> > deductive machinery (similar in style to the rules used in the MT for RDF
> > schema entailment) to assert the statements thus described.
> >
> >     :Lois :accepts { :Superman rdf:type :StrongPerson } .
> >     :Lois :accepts { :ClarkKent rdf:type :WeakPerson } .
> >
> >     :Reader :accepts { :Superman :sameAs :ClarkKent } .
> >     :Reader :accepts { :Superman rdf:type :StrongPerson } .
> >
> >     :Reader rdf:type :knowsAll .
> >
> > My interpretation here of the "{ ... }" construct is that it is a
> > collection of the reifications of the enclosed statements, reified
> > according to proposal 1.
>
>That's not the intended interpretation of {}. I went over this
>superman case in detail with TimBL, and he agreed that
>
>         :Lois :accepts { :Superman rdf:type :StrongPerson } .
>         :ClarkKent = :Superman.
>
>does *not* ential that
>
>         :Lois :accepts { :ClarkKent rdf:type :StrongPerson } .
>
>i.e. {} are not referentially transparent.

One of the things I am coming to realize is my assumption that anything 
that is asserted in a top-level context is also asserted in any nested 
context.  So I *would* expect the entailment you describe.  In my own 
formulation of this, I placed the '=' statement in an inner context.

OK, I now see the problem with my formulation.  Hmmm... how can I stop 
things "leaking" between contexts?  I need to think about that.

> > I haven't yet had an opportunity to work through all the model/entailment
> > stuff, and I'm aware (for example) that DAML+OIL has found some 
> awkwardness
> > there in dealing with its collection types, but I'm assuming that the non
> > asserted statement "weasle words" in the MT may help if there are any
> > difficulties there.
>
>If you're relying on the "weasle words", then you don't really
>have a formal system.

True.  I was anticipating using them to justify some more formally stated 
variations from the standard MT interpretation.

> > I think a feature with this discussion is that we are trying to employ
> > reification to use using RDF beyond its defined capability, which is
> > basically the expression of facts corresponding to the
> > existential-conjunctive subset of first order logic.  More is needed to
> > express rules and modalities and the consequences of incomplete
> > knowledge.  It's easy enough to see how one can encode these things in 
> RDF,
> > but giving them their intended meaning needs more.
>
>WARNING! In general, the pattern of "I haven't worked out the details,
>but it's easy enough to see..." is a mistake waiting to happen.

Agreed.  (One of my old mathematical analysis tutor's favourite sayings 
was:  "If something is obvious then either it's an assumption or it can be 
proven in three lines".)  The two indicated statements above referred to 
different things.  I have worked out some encodings, but not what it needs 
to give them their intended meanings.  (So, yes, in that sense, nothing 
meaningful (sic) has been worked out ;-)

> > >In fact, it seems axiomatic that for any literal "oo", there's
> > >a statement with that object. i.e. here's an entailment test:
> > >
> > >input: (none/empty)
> > >
> > >output:
> > >         _:ss <http://www.w3.org/1999/02/22-rdf-syntax-ns#object> "oo".
> >
> > I'm not sure why you say this.
> >
> > The above entailed statement says "there exists some resource R such that
> > <R,I("oo")> is in IEXT(I(rdf:object)), in any model of the entailed
> > expression.  I don't see how that is entailed by an empty graph.
>
>Er... that's what I meant by "axiomatic" -- it follows from the
>empty graph.
>
>It's like the axiom of singletons or the axiom of pairs: you
>can't just conclude, based on nothing, that {1} exists,
>or that any particular thing of type Statement exists;
>you have to have something in your logic that says these
>things are in R.

I don't see why I would need or want to conclude that the said resource R 
exists based on an empty graph.  But...

>I'm suggesting that "there is a statement whose object is s" is a
>common truth, i.e. axiom, for any s. [Actually, I'm not
>suggesting that; but I'm reading it into proposal 1.]

... aah, I see what you mean.  OK, if we apply standard RDF MT semantics to 
rdf:subject, etc., then I am compelled to agree.

[...]

OK, I'm veering slightly toward proposal 3.

#g


------------------------------------------------------------
Graham Klyne                    MIMEsweeper Group
Strategic Research              <http://www.mimesweeper.com>
<Graham.Klyne@MIMEsweeper.com>
        __
       /\ \
      /  \ \
     / /\ \ \
    / / /\ \ \
   / / /__\_\ \
  / / /________\
  \/___________/

Received on Saturday, 26 January 2002 05:24:13 UTC