- From: pat hayes <phayes@ai.uwf.edu>
- Date: Fri, 25 Oct 2002 16:13:26 -0500
- To: Sandro Hawke <sandro@w3.org>
- Cc: www-rdf-interest@w3.org
>This reply to [1] is moved to this list as requested in [2].
>
>***** INTRODUCTION
>
>As usual it's hard to address logicians, programmers, architects,
>process managers, and personal issues all in the same message. I'll
>simply address Pat here, as best I can.
>
>In my previous message I said that (given my namespace bindings)
> _:x rdf:type animals:Dog.
>entails
> _:x rdf:type animals:Mammal.
>
>Let be break down that claim of entailment into it being (1) feasible,
>(2) desirable, and (3) already established. I only address feasibility in
>this message; if that can be established, I can go on to (2) and (3)
>as necessary.
>
>There's a trivial kind of feasibility, where we define any use of
>rdf:type to entail everything, but of course that's not what I mean.
>So I'll restate my desired conclusion:
>
>The RDF specs can define "RDF full entailment" so that
> _:x rdf:type animals:Dog.
>entails
> _:x rdf:type animals:Mammal.
>but not
> _:x rdf:type animals:Fish
>
>Again, the question of whether they *should* or *essentially-already-
>do* define it thus is left for later.
>
>My argument will go like this: First I'll translate both the RDF and
>the URI-References into natural language expressions to show a similar
>entailment does hold. Then I'll introduce reasoning using the state
>of the web. Then I'll show (er, suggest) that my natural language
>translations of URI-References are feasible. I think the other parts of
>my natural language translation are pretty obvious.
>
>I might need to say something more about how what definitions are, but
>I think you already granted me that. It's also addressed in other
>mail [3].
>
>Following this, I do a point-by-point reply to your e-mail, except
>where it seems clearly addressed by this new beginning. The
>point-by-point area does have some gems (IMO), like a proposal for
>rdf:definition to make more-clear the role of natural language in the
>system, and an analysis what's required for floating semantics to
>work.
>
>***** Entailment in Natural-Language Translation
>
>So, in natural language, here is the state of an example universe:
>
> Doc-1 is this string:
>
> The class herein called "Dog" is a
> subclass of the class herein called
> "Mammal".
>
> Claim-1a is expressed by Doc-1.
>
> Claim-1b: Doc-1 (as defined above) is on the web at address URL-1.
>
> The creator of Doc-1 and the controller of URL-1 is "Nancy" (the
> namer).
>
>
> Doc-2 is this string:
>
> The thing herein called "spot" is a member
> of the class called "Dog" in the document
> on the web at address URL-1.
>
> Claim-2a is expressed by Doc-2.
>
> Claim-2b: Doc-2 (as defined above) is on the web at address URL-2.
>
> The creator of Doc-2 and the controller of URL-2 is "Arthur" (the
> author).
>
>
> Proposition-1: The thing called "spot" in Doc-2 is a member
> of the class which is called "Mammal" in the document on the web at
> address URL-1.
>
> Proposition-2: The thing called "spot" in the document on the web
> at address URL-2 is a member of the class which is called "Mammal"
> in the document on the web at address URL-2.
>
>It seems clear to me that Proposition-1 logically follows from
>Claim-1b and Claim-2a.
I disagree. In fact, I will state it as a fact (not an opinion) that
it does not follow *logically*, since neither of those claims (1b and
2a) use the term "Mammal", so it follows by the Craig interpolation
lemma that proposition-1 does not follow from them.
So I know that the sense of 'entailment' you have in mind here is not
logical entailment. I also do not think it is 'natural language'
entailment, in any reasonable sense of that rather vague term, for
much the same reasons. Lets take the example off the web and see what
it looks like. Suppose I have Doc-1 written on a piece of paper and I
brandish this piece of paper at someone and assert 'This piece of
paper exists and Spot is a Dog (in the sense used on this piece of
paper)' which is analogous to your 1b + 2a. Now, what is on the paper
is irrelevant: it still doesn't follow *from what I said* that Spot
is a Mammal. It does of course follow from what I said *and what is
written on the paper*, but I didn't say what was written on the
paper: I just brandished it and claimed that it existed. I was
talking ABOUT it, not asserting it. That is just like saying it is on
the Web. Its being on the Web, on the one hand; and what it actually
asserts, on the other hand, are different propositions. The
conclusion follows from one, but not from the other.
If you want to say that the better analogy would be for me to
brandish the paper and say 'Spot is a dog and this document <Pat
waves paper> is true' then maybe one could make a case: but still,
the conclusion would only follow if you were to explain how to
interpret "this" in this context so that asserting something about
the indexical amounted to asserting the content of what you find when
you *use* the indexical to index; and that would be (1) hard to do
properly and (2) unnecessary, since the right entailment story is at
hand: the conclusion follows (logically) from what you said and what
is written on the paper. We don't need to get involved with the
brandishing stuff (the URL accessing and dereferencing) in order to
say exactly what is entailed by what.
> To rephrase that: if Claim-1b is true and
>Claim-2a is true, Proposition-1 must be true.
> Another rephrasing: the
>conjunction of Claim-1b and Claim-2b entails Proposition-1.
>
>Do you agree this is so?
No, see above.
>
>I'm not so interested in Proposition-2, but it logically follows from
>Claim-1b, Claim-2a, and Claim-2b. It talks about URL-2 (rather than
>the claims of Doc-2) so it only follows if we include the connection
>between Doc-2 and URL-2.
So it doesn't follow logically.
>
>***** Reasoning About the State of the Web
>
>The claims 1b and 2b are of quite a different nature than, say, 1a.
Indeed. I would like to see a more detailed analysis of them. They
seem very difficult and subtle claims, ones which blend together
indexicals, meta/object language confusions and unspoken assumptions
about the 'state' of 'the web', all of which cry out for more
analysis and exposition in order to get their meaning clear. Don't
get me wrong, I would love to try doing this. BUt we shouldnt just
imagine, or pretend, that we have already done it, and then
incorporate our hubris into the foundation layer of the basic SW spec.
>Introductions to logic talk about how the real state of the world
>(whatever that might be) is beyond the reach of logic, so instead
>logic concerns itself with what must be true for all worlds.
>
>But some part of the state of the web is readily available to both
>automated and human reasoners. And we'd like very much to use it.
>
>The idea here is to consider all claims like 1b and 2b (all true
>claims about the state of the web) as axiomatic to "RDF full
>entailment". In "RDF full entailment", claim-1b follows from the
>empty graph!
So you think that 1b is a LOGICAL truth, like a tautology? (Really??)
>Thus in "RDF full entailment", Proposition-1 follows from Claim-2a.
>
>***** URI-References
>
>My translation of the RDF node label
> http://www.w3.org/2002/10/meaning/animals#Dog
>into the English
> the class called "Dog" in the document on the web at address
> "http://www.w3.org/2002/10/meaning/animals"
>is not guided by any approved standards I know of, but I don't need to
>prove it's the correct translation (for the goal of this message),
>just that it's a possible one. Hrm. That seems obvious, but hard to
>prove. Maybe by contradiction? Let me know if that's needed.
>
>***** Conclusion?
>
>Are you convinced yet that the RDF specs can, in theory, define the
>meaning of triples and URI-References such that from
> _:x rdf:type animals:Dog.
>it follows that
> _:x rdf:type animals:Mammal.
Emphatically not. We tried to do a piece of this when defining a
semantics for owl:imports, and we still havn't got that right to
everyone's satisfaction.
>?
>
>
>***** Point-By-Point Reply
>
>> >***** 1. New Introduction and Summary
>> >
>> >In the editor's draft of RDF-CONCEPTS [0], you've added a lot of text
>> >about the meaning of a URIRef coming from the web-content available at
>> >its URI-part. It's an excellent and much-needed addition.
>> >
>> >I want to underscore how important it is by pointing out that
>> >social meaning is self-reinforcing. If people start to doubt the
>> >importance of using URIRefs as they are defined (and begin to
>> >experiment with their own incompatible meanings), the RDF specs are
>> >likely to lose any authority in the matter. People need tremendous
>> >confidence in the language in which they write their contracts if
> > >they are to be held to those contracts. There must be very little
>> >window for people to argue about what the definition of "is" is.
>> >
>> >With that in mind, and with an eye towards prospects of automated
>> >reasoning, I'd like to propose this test case:
>> >
>> ><?xml version="1.0"?>
>> ><!DOCTYPE rdf:RDF [
>> ><!ENTITY animals "http://www.w3.org/2002/10/meaning/animals">
>> ><!ENTITY rdf "http://www.w3.org/1999/02/22-rdf-syntax-ns">
>> >]>
>> ><rdf:RDF xmlns:rdf="&rdf;#"
>> > xmlns:animals="&animals;#">
>> > <rdf:Description rdf:ID="spot">
>> > <rdf:type rdf:resource="&animals;#Dog" />
>> > </rdf:Description>
>> ></rdf:RDF>
>> >
>> >(I moved the hash-mark out of the entity for reasons which will be
>> >clear later.)
>> >
>> >This parses as:
>> >
>> >_:x <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
>> ><http://www.w3.org/2002/10/meaning/animals#Dog> .
>> >
>> >and it should entail
>> >
>> >_:x <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
>> ><http://www.w3.org/2002/10/meaning/animals#Mammal> .
>> >
>> >How? Because the document at "http://www.w3.org/2002/10/meaning/animals"
>> >says that #Dog is an rdfs:subclassOf #Mammal.
>>
>> Oooh, this reminds me of the argument we had at the recent webont F2F
>> about 'imports'. There is a real problem (noticed first by Dan C.) in
>> saying that A entails B because of what is in C. "A entails B"
>> already has a meaning: it means that any interpretation which
>> satisfies A also satisfies B. So if A entails B because of what C
>> says, then A's *truth* must depend on what C says. Is that really
>> what you want to say here? That the truth of
>>
>> >_:x <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
>> ><http://www.w3.org/2002/10/meaning/animals#Dog> .
>>
>> depends on the interpretation of the document at
>>
>> "http://www.w3.org/2002/10/meaning/animals" ?
>>
>> This is a very odd notion of 'truth', since it recurses along URLs.
>> In order to find out what a webpage is saying, now, I have to locate
>> the transitive closure of all the implicit links from that page,
>
>As you can probably see by now, this is pretty much exactly the notion
>of truth I have in mind. And it doesn't seem odd at all. Isn't that
>kind of recursion what all uses of identifiers involve?
Well, no, in fact: but aside from that, the point is that we aren't
talking here about how to USE an identifier, but about what it MEANS.
> Sometimes you
>can reason without knowing how the identifier is defined, but in
>general the identifier serves as a kind of shorthand for its
>definition. It allows the author and reader to bring in a whole set
>of definitional axioms which, hopefully, are not subject to debate.
Look, the axioms are there (let us suppose). Why do we need to talk
about 'bringing them in'? If they are published somewhere then anyone
can 'bring them in'. BUt if they are published by A, then B doesn't
need to do anything special in order that C can find them at A. Maybe
as a courtesy B can include a pointer to A, just to give C a helping
hand, as it were: but the transaction between C (who is doing the
reasoning) and A (who is publishing the axioms) seems to me to have
nothing particularly to do with B (who is using the terms for B's own
purposes.) It certainly has nothing to do with the *logic* that C
might use to figure out the logical consequences of what A and B (and
anyone else) are saying.
>
>When they are subject to debate, you have to stop treating them as
>axioms. Some people (like me in my younger days) often refuse to
>accept these unstated definitional axioms; they usually get accused of
>"playing semantic games". Note the scorn President Clinton got for
>picking on the meanings of words and the parsings of phrases.
I was entirely on his side on that one, however. (The fact that
America scorns an intelligent man for making careful distinctions
when being treated as a hostile witness while under oath tells us
more about America than it does about the man. )
>
>"Floating" semantics will mean an author can use terms and safely
>assume the reader will have handy the same meaning or definitional
>axioms. (Similarly, a reader will be able to assume the author was
>using the same meaning.) This doesn't need to be perfect, but it
>needs to be "good enough" for each particular application.
Fine. So, if you want to know the intended meanings, go to the source
and look for what the source says. Why do we need to say more than
that?
> Maybe
>people who think we should float the semantics now have very low
>expectations for Semantic Web applications in the next few years.
>
>> and
>> I have to consider them all as being asserted by the webpage itself.
>> Not only does this seem implausible, it seems unnecessary. After all,
>> they are already being asserted, right? Thats how I am able to find
>> them, by their being published on the Web. If they weren't being
>> asserted then I would get 404 errors. So why do I need to assert them
>> *again*?
>
>It's the difference between them being asserted by their author
>(Nancy, in the example far above) and claimed-to-be-true by the author
>of the document using the term (Arthur).
OK, that's what Jeff Heflin says about 'imports' as well. Heres my
response, to both of you. Suppose I am C reading this RDF and drawing
conclusions from it. You are B and you use a term defined at A. I can
easily find A by deconstructing your urirefs, so here I am with all
this RDF. Now, what possible difference does it make to me, or to any
conclusions I can draw, whether you, B, assert, co-sign, import,
assent to or in general say anything whatever about the RDF that I
find at A? As far as I can see, the answer is: absolutely nothing.
That is, your assenting to A is *completely irrelevant* to me. I
presumably trust you, or I wouldnt be using your RDF in the first
place. We both trust A, or I wouldn't trust you (since you use A's
terms). (In any case, who I trust is up to me, not up to you to tell
me.) So your importing or assenting or whatever doesn't add a squit
to my ability to draw useful conclusions. It might make you feel
better, but I am just going to ignore it. In fact, I *have* to ignore
it, since there aren't any conclusions I can possibly draw from it.
>
>When we're not granting that all web-documents are true, we need to be
>able to make this distinction. We may trust Arthur and know nothing
>of Nancy; following my proposal, we can see everything Arthur meant
>when he used particular terms, not just what he directly stated in his
>document.
>
>> >
>> >Let me back up a little and clarify: we have three kinds of
>> >entailment:
>> >
>> > (1) RDF simple entailment, as in the MT [2], which says
>> > things like every RDF graph entails its subgraphs.
>> > This kind of entailment pays no attention to URIRefs.
>> > (2) Entailment with the "rdf" and "rdfs" vocabulary terms
>> > reserved, as in MT [2].
>> > (3) Entailment where every URIRef is constrained in meaning
>>
>> No, its not *constrained*. It *asserts* that other content (again).
>> But of course other people might be asserting other things; nothing
>> constrains them from doing that.
>
>In my hedging about what EXACTLY a definition is, I was here using the
>phrasing that a definition constrains the valid interpretations of
>the defined term. This seems intuitive, but perhaps there's a formal
>definition of "constrained" that I'm not adhering to.
>
>> > according to the web content available at its URI part.
>> >
>> >Of course DAML+OIL defines its own entailment, as does OWL, as do my
>> >various layered logic languages [6], but these should all be seen as
>> >special cases of (3). The terms used by Dublic Core, RSS, Creative
>> >Commons, and various other efforts may not define their meanings with
>> >model theories or first-order axioms, but their terms are also
>> >carefully defined, and in some cases their misuse would be
>> >intollerable (and in the case of CC, perhaps even illegally!).
>>
>> Fine, but there is no need to incorporate that meaning into a notion
>> of entailment. All we need to do is to say that *if* they mean
>> something, in some sense of 'mean', by virtue of whatever
>> social/legal/contextual process is considered to attach meanings to
>> them, then those 'mean'ings are also inherited by their entailments.
> > But entailment itself is a crisp notion defined in terms of the MT:
>> no need to mess with that (and better not to try, in case it all
>> falls apart.)
>
>I'm fine with separating "RDF simple entailment", "RDFS entailment"
>and "RDF full entailment". (These were my three types at the
>beginning of my earlier message.) The third involves the state of the
>web, and may be hard to express quite as formally, but it is still
>fairly crisp. It does NOT require any appeal to
>social/legal/contextual process. That's why I want an approved test
>case for it.
>
>There is social/legal process in understanding any natural language
>definitions, but they don't occur in my test case. (See some
>discussion of "rdf:definition" below.)
>
>> BTW, if these issues ever get to be of real importance, then I bet
>> the the legal system will invent its own criteria no matter what we
>> say about it, and I bet it will be messy and full of vagueness and
>> case law. For example, suppose that the inference path from what I
>> publish to something insulting is very long and recondite, and I
>> argue that I didn't forsee those entailments and didn't intend to
>> assert them; I bet that some jury will buy some such argument
>> eventually. (Or suppose I set up an RDF website - actually it will
>> need to be OWL - which has double meanings, where one set of meanings
>> is very obvious and transparent, but the others are very indirect and
>> unintuitive and hard to decipher without running special reasoners,
>> and then I sue you for what you have 'said' by using one of my terms
>> in a way that reflects only its obvious meaning.)
>
>There is some danger here, to be sure. But what are our options? Try
>to be as clear and upfront as possible about what RDF means, helping
>the toolbuilders help convey this to the users, or float the semantics
>so there simply is no way to know which definitions should govern the
>use of some terms? (but we'll come back to this.)
>
>> >
>> >Type (2) entailment above should also be subsumed into type (3), by
>> >putting normative pointers at the rdf and rdfs namespace addresses to
>> >the appropriate Recs (when the Recs happen). In fact, the MT should
>> >be more clear in distinguishing between (1), (2), and (3). (2) should
>> >probably be in a separate document. Perhaps (1) and (3) should also
>> >be separated, but they remain to describe the meaning inherent in all
>> >RDF documents, regardless of any URIRefs which occur in it.
>> >
>> >The point here is that an RDF document must be taken to assert the
>> >truth of all the documents it names in the URI parts of its
>> >node-labeling URIRefs.
>>
>> I disagree. It might in some sense presuppose them, and it (or its
>> author) might be responsible for what *it* says when they are taken
>> into account; but neither of those are the same thing as it
>> re-asserting them.
>
>I don't see how you can distinguish between (1) what a document says when
>the definitions of its terms are taken into account and (2) what the
>definitions say. I'm open to there being some bright line, but I
>can't find it, so for now I go with the worst-case approach of
>importing the entire definition.
>
>> > If those documents are available to a reader,
>> >and the reader is capable of understanding them, the reader is fully
>> >entitled to infer facts from the conjunction of the author's documents
>> >and all the definitional documents.
>>
>> The reader is already entitled to do that. No need to say anything to
>> make this possible. If I read one thing in the Times and another
>> thing in the Mirror, then I am entitled to draw my own conclusions.
>
>Forgive me -- I meant that the reader could attribute such inferred
>facts to the document's author. To put it differently, if I trust the
>Times but do not necessarily trust the Mirror, when the Times uses
>definitions from the Mirror I know I can trust (that part of) the
>Mirror.
>
>> > Moreover, the reader can
>> >attribute these conclusions to the author; the author is responsible
>> >for chosing terms (eg comic, clown) whose definitions he accepts.
>>
>> Right, but we need to be careful. I think the way to say this is, the
> > author is responsible for choosing terms whose consequences (from
>> what he says and what the owner of the term asserts) he is willing to
>> stand by. But that is not (necessarily) to endorse everything that
>> the owner asserts. For example, I might use a term in a dictionary
> > without necessarily thereby agreeing that *every* definition in the
>> dictionary is correct. I am only assenting to the part that I am
>> using; and even there, I am not re-asserting it, only agreeing to it.
>
>Again, I don't know how to draw this line through tricky, interwoven
>definitions. See also my reply to Peter [3] about how to solve this
>in practice.
>
>> >
>> >There are many more details, below. I first approached this topic
>> >without noticing the new text in the editor's draft, and spent more
>> >time arguing why using the URI for the semantics was important. I'm
>> >going to leave that text here, because some people are still probably
>> >not convinced. If you are convinced, feel free to skip sections 3
>> >and 4.
>> >
>> >**** 2. A Few Notes on RDF-CONCEPTS [0]
>> >
>> >I think you overplay the difference between formal and natural languages in
>> >2.3.3 in the example with
>> >
>> > B:oneOfThem rdfs:comment "This means the same as rdfs:subClassOf".
>> >
>> >If we take rdfs:comment to provide normative natural language
>> >information about the subject (and if it doesn't we need some other
>> >property which does), then in fact C is still to blame for the insult
>> >to C:JohnSmith. The failure of RDFS class reasoning to reach the
>> >insult does not mean the insult is not style-3 entailed, in this case
>> >via B:oneOfThem.
>>
>> Well then that is a critical fault with your 'style-3' notion. Any
>> notion of entailment which requires one to interpret NL comments is
>> simply untenable. There really is a sharp distinction between NL and
>> formal languages here, and we cannot allow it to get blurred: if we
>> do, we are dead in the water before we even get started.
>
>I'm not trying to blur the line. I'm just saying that certain parts
>of the system apply equally well no matter what kind of language is
>used.
>
>Let me suggest a different approach which makes the line clearer:
>
> The document at the URI part of a URI-Ref may be available in RDF
> (content-type: application/rdf+xml). Such RDF content is
> considered to be asserted-as-true by all RDF documents which use
> that URI-Ref as a node label.
>
> A special (reserved) predicate called rdf:definition links
> subjects to natural-language text which "defines" the subject.
> A triple of the form
> _:x rdf:definition "a blue car"
> is true if and only if the thing identified by _:x is a blue
> car. To make long definitions more readable, the pronoun "this"
> or the noun phrase "the subject" (or equivalents in other
> languages appropriate to the xml:lang tag of the string) can be
> used to refer to the subject.
>
> Reference to longer works is also appropriate for complex
> definitions, as in:
> _:kg rdf:definition "a kilogram, as defined in 1960 by
> the General Conference on Weights
> and Measures. See L. Van Hagen Judson,
> Units of Weight and Measure
> (U.S. Customary and Metric), Definitions
> and Tables of Equivalents (1961;
> U.S. National Bureau of Standards,
> Miscellaneous Publication 233) and
> Weights and Measures Standards of the
> United States: A Brief History (1963;
> U.S. National Bureau of Standards,
> Miscellaneous Publication 247). "
>
> Determining the truth of rdf:definition triples can be difficult
> or even impossible for people and for machines. Confidence in
> such determinations can also be difficult. In general, the
> degree of linguistic precision and detail should match the
> requirements for confidence of interpretation. In some cases, of
> course, matters of truth simply cannot be settled, even by the
> most detailed court proceedings.
The real problem is that when it comes to NL, what even *counts* as
truth has to be re-thought from the ground up. The standard
model-theoretic account just won't do: one needs to take into account
things like the assumed common ground, the role of conversational
implicatures, enthymemes, speech acts, indexicals, tense, indirect
quotation, analogy and metaphor, natural kind terms, semiotics,
etcetcetc. . NL is the entire human condition. If you want to refer
to NL meanings, then lets just forget about the SW. The SW isn't
going to be able to handle it: just give up now, go home and find
another job.
> Still, the triple is said to
> have some truth value, however controvercial or unknowable.
Nah, lots of NL doesn't have a truth-value. What is the truth-value
of "Duck!" ?
>
>... or something like that. Perhaps rdfs:isDefinedBy could be
>revived in a similar function, but this seems simpler to me. I'd also
>be tempted to allow XML (XHTML) literals as the objects here.
>Pressing rdfs:comment to use here is probably not a good idea.
>
>> >I think 2.3.4 is wrong: the predicate needs no special status. The
> > >situation you're trying to prevent here is prevented by accepting the
>> >namespace/URI owner as authoritative in defining the terms there.
>> >(see my definition of definition in section 5.y).
>>
>> The issue is not about authority, but about what counts as a 'definition'.
>>
>> >
>> >Section 2.3.5 is also misleading: there is RDF-Simple-Entailment ("1"
>> >above) and RDF-URI-Based-Entailment ("3" above), and that pretty much
>> >covers it. At some URIs (eg OWL, RDF/RDFS, LX) you should find
>> >appeals to natural language and/or mathematical definitions which are
>> >not directly usable by machines, but the terms defined there can be
>> >used to define other terms in a way which *is* amenable to automated
>> >reasoning. One could try to distinguish between natural language
>> >definitions and formal language definitions, but I'm not sure how that
>> >would help, since automated reasoners vary so much in what kind of
>> >formal languages they can handle.
>>
>> You seem to be repeating a common beginners mistake. Sorry to be so
>> blunt, but its important not to let this error run unchecked. Of
>> course a *spec* is written in NL: its intended for human developers
>> to read. But a spec is not a *translation*. The MTs for RDFS and OWL
>> are written in what might be called 'NL math'; but the specifications
>> they provide (of entailment and satisfaction) are completely
>> unambiguous and exact, which is why they can be used as a guide to
>> developers of inference systems. The fact that the METAlanguage of a
>> formal language is readable by human beings does not imply that the
>> language ITSELF is somehow tainted with informal or social meaning.
>>
>> >
>> >***** 3. Older Introduction
>
>Oh my god, we're only up to section 3! I'll try to avoid repeating
>myself....
>
>> >If I receive and believe an RDF document, D, saying that D:spot has
>> >rdf:type animals:Dog, and the animals schema says that animals:Dog is
>> >a subclass of animals:Mammal, would it be right of me to infer that
>> >D:spot has rdf:type animals:Mammal?
>>
>> I would say that there is no answer to that question. It depends on
>> what you accept. If you accept both documents, then yes, you should
>> feel right about making the inference. If not, then maybe not. All
>> that RDF can tell you is what follows from what: but what you choose
>> to believe is up to you.
>>
>> Logic 101: don't confuse 'valid argument' with 'correct conclusion'.
>> Logic doesn't tell you which conclusions are correct or true: it only
>> gives you ways to infer one thing from another.
>
>I think I've addressed this with "Reasoning about the State of the
>Web."
>
>> >
>> >Your answer might be "never", "sometimes", or "always." If you say
>> >"never," then I think you've missed the point of RDF and XML, with all
>> >these URIs and namespaces. If you say "sometimes," then we need to
>> >talk about the qualities of those times. If you say "always", we have
>> >some consequences which might be problematic. (I will argue that the
>> >correct answer is "always" and that the problems are manageable.)
>> >
>> >In any case, I don't think the current working drafts are clear on
>> >this issue.
>>
>> They should not be, any more than they should try to answer the
>>Secret of Lif
>> e.
>>
>> > RDF-CONCEPTS section 2.3 [1] suggests to me the answer is
>> >probably "always" and RDF-MT section 1.2 [2] says "sometimes" and that
>> >it depends which vocabulary you are reserving. Such an answer from
>> >the MT, while true in a sense, is fairly useless.
>>
>> Tough shit. I mean, it DOES depend on that. if that bothers you, get
>> used to it, because this isn't going to change.
>
>Sorry, no insult intended! I'm trying to get the MT to codify the
>kind of meaning that I think people want from RDF. More than "want",
>even "expect." But they wont get it unless it's codified soon.
>
>You heard Tim pitch this at the DAML PI meeting. No one objected.
>Is that because they didn't understand,
Apparently, because I don't know which particular pitch you are
referring to. I don't recall this issue even coming up at the PI
meeting, so I probably missed the point at the time.
>didn't feel it was their place
>to object, or just wanted the meeting to end? He did use some rather
>vague terms, perhaps more in line with the current Concepts document
>than the test case I'm proposing. (I did run some similar test cases
>by him, so I *think* he'd support my position. Alas, he's out of
>contact this week.)
>
>> > I need to know when
>> >I'm entitled to make the Dogs-are-Mammals inference,
>>
>> You are always entitled to make that *inference*. The issue is
>> whether or not you believe the antecedents. The rule is valid, but
>> its up to you to decide whether or not to trigger it. RDF can't help
>> you there. All it can do is convey the content from one place to
>> another, but it can't guarantee verity.
>>
>> >and I don't think
>> >out-of-band negotation of the "reserved" vocabulary for each RDF
>> >document is practical.
>> >
>> >I'd like to apologize for raising this issue so late in the process,
>> >but my understanding of it has only become clear in the past week.
>> >Previously, I had some vague notion that we could "float" the meaning
>> >of RDF identifiers, but I no longer think that is practical. I am
>> >indebted to Pat Hayes, Jeff Heflin, David Booth, Larry Masinter, Dan
>> >Connolly, and especially Tim Berners-Lee for recent conversations
>> >helping me understand these issues (even when they disagreed with me).
>> >
>> >Last week at the DAML-PI meeting [3], TimBL said that we are not ready
>> >to "float the currency" of identifier meanings yet, and wont be for
>> >perhaps fifty years.
>>
>> I'd say less, maybe ten. If the 'wild' free-wheeling social SW ever
>> takes off, it will start to happen fairly quickly, Im sure, whether
>> we like it or not.
>
>But you still agree we need to start with some agreed-upon way to say
>which assertions about a term should be considered
>not-subject-to-debate, as its "definition"?
Well, it seems to me that there is a simple, clear story here.
1. RDF is a logic (an assertional language) , and entailment has its
usual meaning.
2. Urirefs 'belong' to their owners, and the owner is only
responsible for the sentences hse publishes. That is, owners are not
responsible for their urirefs, but they are responsible for their
triples (just like everyone else.)
3. In general, its good advice to only believe things published by
entities you trust; but it is not logically inconsistent to be either
paranoid or gullible.
The only special thing that needs to be said is that
4. if you publish something which uses a uriref belonging to someone
else, then it is your responsibility to ensure that the meaning you
intend it to have is consistent with the meaning its owner intends it
to have, ie expressed in whatever assertions hse makes using it: and
so
5. if you don't, and someone is misled as a result (ie if they draw
conclusions from what you wrote and what the author wrote which are
valid but which neither of you intended), then you are to blame (not
the owner of the uriref that you misused).
This last point probably needs to be spelled out more carefully (what
if the owner published some new stuff after you used the uriref, for
example?) but it will do for now.
There. No need to mess with entailment, no need for a special web
logic, no need to worry about what counts as a 'definition', etc..
>
>Nothing in my proposal prevents null definitions, which allow full
>free-floating of terms.
>
>> >For now, he argued, we need to stay on the gold
>> >standard, where namespace owners have the non-negotiable right to
>> >dictate the meanings of the terms in their namespace. This is like
>> >the US Government saying a US "dollar" is worth 1/35th of a Troy ounce
> > >of gold; it defines the US dollar in terms of other well-known
>> >concepts. This makes sense when introducing a term; it makes less
>> >sense when everyone has developed a strong sense of what the term
>> >means. Tim's point, I think, was that we're a long way from computers
>> >being able to navigate in a world of vague meaning.
>>
>> Indeed.
>>
>> >
>> >***** 4. Argument For Entailment
>> >
>> >Let's return to my Dog/Mammal example. Let's bind the namespace
>> >"animals" to "http://www.w3.org/2002/10/meaning/animals#". The
>> >document at that address (without the hash) is some RDF saying in RDFS
>> >that animals:Cat is, in fact, a subclass of animals:Mammal.
>> >
>> >Does this mean that the triple
>> > _:x rdf:type animals:Cat.
>> >entails
>> > _:x rdf:type animals:Mammal.
>>
>> No. It means that triple plus the owner's assertion about what it
>> 'means' together entail that. Isn't that enough?
>>
>> >?
>> >
>> >There are some issues here about connectivity, trust, and
>> >change-over-time, but let's defer them for the moment. Assume a
>> >static, always connected, always trustworthy web.
>> >
>> >Now, I claim that (following the "gold standard") the second triple
>> >follows logically from the first.
>>
>> Again: "entails" is an English word with a meaning. Apply that
>> meaning, and you are saying that the first triple *asserts* that cats
>> are mammals. But it doesn't seem to me that it does assert that: and
>> if it does, why do we even need to use the document at the unhashed
>> address? According to your criteria, it is irrelevant.
>>
>> >The author of the first chose to
>> >use the "animals" namespace, and by doing so acknowledged the
>> >definitions therein.
>>
>> Acknowledging is not the same as asserting.
>>
>> > The author could have used some other namespace,
>> >or no namespace, but chose to use "animals" (by which I mean the
>> >longer URI above). The author almost certainly chose to use the
>> >"animals" namespace so that others, doing later queries or merges,
>> >would connect his expressions with other expressions about animals.
> > >He wanted us to be able to infer that _:x was a mammal.
>>
>> Quite possibly, but not by saying something that entailed it; rather,
>> by saying something new which could be combined with something he
>> referred to, so that *together* they entailed this.
>>
>> >
>> >Did he want us to follow the gold standard, or did he want us to have
>> >to think carefully about which definition of animals to use? He
>> >probably wanted us to use the gold standard, to use the definitions at
>> >the namespace address, because otherwise there's a chance we'd believe
>> >some foolish claim about cats being fishes, and totally misunderstand
>> >him.
>>
>> Ah, but even your gold standard doesn't provide any security against
>> that. Suppose that Joe asserted the 'real' definition, and some other
>> schmuk, Mick, publishes some nonsensical claim *using Joe's term*. I
>> might still stumble across Mike's nonsense and believe it; nothing
>> that you or Joe can say or do is enough to prevent me from being
>> misled by Mike. NOTHING.
>>
>> This point also came up in the 'imports' discussion, and I think it
>> reveals a basic flaw in a lot of reasoning about 'trust'. Let me
>> shout this from the rooftops: PROVIDING A WAY TO INDICATE TRUST DOES
>> NOT PROVIDE ANY WAY TO INDICATE MISTRUST. The only way in which this
>> can happen is if there is a basic, universal assumption of mistrust -
>> do not believe ANYTHING you read in RDF, its ALL LIES - unless it is
>> explicitly overridden by an 'imports' or an explicit use of a term,
>> as in your 'gold standard' rule. But surely that kind of
>> institutionalized paranoia isn't the right way to start building a
>> semantic web, is it? I wouldn't want to use a paranoid version of
>> Google.
>
>A very interesting point. On the other hand, it's damn nice to know
>when you can trust something. The rest of the time (business as
>usual) you need to take things with a grain of salt. Google gives me
>just about the right amount of salt in my diet, but I rather expect
>agents scouring the semantic web might come back and dump several
>cubic meters of salt on my keyboard, as they start to reason about all
>sort of, er, salty things.
>
>If I decide to trust the Times (to some degree X), and the Times
>completely trusts 700 specific sources, then I can very nicely infer
>that all 700 sources are worthy of trust (to degree X) and cut a lot
>of salt out of my diet. (One's actually logic about the transitivity
>of trust may be more complex, but it's still important to have good
>data.)
>
>So yes: the wild, wild, semantic web will be full of tons of useful
>and interesting information of completely unknown quality. For some
>applications you'll be happy to assume it's all true; for others
>you'll want to be more careful. When you start being careful, it will
>be nice to have interlinked networks of trust to help keep things
>simpler. My proposal here ends up providing some handy trust
>information as a side-effect of being precise about what it means to
>"use a URIRef according to it definition".
I think you are getting two different issues mixed up. I agree about
the 'web of trust' thing - Seth Russell made the same point a while
ago. Seth's idea was to have an explicit 'I trust that' (semref)
pointer - a kind of content-thumbs-up sign rather than an explicit
endorsement of all the triples - precisely to enable this
web-of-trust thing to get started. Nice idea. But that isn't the same
as saying that this is a *definition* of my terminology, or that I
hereby legally endorse this (so if someone sues its author, I can be
named as co-defendant?), or that in order to understand me, you must
import all of this and its transitive closure (even if I just want to
say that Spot is a Mammal and the transitive closure is half the
bloody Web) or that in order to use logical inference on what I say,
you need to check out this and its transitive closure (so if you get
a 404 error, I'm not really saying anything, in spite of
appearances). All of these ideas are much too strong and are all
"solving" non-problems. The fact that there are no real 'definitions'
in RDF is a feature, not a bug, for example.
>
>> >
>> >So yes, granted the issues about connectivity, trust, and
>> >change-over-time, the above entailment should hold. Now, let's
>> >address those issues:
>> >
>> >***** 5. Answers to Problems
>> >
>> >1. Connectivity. Connectivity does not affect entailment. Whether
>> > or not someone can get a copy of the "animals" definition document
>> > does not change the fact that that document is the primary source
>> > for the definitions of all the terms in the animals: namespace.
>> > If you can't fetch the definitions, then your knowledge of the
>> > terms is incomplete and your reasoning about them will be
>> > incomplete. Incomplete reasoning can be a problem, but it's
>> > hardly a new problem or one which only arises when we bring in
>> > connectivity issues. If you can't fetch the document (and don't
>> > have a current cached copy) then you know that you're missing some
>> > information. The monotonicity guarantee of RDF, however, allows
>> > you to proceed with your partial information, which might be good
>> > enough.
> > >
>> >2. Trust (except for change-over-time). This gold standard means
>> > that the claims of an RDF document (which [1] says should have
>> > legal weight) depend on the contents of other documents. This is
>> > more stable than saying such claims depend on social consensus,
>> > but it still involves trust. If I say my dog has rdf:type
>> > animals:Dog and the animals document says that an animals:Dog was
>> > once kicked by Ebenezer Scrooge, can I really be held to be saying
>> > that Scrooge committed such an act?
>>
>> No, because there is no inference path to that from anything that YOU
>> have asserted (unless it was your dog he kicked, of course.).
>> Entailment is actually quite useful when you morph it into proof
>> theory, since it provides a much sharper tool to figure out what
>> follows from what. For example, let me commend the Craig
>> interpolation lemma to your attention. It says that if A follows from
> > B (and neither of them is a logical truth or a logical contradiction)
>> then there must be on 'interpolant' C which only contains names from
>> the *intersection* of the namespaces of A and B such that A entails C
>> entails B. From which it follows for example that if A and B have no
>> names in common, then A cannot entail B (unless A is a contradiction
>> or B is a tautology). That deals with your Scrooge example.
>
>Very nice. But then I went and dumped the state of the web into your
>logic. :-)
You tried, but it wouldnt go through the funnel.
>
>(as I duck, fearing what you might start throwing at me....)
>
>> > I think so; I haven't found a
>> > solid line marking the parts of a definition which have bearing
>> > solely on other things. Perhaps the animals document means the
>> > Scrooge clause to be the necessary and sufficient condition for
>> > doghood! So, a bit hesitantly, we have to say that all statements
>> > in the definition document are asserted by any use of terms from
>> > the document.
>> >
>> > We can address the Scrooge issue by saying that using terms from a
>> > document is a lot like signing it. Don't do it unless you have
>> > read the document and agree with it. Of course you need to do
>> > this recursively, following the definitions of any terms it uses.
>> >
>> >x. (x is for extra) This brings up the issue of URIRefs "grounding
>> > out" in natural language text (which may well make use of
>> > mathematical notation). Our "animals" document constrains the
>> > meaning of animals:Dog (very slightly) by using the term
>> > rdfs:subclassOf. That term needs to be constrained by the
>> > document at the rdfs namespace [4], which it sort of is.
>>
>> No, its constrained by the *language spec*. Even if that spec was not
>> on the web, it would still do its work by virtue of being the
>> specification. It doesn't need to be read by active web agents in
>> order to be a normative language specification. The meanings of
>> rdf:type and rdfs:subClassOf are not PROVIDED at the URl
>> http://www.w3.org/2000/01/rdf-schema; that uriref serves only to
>> *identify* the RDF(S) spec. The actual meanings are defined in the
>> documents which (we hope) will be read by software developers, not by
>> the comments on a web page. I would expect any RDF-savvy software to
>> be able to recognize the normative RDFS URI, but I wouldn't expect it
>> to follow the link in order to *find out* what rdf:type means. It
>> ought to just 'know' that, in much the same sense that I 'know' how
>> to breathe.
>
>I know that's how it's done now, but that doesn't scale.
Sure it does. Any automated 'meaning' has to ground out somewhere in
working code, and that code will be built to act in conformance to a
spec. Im talking about languages, not just vocabularies. We already
have how many? eight? sweb languages all with different specs (RDF,
RDFS, RDFS plus datatypes, OWL-lite, OWL, fastOWL, OIL , DAML+OIL).
These differences between these cannot be described just by changes
in vocabulary; they all impose different semantic (and hence
inferential) conditions on a vocabulary.
>Other
>vocabularies like DC, CC, RSS, etc, need to be able to define their
>"reserved vocabularies" just like rdf/rdfs does.
No, NOT like RDF/RDFS does. FOL doesn't need another logic to define
'and'. If you want fixed, interchange-supporting meanings, then you
fix them in specifications and let people build them into software.
If you want fluid, machine-readable meanings, then you formalize them
using a fixed machine-processable framework.
> We can special case
>rdf/rdfs, but there's no good reason to. This is why RDF uses URIs.
>
>> > To
>> > follow the gold standard, that document must make normative
>> > reference to "http://www.w3.org/TR/rdf-schema/" which it currently
>> > does not. (We could exempt RDF and RDFS from this policy,
>> > understanding that their meanings are acknowledged by the very use
>> > of the RDF/XML data format. There is little reason for this
> > > special dispensation.)
>>
>> I believe that any well-formed RDF/XML will contain such a normative
> > reference in its header, right?
>>
>> >
>> > I don't see a proper way in the current spec to make this kind of
>> > normative reference from an RDF/XML document to a human-readable
>> > one.
>>
>> Why does it have to be a reference to a human-readable document? For
>> that matter, why does it have to be a reference to ANY document?
>> Suppose that some web attack disables the W3C server so that this URL
>> produces a 404 error: would all RDF reasoners on the planet grind to
>> a halt because they wouldn't know what rdf:type meant?
>
>Nah, the rdf and rdfs namespace content (like nearly all definitional
>content, I think) should be served with an expires of "never", so once
>you've read it once you can keep using it forever.
My point is that you don't need to read it even once, if you are RDF
software. Its built into you.
> Or maybe an
>expires of a few months, if we want to be able to change the semantics
>and force everyone to rewrite their implementations: a fascinating
>political issue....
>
>It would be nice to make a distinction in expiration committment
>between adding new triples which don't share nodes with the old ones,
>new ones which do, and deleting triples. I'm not sure if the current
>web gives us any good way to do that. I guess the definition can
>simply point to other places one might look for addition kinds of
>information of varying degrees of trustworthiness.
>
>> >Perhaps it is sufficient for an rdfs:comment or
>> > dc:description to claim, in its natural-language text, that it is
>> > in fact normative. That's a little loopy, but natural language
>> > can probably handle it. Better would be to make sure the RDFS
>> > namespace document said that rdfs:comment contained true
>> > natural-language statements about the subject.
>>
>> It can say that all it wants, but it can't say it in RDF, so an RDF
>> engine isn't going to be able to understand it.
>>
>> >
>> >3. Change-over-time is a special case of the "stewardship" issues. It
>> > doesn't necessarily involve time; it's possible for a web server
>> > to offer one definition document to people who seem to be in France
>> > and another to people who seem to be in England.
>> >
>> > Stewardship issues arise often: should one define one's input as
>> > being Unicode 3.2 characters, or as being whatever characters set
>> > is the latest approved by the Unicode Consortium? Do you
>> > advertize your program as running on "OS Version 9.1" or "OS
>> > Version 9.1 or later"? It all depends on whether you trust the
>> > stewardship of the organization which controls the underlying
>> > components.
>> >
>> > The solutions here are typical security solutions, because these
>> > are fairly typical security problems.
>>
>> [big snip] [Security issues are interesting but irrelevant to the
>> current discussion]
>>
>> >y. (why not add an extra (rather philosophical) point?) I've been a
>> > little vague about what a "definition" is. I mean a "definition"
>> > to be some declarative statement which uses the term and is true
>> > only for certain meanings of that term. An asserted (included,
>> > imported) definition thus limits the possible valid
>> > interpretations (models) of statements which use the term.
>>
>> Fine, so a definition is just another assertion. I like that idea.
>> You might add, that only the owner of a term is allowed to claim that
>> any of the assertions made using it are definitional (definitive?) in
>> the required sense.
>
>I think that follows from things I've said elsewhere, but sure.
>
>> >
>> > A "strong" definition is a work of art which constrains
>> > interpretation to the point where no observable differences
>> > emerge. For artificial terms, even stronger "perfect" definitions
>> > can be written. These are definitions in the mathematical sense,
>> > "Let us define f to be...". Compared to that, natural language
>> > definitions and ontologies are usually mere descriptions.
>>
>> Well, no, lots of NL depends on ostensive definitions which are
> > rooted in contexts of use, eg almost all proper names are like this,
> > as are natural kind terms like 'wet' or 'overcast' or 'wood'. These
>> aren't descriptions in the usual sense. NL is really *very*
>> complicated; way too complicated to toss casually into a discussion
>> like this.
>
>Heh. Good point. Still, I did only claim "usually".
>
>> > Still,
>> > I call them definitional documents in accordance with their intent
>> > and common usage.
>> >
>> > Definitions do not have to be perfect, or even strong, of course.
>> > They can be "thin" ontologies like my Dog/Mammal one, which merely
>> > offer a little helpful description. The essense of the gold
>> > standard is that, no matter whether a definition is thin, strong,
>> > or perfect, you at least know which one everyone is supposed to
>> > use.
>>
>> Everyone is *supposed* to use? According to what authority?? Isnt
>> that a bit like saying, the newspaper that everyone is supposed to
>> read?
>
>Forgive me, I got sloppy again. The "supposed to" onus is really on
>the author, consenting to the definitions of the terms he uses. The
>reader is free to use whatever 3rd party information he wants, as you
>say, but he does get the URI-based definition "for free"; he knows the
>author agrees with it and with all the conclusions one could draw from
>the combination of his document and the URIRef->URI definition
>documents. He doesn't need to make a difficult judgement call about
>that.
OK, fair enough. If all we want to say is that by using a uriref, I
trust the owner to define the meaning in a way I intend, then I have
no problem with that. BUt that doesn't refer to truth or entailment
or definition: it is explicitly about trust.
>
>The RDF Core WG has, I think, the authority to put this onus on
>authors of RDF/XML documents. Such authority is rather more tenuous
>than I would like, but I think it's enough to start with. If we get
>off on the right foot, the social interactions between authors and
>readers will start to reinforce this obligation. My test case should
>help provide a clear sign moving forward.
I think it is far too strong, and will have a paralysing effect. I
can imagine the Lucent or Xerox lawyers forbidding anyone in the
company to use RDF in case they accidentally assert something that
could lead to a class-action suit.
>
>> >
>> >
>> >***** 6. Older Conclusion
>> >
>> >I've tried hard to be clear and concise here, and I apologize for any
>> >failures. I understand you're working under a looming deadline, but
>> >this issue is crucial to address as soon as possible, in this version
>> >of RDF. I don't think this is a change in the basic intent of RDF,
>> >but if you Recommend the MT in its current form, you will have given RDF
>> >URIRefs only floating semantics.
>> >
>> >I doubt the change from floating semantics back to namespace-document
>> >semantics can be made compatibly. With floating semantics, people and
>> >machines reading RDF are required to use their own judgement in
>> >deciding which definitions to use. Once they start doing that,
>> >authors will become used to it, and will no longer be obligated to
>> >adhere to original definitions. Obligations cannot be imposed
>> >retroactively (in this kind of a free environment), so if
>> >namespace-document semantics are added later, they will have to be
>> >added in a language which is marked as having different semantics.
>> >But the difference is easy to miss; it's the difference that "now you
>> >have to use the terms as defined!" and if there's a reasonable doubt
>> >about authors understanding this change, then they really have no
>> >obligation (such as might stand up in court), and the change has not
>> >actually been made.
>> >
>> >Since floating semantics are not amenable to automated reasoning,
>>
>> ?? If I follow the above, then 'floating semantics' is the ONLY kind
>> that is amenable to automated reasoning. Allowing meaning to depend
>> on NL comments makes the SW unworkable for the forseeable future, and
>> in any case makes the SW indistinguishable from the WWW, so why the
>> hell are we wasting all this time and effort? The WWW exists, so we
>> can just declare victory and go home.
>
>I hope I cleared this up in my introduction of rdf:definition to
>clearly separate the natural from the KR languages.
Well, not really. You seem to say one thing but assume another. BUt
maybe Im not following you properly: I seem to have got 'floating
semantics' wrong in there somewhere as well.
> (KR languages
>other than RDF will fit in here somewhere, someday,
Right. Ever heard of OWL? Or DAML? :-)
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 Friday, 25 October 2002 17:13:42 UTC