- From: Sandro Hawke <sandro@w3.org>
- Date: Fri, 25 Oct 2002 14:35:59 -0400
- To: pat hayes <phayes@ai.uwf.edu>
- 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. 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?
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.
***** Reasoning About the State of the Web
The claims 1b and 2b are of quite a different nature than, say, 1a.
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!
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.
?
***** 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? 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.
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.
"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. 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).
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. Still, the triple is said to
have some truth value, however controvercial or unknowable.
... 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, 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"?
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".
> >
> >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. :-)
(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. Other
vocabularies like DC, CC, RSS, etc, need to be able to define their
"reserved vocabularies" just like rdf/rdfs does. 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. 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.
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.
> >
> >
> >***** 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. (KR languages
other than RDF will fit in here somewhere, someday, probably via
content negotiation or in (ugh) literals.)
> >you pass on this issue now, you will have kept RDF (in its present
> >form and probably all similar future forms) from being a viable
> >Semantic Web language.
>
> I disagree strongly. If we try to go the way you are urging, we will
> have defined the SW out of existence.
>
> Pat
Wondering if I've made any headway,
-- sandro
[1] http://lists.w3.org/Archives/Public/www-rdf-comments/2002OctDec/0046.html
[2] http://lists.w3.org/Archives/Public/www-rdf-comments/2002OctDec/0049.html
[3] http://lists.w3.org/Archives/Public/www-rdf-interest/2002Oct/0104.html
Received on Friday, 25 October 2002 14:36:47 UTC