Re: Proposals? Re: use/mention and reification

At 06:01 PM 1/24/02 -0600, Dan Connolly wrote:
>On Thu, 2002-01-24 at 04:10, Jan Grant wrote:
> > Can we get small amounts of words to describe these please? Currently
> > there seem to be three proposals knocking around, with a possibility of
> > others: (insert "this WG resolves that..." in front of all these)
> >
> >
> > Proposal #1:
> >
> >       A resource R in an RDF graph G is said to be the reification
> >       of the statement
> >               S P O .
> >       iff there exist in G the following statements:
> >
> >               R <rdf:type> <rdf:Statement> .
> >               R <rdf:subject> f(S) .
> >               R <rdf:predicate> f(P) .
> >               R <rdf:object> f(O) .
> >
> >       where f is simply the identity function.
> >
> > Objections to this thus far appear to be (apologies if I'm putting words
> > in people's mouths here):
> >
> >       danbri: objects on the basis that the intended interpretation
> >       associated with the "utterer" of S P O may assign different
> >       denotations to S, P and/or O - in other words, this is "broken"
> >       when reifying statements taken from different sources in the
> >       same graph (is that accurate, Danbri?)
> >
> >       danc: objects on the grounds that there's a use/mention
> >       problem here, that it's hard to see how to make a MTetic
> >       interpretation of this work. (again, correct me if I'm wrong).
> >       (See his earlier messages on this) (- If there isn't a way
> >       to make this make sense, then this seems to be a showstopper
> >       objection)
>
>No, it's not a show-stopper objection; I don't see a conflict
>between Proposal #1 as stated above and the model theory.

I agree.

>I just don't have any use for that sort of reification;
>i.e. I don't see why it's in the spec.
>I on behalf of the W3C Semantic Web Advanced Development group,
>I think. (I should double-check with the rest of the group.)
>
>If other folks find it useful (or if we're prepared to
>accept it as the best interpretation of the current spec
>or whatever), then I don't object.

I have always assumed it worked that way, and much of my thinking has 
proceeded on that assumption, but I'm not yet ready with concrete code to 
demonstrate my point (but something is under construction).  I agree that 
on its own (i.e. without some additional deductive machinery) there's not 
much one can do with this, but I don't see that quoting the URIs really 
changes that.

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.  Below, I use :contains to indicate containment in 
the collection.

The following cannot be expressed directly in RDF:

    ?x :accepts ?y .
    ?x rdf:type :knowsAll .
    => ?y rdf:type :trueContext .

    ?x :sameAs ?y .
    => ?y :sameAs ?x .

    ?x :sameAs ?y .
    ?x ?p ?o .
    => ?y ?p ?o .

    ?r rdf:type rdf:Statement .
    ?r rdf:subject ?s .
    ?r rdf:predicate ?p .
    ?r rdf:object ?o .
    ?c rdf:type :trueContext .
    ?c :contains :r .
    => ?s ?p ?o .

but on adoption of these rules, one can deduce:

    :ClarkKent rdf:type :StrongPerson .

(now an asserted fact, not in a context) in such a way that it doesn't 
contradict with the assertion of Los's belief of { :ClarkKent rdf:type 
:WeakPerson }.

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.

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.

Thus, I think any attempt to fully resolve the reification problem within 
our current charter will, at best, be incomplete.

>Or... hmm... while I don't see a big conflict with the
>model theory, I do see a bunch of stuff that should
>be added to the model theory to describe this idea
>of reification, and it looks really ugly.

Some additional closure rules, maybe.  I don't see that looking 
particularly ugly.

>Here's an entailment test:
>
>input:
>
>         <msgid:s@example> <msgid:p@example> "o".
>
>does it rdf-entail this?
>         _:ss <http://www.w3.org/1999/02/22-rdf-syntax-ns#object> "o".
>         _:ss <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
><http://www.w3.org/1999/02/22-rdf-syntax-ns#Statement>.
>
>?
>
>The way I read proposal 1, it does.

Yes, I think so.  Roughly, I read the entailment as "there exists a 
statement which has "o" as the value of its object property".

>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.  The only 
RDFS-entailments on an empty graph that I can see would be the "common" truths:

rdfs:Resource rdf:type rdfs:Class
rdfs:Literal rdf:type rdfs:Class
rdfs:Class rdf:type rdfs:Class
rdf:Property rdf:type rdfs:Class
rdf:type rdf:type rdf:Property
rdf:type rdfs:domain rdfs:Resource
rdf:type rdfs:range rdfs:Class
rdfs:domain rdf:type rdf:Property
rdfs:domain rdfs:domain rdf:Property
rdfs:domain rdfs:range rdfs:Class
rdfs:range rdf:type rdf:Property
rdfs:range rdfs:domain rdf:Property
rdfs:range rdfs:range rdfs:Class
rdfs:subPropertyOf rdf:type rdf:Property
rdfs:subPropertyOf rdfs:domain rdf:Property
rdfs:subPropertyOf rdfs:range rdf:Property
rdfs:subClassOf rdf:type rdf:Property
rdfs:subClassOf rdfs:domain rdfs:Class
rdfs:subClassOf rdfs:range rdfs:Class

and statements entailed by them.  None of these contains a literal object, 
and none of the rules for deductive closure introduce any node labels that 
are not already used in the graph.

(With reference to 
http://lists.w3.org/Archives/Public/www-archive/2002Jan/att-0007/01-RDF_Model_Theory.htm)


> > Proposal #2: (Danbri or danc to fill in the blanks..?)
> >
> >       Looks like proposal #1 but f is defined differently.
>
>yeah... f(X) is quote(X)
>
> >       f(X) = X        if X is a literal
>
>umm... I'm not sure how to quote literals.
>
> >       f(X) = ?        if X is a URI-labelled resource
>
>I was thinking
>   f(<http...>) = "http:..."
>
>but I didn't consider quoting literals and blank nodes.
>Blech.

I must say that these problems make this approach look even less attractive 
to me.

> > Proposal #3:
> >
> >       this WG resolves that it's never heard of an eleven-letter
> >       word beginning with "R". (DanC's option A)
>
>I find that acceptable.

I could live with this... I've tended to invent my own vocabulary in any 
case for reification-like constructs.  But can we make the defined 
vocabulary simply go away?

#g


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

Received on Friday, 25 January 2002 08:25:14 UTC