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.
Hmm... it seems that you come to the same conclusion,
but you think you can get there via reification in the
sense of proposal 1. I don't think you can; according
to proposal 1 (and your use of contains for {})
the first line would expand to
:Lois :accepts _:c1.
_:c1 :contains _:s1.
_:s1 rdf:subject :Superman.
and then by the rules for substitution of
equals for equals as you give below, we'd
have
_:s1 rdf:subject :ClarkKent.
i.e. lois accepts that Clark Kent is strong...
which is not what you meant, right?
> 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.
If you're relying on the "weasle words", then you don't really
have a formal system.
> 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.
In the particular case of RDF and reification, especially so.
I was under this illusion for some years, but when I finally did try
to work out the details (during the development of
http://www.w3.org/2000/04shoe-swell/ ) I discovered that it's
not easy at all to encode these things in RDF... well, perhaps
there are easy ways to do it, but they don't look anything
like reification per proposal #1.
> 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.
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.
Maybe you can come up with closure rules that don't work this way,
but I don't see how, at a glance.
> The only
> RDFS-entailments on an empty graph that I can see would be the "common" truths:
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.]
> (With reference to
> http://lists.w3.org/Archives/Public/www-archive/2002Jan/att-0007/01-RDF_Model_Theory.htm)
[... difficulties with proposal 2 omitted...]
I withdraw that proposal; it's incomplete,
and it involves more design work to complete
than I'm interested in at this stage.
> > > 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?
Well, if you take our decision on aboutEachPrefix as precedent,
we can.
Now that was just syntax, while subject/predicate/object/Statement
are real live properties and Classes. So I'd agree we can't
pretend we never heard of them. I'd suggest we say that
they're normal properties (like rdfs:label) but that's all;
they're not magically produced from syntactic uses
of bagId or anything like that.
--
Dan Connolly, W3C http://www.w3.org/People/Connolly/