Re: RDF & Trust & OWL & Layering (was Re: Meaning of URIRefs)

>  > >  > Sure, strong-hint is fine, I guess. But look: suppose you in fact
>>  >>  just said something sensible about _:x, say that it was a cat and
>>  >>  also a Siamese, and suppose some other schmuk said that all Siamese
>>  >>  were dogs. I now have a contradiction derived from three sources.
>>  >>  There's nothing you can do to protect me from believing some nonsense
>>  >>  written by someone else. So no matter what *you* say, *I* need to be
>>  >>  always on my toes to make sure I don't just believe anything people
>>  >>  say using other people's urirefs. For that matter, I need to be on my
>>  >>  toes when reading what people say about their OWN urirefs; there is
>>  >>  lots of silly stuff out there which was written by its original
>>  >>  authors. There are even people who think that emailboxes are human
>>  >>  beings, for example.
>>  >>
>>  >>  >
>>  >>  >If some other web document (not at the animals URI) says that
>>  >>  >animals:Dog is a subclass of animals:Tree (disjoint from
>>  >>  >animals:Mammals), does the reader have any basis for thinking that
>>  >>  >_:spot is more legitimately an animals:Mammal than an animals:Tree?
>>  >>
>>  >>  Strict answer: no. Realistic answer: maybe, because owners of urirefs
>>  >>  are more likely to take some care with what they say using those
>>  >>  urirefs. Bottom line: you, the RDF reader, have to decide who you
>>  >>  trust. Caveat lector.
>>  >
>>  >I don't think it needs to be so bleak.
>>
>>  I don't see this prospect as in any way 'bleak'. Its the normal adult
>>  human condition: you don't necessarily believe everything you hear.
>>
>
>But it is not the normal condition for a computer program.

I agree, but then we aren't talking about computer programs any more, 
right? Computer programs can't read information in NL comments, after 
all.

>  In
>general, programs don't deal with trust -- their outputs are as
>trustworthy as the least trustworthy of all their inputs (and their
>code itself).
>
>And of course the Semantic Web is intended largely for programs to
>use.  It is not practical for a human-level judgement to be made about
>the trustworthiness of every input, is it?  That's the bleakness I was
>referring to -- the prospect of needing human judgement everywhere.
>
>With the right architectural choices (which I'm advocating here), it
>is not necessary.

Of course it is. We have NO MEANS of automatic judgement of 
trustworthyness at present. Providing any kind of endorsement links 
isn't going to provide it, since all it can do it to allow A to tell 
C that A trusts B; but how is C going to decide to trust A in the 
first place?

>
>>  >I think people can handle
>>  >being dubious and weighing trust about a small number of sources,
>>
>>  I agree, but....
>>
>>  >and
>>  >if we have some kind of imports mechanism, that's all they'll need to
>>  >do.
>>
>>  ...they can do that without getting involved with 'imports' or
>>  similar nonsense. All that anything that YOU can say cannot give me
>>  any more confidence in anything else than I already have in you
>>  (other than by through a kind of Googlish weighting scheme, in which
>>  case your veracity is decided by your peers in any case. )
>>
>>  >
>>  >Imagine if the HTML web had two kinds of links: links to agreed-with
>>  >documents and links to not-necessarily-agreed-with documents.  People
>>  >wouldn't have to shift trust-gears when following the first kind of
>>  >link.
>>
>>  Yes, they would, because I might trust you as a tracker of current
>>  news without trusting your actual opinions (I actually know people
>>  like that, I swear), or vice versa (ditto).
>>
>>  >I suggest that this is largely the case; aside from
>>  >directory-style or search-result-style pages, links of the second type
>>  >are almost always clearly marked.   (Graphic style is also heavily
>>  >used; users re-engage their judgement when they come to a page that
>>  >looks very different.)
>>  >
>>  >Imagine users asking questions like "According to The Times, Is Dubya
>  > >President?".  The Times judges the trustworthiness of many sources, so
>>  >users don't have to.
>>
>>  Right, but that's a judgement about *the Times*, not about the Times'
>>  opinions about who to trust.
>
>I'm suggesting that for ease-of-use those should often be lumped together.

I think that would be a very dangerous principle to build into the 
fabric of the SW.

>
>>  >  (Of course users may chose to, if, for instance,
>>  >they don't really trust The Times.  But they shouldn't always have
>>  >to.)
>>
>>  Fine. Of course people will use reasoning like this. I don't see how
>>  'importing' helps with this, however.
>
>If you don't want to lump thing together, it probably doesn't.
>
>>  >So RDF could really use a way to say another document is true.  It
>>  >might turn out to be owl:imports, or the URI-Ref mechanism I'm
>>  >proposing, or something else....
>>
>>  RDF is predicated on the (admittedly naive) assumption that all
>>  documents are true. Saying so explicitly doesn't add anything to that
>>  (unless you secretly don't believe that all documents ARE true, in
>>  which case you probably shouldnt be using RDF, but should wait for a
>>  more useful language like OWL to come into general use.)
>
>I'm very surprised to hear you say that.   (especially since they're
>written words :-)
>
>1) I see no such predication in RDF.   I hear lots of people talk
>about RDF applications which keep track of where data came from, so
>it can be properly weighed for trustworthyness.  You saw Mike Dean's
>SONAT presentation, where he talked about using a form of reification
>to track sources, and I can't begin to count the number of times I've
>heard people talk about all this.  This applies to trusting machine
>reasoning and accuracy of data, as well as the more-obvious issues of
>identity and intent of information providers.
>
>Of course RDF itself (not counting it's broken reification mechanism)
>doesn't have any direct support for this stuff.  But it doesn't really
>need to; source-tracking can be built around or on top of RDF in each
>application.

That is all that I meant. The RDF knows nothing about this. If you 
want to perform reasoning about trustworthyness, you had better use 
something else.

>
>Are you just being precise about what's in the MT -- that the language
>itself has no direct support for talking about trust issues -- or are
>you really saying that people who want to track trust (like seemingly
>every RDF user I know) should not be using RDF?

OK, maybe I overspoke there a little and expressed myself too 
colorfully. BUt I do think that we need to draw a distinction 
somewhere between what RDF can support (in this incarnation) and what 
are the open issues and deep problems that need to be solved for the 
future of the SW. Of course trust is central and we are all going to 
have to come to terms with it. But nothing, as far as I can see, in 
RDF or anywhere in the history of RDF or the documentation 
surrounding RDF has seriously considered these issues. So I think it 
would be a very serious mistake to suddenly invent an ad-hoc solution 
and incorporate it into the standard a few weeks - nay, a few *days* 
- before final call, without such a very deep and far-reaching issue 
being given very careful and mature consideration. And I think it 
would be only honest to tell the world that in its present 
incarnation, RDF has no mechanisms or expressiveness devoted to this 
issue of how one says that a source is to be considered trustworthy, 
and (therefore) implicitly assumes that all sources of RDF-encoded 
information are equal.

>2) OWL is a different language from RDF only in the sense that English
>using the word "Aardvark" is a different language from English which
>does not use the word "Aardvark".

Nonsense. It is a completely different language with a completely 
different model theory and a completely different proof theory. There 
is an RDF encoding of OWL, which by virtue of considerable effort has 
been given a semantics which allows it to be considered an extension 
of RDF, but this 'extension' is about an order of magnitude more 
complex to state than the semantics of RDF itself. If one were to 
write out the full semantic conditions for OWL/RDF, only about 10% of 
it would cover all of RDF(S). It would be more accurate to say that 
RDF was a tiny subset of OWL/RDF than that OWL is in any reasonable 
sense an extension of RDF.

RDF is at best a primitive NOTATION with an elementary semantics. The 
fact that other languages can be encoded into this notation, with 
some difficulty, does not make them into mere RDF namespaces (and in 
fact even the idea of encoding in RDF may not be true if the RDF core 
WG decides not to include list semantics in the RDF spec)

>OWL offers precise definitions of
>some few-dozen "words" which allow people to say things in RDF which
>they could not say otherwise, unless they defined some of their own
>words.

It does far more than this. If this were all it did, then it would be 
impossible to encode negation in OWL. And they cannot define their 
own words, in this sense, by the way, and still conform to the RDF or 
OWL specs. If I define a word to mean something that cannot be 
expressed in RDF (say) , then there will be entailments involving 
that word which are not RDF-valid and hence are not sanctioned by the 
RDF specs. Similarly for DAML, OWL, KIF, FOPC, type theory, etc.; 
name your formalism, the point is the same.

>
>I meant to jump on this earlier, when you said that OWL and DAML were
>"other KR languages [not RDF]".[1]  I can see why you might call them
>different languages (natural language using technical jargon is kind
>of another language), but that's also misleading.
>
>...
>
>The vision of RDF is that it's another solid step up the semantic
>ladder,

There is no such 'semantic ladder'. This idea is the figment of 
someone's imagination; someone, I might add, who does not actually 
know much about semantics. There isn't a Church's thesis for meaning: 
you can't build it all up from some simple core mechanism by adding 
layers each implemented in the lower ones.

>where bits and ascii/unicode are lower steps.  (Some people
>put XML as a step here; I think it's just a step sideways.)  This step
>puts us at the semantic Web.  At this step we have one single approach
>to structuring (triples, binary relations), and one form of naming
>(URI-Refs) [plus literals, but they're 90% carbohydrates].  Every
>additional feature you might want to add, like the features of RDFS,
>OWL, DAML+OIL, DC, CC, RSS, etc, is added by picking some identifiers
>and fixing their meaning.

You might as well say that we have character strings, and all of 
literature is just picking some  of the strings and fixing their 
meaning.  Kind of true, in a desultory half-baked shallow 
undergraduate way, but not an observation on which to try to build a 
technology.

The difference between the RDF//RSS(OR DC or CC) and RDF//OWL 
relationships is that the latter, but not the former, changes the 
notion of valid inference. RSS is a set of axioms, in effect, written 
*in* RDF. OWL (that is, the OWL semantic conditions) cannot be 
written in RDF.

>This thread has been about the fact that the approach of fixing their
>meaning by making a W3C working group does scale.  This is just fine;
>the URIs in the URI-Refs allow us to fix the meaning via documents on
>the web.  That scales just fine.  Anyone with a website can define
>their own vocabulary for ontology, rules, IPR licensing, syndication;
>others can it those terms in their RDF, and it all scales and works.

We have no idea whether or not it will work or how much of it will 
scale, actually. But if we allow anyone to define meaning in any way 
they like, then I can guarantee that it will not work at all, at any 
scale.

Pat
-- 
---------------------------------------------------------------------
IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola              			(850)202 4440   fax
FL 32501           				(850)291 0667    cell
phayes@ai.uwf.edu	          http://www.coginst.uwf.edu/~phayes

Received on Monday, 28 October 2002 16:30:28 UTC