What is truth anyways? was: Re: MISC: Internet Media Type registration: proposed TAG finding

Gentlemen,

I'm getting rather frustrated. Perhaps it is a mistake to write a model
theory for RDF, as it appears too constraining. Perhaps it actually would be
better to let everyone interpret triples as they please -- I mean N3/CWM
appears honestly useful, so why not allow
http://www.w3.org/2000/10/swap/log#Truth to be a _Truth_ in the same sense
that a truth defined by the RDF model theory is a truth (assertion) ? What
is the harm in being so draconian in how we define truth?

Isn't that how the internet works ... let a thousand flowers bloom ... and
so why not allow a thousand truths?

Jonathan


>
> >On Wed, 2002-05-29 at 11:35, patrick hayes wrote:
> >[...]
> >>  >It wouldn't be unprecedented, by the way:
> >>  >
> >>  >   http://www.w3.org/2000/10/swap/log#Truth
> >>
> >>  Wow, scales fall from my eyes!
> >
> >Why is this so crazy? It doesn't seem interestingly
> >different from wtr in KIF.
>
> The difference is fundamentally that the meaning of wtr in KIF is
> specified by a KIF model theory, not by English comments in a
> particular KIF document. So the KIF is (1) mathematically precise (2)
> part of the actual language specification (3) part of a semantics
> (and also, by the way (4) provably equivalent to a complete deductive
> system, although this isnt described in the KIF specs.)  None of that
> is true of the swap file.
>
> >[...]
> >>  Seriously, that document (1) does not define logical truth in any way
> >>  whatsoever (2) says this: - <rdfs:Class
> >>  rdf:about="http://www.w3.org/2000/10/swap/log#Truth">
> >>     <rdfs:comment>Something which is true: belive it as you would
> >>  belive this. Understood natively by cwm in that it will execute rules
> >>  in a formula declared a Truth within a formula it is already taking
> >>  rules from.</rdfs:comment>
> >>
> >>  which seems to indicate that log#Truth in fact is simply supposed to
> >>  mean 'asserted', which is perfectly meaningful, but is not the same
> >>  as 'logically true'.
> >
> >Er... close to that; it's a de-quoting mechanism.
>
> OK, that's fine. However, I note that this isn't specified in the RDF
> spec anywhere.
>
> >  > And in fact, the document does not define *any*
> >>  meanings in RDF, or constrain the RDF interpretations, in any way
> >>  whatsoever. It is just English with RDF decorations added. (The CWM
> >>  code might be said to be a kind of implicit machine-readable
> >>  constraint on interpretations of this vocabulary - along the lines of
> >>  'this means whatever it takes to make CWM produce valid conclusions'
> >>  - but it goes well beyond what an RDF engine would be able to make
> >>  use of.)
> >
> >[...]
> >>  >>  Who discovers this, and how?
> >>  >
> >>  >As explained above, I (i.e. anybody using
> >>  >the framework) use the deployed URI infrastructure
> >>  >to dereference http://www.daml.org/2001/03/daml+oil#UniqueProperty
> >>  >and I see:
> >>  >
> >>  ><rdfs:Class rdf:ID="UniqueProperty">
> >>  >   <rdfs:label>UniqueProperty</rdfs:label>
> >>  >   <rdfs:comment>
> >>  >     compare with maxCardinality=1; e.g. integer successor:
> >>  >     if P is a UniqueProperty, then if P(x, y) and P(x, z) then y=z.
> >>  >     cf OIL FunctionalProperty.
> >>  >   </rdfs:comment>
> >>  >   <rdfs:subClassOf
> >>  >rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/>
> >>  ></rdfs:Class>
> >>  >
> >>  >The comment there is reasonably clear as a constraint
> >>  >on interpretations, no?
> >>
> >>  NO!!! It is not in any way a constraint on interpretations, any more
> >>  than a comment in a program is code.
> >
> >How is that not acceptable as a constraint on interpretations, but
> >stuff like this is?
> >
> >
> >[[
> >for ?D an XML Schema datatype, IO(?O) is the singleton set containing
> >the element of IC(?D) that has lexical representation ?L, provided that
> >there is one, otherwise IO(?O) = { }
> >]]
> >  -- http://www.w3.org/TR/2001/NOTE-daml+oil-model-20011218#3
>
> The difference is that this stuff is in a description of the model
> theory, and is part of the language specification intended to be read
> by humans, not a comment attached to a piece of the formal language
> intended to be read by software. Nobody expects this to be readable
> by machines. But that earlier rdfs:comment isn't in a specification
> document intended for human readers, it's in a piece of formal RDF.
>
> I agree with you that this particular rdfs:comment is so exact that
> it COULD be part of a semantic specification. Unfortunately, however,
> as a matter of fact it ISNT part of a semantic specification. It's
> labelled "comment",  and its not part of a published specification
> document, and it occurs inside some RDF, which is supposed to be
> machine-readable.  Comments, pretty much by their nature, are not
> parts of a formal semantic specification and are not supposed to be
> machine-readable.
>
> >  > A comment is a COMMENT, and that
> >>  is all. YOU can read that and understand it, Dan, because you are a
> >>  HUMAN BEING WHO UNDERSTANDS ENGLISH. The whole point of the semantic
> >>  web is to allow SOFTWARE AGENTS to do a little understanding.
> >
> >Yes, so, I read the comment and write some code.
>
> But we are talking about something that is supposed to be readable BY
> THE CODE, not by YOU. Thats why we are working on all these
> interminable specification documents, right? So that people can write
> code which will process the RDF unambiguously, and all their various
> pieces of code will do the right things with one another. RDF isn't
> meant for people to first read, then having read it, write code to
> interpret it. Its meant to be read by code that was already written
> by people who have never seen the particular RDF graph, but have read
> the RDF spec. Would you expect HTML to work if I had to re-write the
> code of my browser in order to read each web page?
>
> >  > When
> >>  you can write a Perl script that can figure out the content of the
> >>  English comments, then maybe you can claim that the meaning of the
> >>  comments is part of the meaning of the formalism. It still wouldn't
> >>  be part of RDF, but you could call it RDFE .
> >
> >It seems to me to be a perfectly reasonable part of
> >the Resource Description Framework. I guess I'm willing
> >to call it an extension to RDF, if that makes you happy.
> >But it seems pretty arbitrary, to me.
>
> It seems absolutely fundamental to me. Why are we even bothering to
> write a spec for RDF if one can include anything in it by writing
> arbitrary scripts?
>
> >[...]
> >>  >Let's put it this way: does dublin core fit into the framework?
> >>  >Or is RDF+dc an extension? How about a document that
> >>  >uses RDFS, DAML+OIL, and dublin core together? Is that
> >>  >another sort of extension?
> >>
> >>  Dan, you cannot possibly be this obtuse. Surely you know the
> >>  distinction between a language and a set of axioms in that language.
> >>  DC is a set of assertions in RDF, right?
> >
> >No; it's a set of terms defined by a community of practice.
>
> OK, then it isn't representable in RDF. You can't have it both ways.
> If RDF is warm and fuzzy and determined by human societal use, then
> it isn't processable by machines (until we have AI licked). If its
> processable by machines then all the formal meaning in it is
> determined by the machine-processable aspects of the spec: in the
> case of RDF, by RDF entailment of some kind. Of course humans might
> declare in some human-readable way (eg in a comment) that some RDF is
> *intended* by them to mean something, and maybe then they can be held
> to account for having published that and tried by a human jury and
> fined by a human judge and whatever. All true, and all totally
> irrelevant to the machine-processable aspects of RDF meaning. I could
> get prosecuted for writing libelous graffiti, but that doesn't make
> graffiti into RDF.
>
> >There are semantics to the dublin core terms that aren't
> >written in the RDF specs.
>
> Of course. But can they be represented in an RDF graph,  so that
> given the RDF graph and the RDF specs together you can figure out the
> semantics? If not, then claiming that there are such semantics, and
> simultaneously that the dublin core is 'in' RDF, seems to me to be
> close to dishonest. If RDF is a formalism, then RDF can only express
> RDF-expressible content.  And if RDF isn't a formalism, then why are
> we bothering to write all these formal specs that sure make it LOOK
> like a formalism? Are we trying to fool somebody, or what?
>
> (Sorry if I sound like I feel strongly about this, but I do feel
> strongly. Ive been worrying and writing about what it means for a
> formal language to express meanings all my working life, and believe
> me, some pretty silly stuff has already been written; but at least in
> AI we now have a fairly clear overall picture of what it means to
> represent knowledge, including what it DOESNT mean. I joined the RDF
> effort in good faith to try to help make the SW happen. Now I feel
> like Ive been conned into signing a religious manifesto.)
>
> >  > That means that one can
> >>  interpret those DC assertions using the RDF semantics and they mean
> >  > something that approximates to what the DC writers had in mind,
> >>  roughly. If you do that to DAML, you often *don't * get an
> >>  approximation of what the writer of the DAML had in mind.
> >
> >I must be quite obtuse; I don't see any fundamental
> >difference between partial understanding of DC semantics
> >and partial understanding of DAML semantics.
>
> The difference is that you are here making a pun on 'semantics' .
> That word is used informally to just mean 'intended meaning' and
> formally to mean something like a model theory. Choose one sense and
> stick to it. In the second sense, DC doesn't even have a semantics.
> In the first sense, "DAML semantics" could be anything.
>
> Basic AI/KR insight: if you formalize a thought or an idea, you can't
> just assume that what you had in mind is what is actually captured in
> the formalization. You have to examine the formalization carefully,
> poke it and shake it, to see what it really has in it.  Just writing
> "Loves(Pat, Jackie) " does not, by itself, capture that idea that I
> love somebody called Jackie. No amount of talking *in English* is
> going to change this. I can say it means that on my home page, write
> letters to the NY Times about it, put up billboards, stand on street
> corners and yell that that is what it means; none of that *makes* it
> mean that.  The only way to make a formal sentence mean something is
> to say enough *in the formalism* to constrain the interpretations *of
> the formalism* sufficiently, and/or to somehow ground the formalism
> to reality, e.g. by perceptual machinery.
>
> Now, maybe English(/French/Kanji...) meanings could be used as a kind
> of social grounding, so that linking the formalism to NL sentences in
> a way that uses other people's experience as a kind of remote
> grounding is itself a social way of attaching meanings. So I can use
> the name 'Melbourne' with confidence even though I have never seen
> the place, never will, and have no idea what it looks, feels, sounds
> or smells like, because Im pretty sure that other people somewhere
> else have done enough seeing, feeling, listening and smelling to
> ensure that the name pins down a unique referent. That is what your
> vision of the 'greater RDF' sounds rather like. And that is indeed a
> great ambition; I mentioned it (briefly) in a paper I wrote in 1985.
> But we aren't going to achieve that by writing little essays inside
> rdfs:comments; we would need some genuine NL understanding software
> to be incorporated into the semantic web. Then (some of) NL will have
> been integrated into the formalism itself, and that *certainly* will
> not be RDF. Again, don't get me wrong: that's a fine long-term
> ambition to have for the SW. But please don't call it 'RDF', because
> that gives the impression that you are claiming that RDF 1.0, this
> useful but rather wimpy little language, can *already* incorporate NL
> meanings, human intentions, and arbitrary semantics; but in fact, it
> can't, no matter how much we put in the rdfs:comment strings.
>
> Pat
> --
> ---------------------------------------------------------------------
> IHMC (850)434 8903   home
> 40 South Alcaniz St. (850)202 4416   office
> Pensacola,  FL 32501 (850)202 4440   fax
> phayes@ai.uwf.edu
> http://www.coginst.uwf.edu/~phayes
>
>

Received on Tuesday, 11 June 2002 19:53:40 UTC