W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > May 2002

Re: help wanted: RDF issue rdfms-assertion

From: patrick hayes <phayes@ai.uwf.edu>
Date: Fri, 31 May 2002 13:53:19 -0500
Message-Id: <p05111a19b91d52e54d81@[65.217.30.61]>
To: Tim Berners-Lee <timbl@w3.org>
Cc: "Brian McBride" <bwm@hplb.hpl.hp.com>, w3c-rdfcore-wg@w3.org
(Sorry this is getting so long. )

>Short answer:
>   Yes there is meaning to RDF statements which is not expressed in RDF.

OK, but then we need to come to a terminological agreement. There is 
a clear sense of phrases like 'meaning of XXX statement" or 'XXX 
meaning' (where XXX is the name of some formal language) which is 
widely used throughout AI/KR and logic. With that sense of 'meaning', 
statements like the above are foolish, like asserting that 2+2 is 
more than 4 . We spend considerable effort teaching our 
undergraduates not to make silly mistakes like that.

It has often seemed to some of us that people in the W3C make 
assertions about meanings that are so daft that it is hard to believe 
that anyone would assert them with a straight face, and I suspect 
that this terminological mismatch has been responsible for much of 
this impression. I am still not *entirely* clear what you mean by 
'meaning', and I bet that nobody is (which is fine, as long as we all 
know there is a research agenda here) but we should try to keep that 
notion of meaning separate from the other, perhaps more technical, 
notions. Since usages like "RDF meaning" when used with your sense of 
'meaning', sound to us like insane hubris (it has the connotation 
that RDF has somehow captured in its semantics - ie its model theory 
-  an entire account of English meaning, or human thought), could we 
perhaps agree to use a less ambiguous terminology? For example, how 
about some invented phrase like 'web meaning', or 'social meaning' or 
something like 'full meaning'. So one might say, the web meaning of a 
piece of RDF is more than its (strict) RDF meaning, and happily agree 
that the phrase 'web meaning' has, as yet, no exact specification.

----
I grok the general point: The RDF might 'carry' more meaning than it 
in some strict sense expresses. The full web meaning is determined 
socially, and may be specified by any means: grounding of RDF terms 
in human-readable English definitions, diagrams, whatever; all using 
conventions that link the RDF to the world in some way that goes 
beyond what can be expressed in RDF.

What I find technically unsettling in your reply is your reliance in 
English (NL) glosses to ground meaning. There are many problems with 
this. First, English is itself only a language, and is just as much 
in need of grounding as any formal language; it gets that grounding 
from the human society that uses it to refer to the world that the 
humans see, hear, taste, feel and even imagine; and *that* is where 
the actual grounding in reality occurs, not in English. Second, many 
computational systems are grounded in the world without going through 
human speakers of English (I'm thinking of machines with sensors, 
bank computers handling bank accounts, cameras with facial 
recognition software, things like that) and so the 'meanings' of the 
terms they use will not usually need to be given an English gloss, 
and in fact they will probably not be accurately captured by any 
English gloss, eg what does "see" mean when applied to a smart bank 
security system using infra-red sensors? Third, we don't actually 
have a precise account of English meaning to rely on, so we are 
hamstrung from the start; and fourth (this is a minority view of my 
own, but I hold it passionately)  human natural language in fact 
isn't very well suited to specifying meanings. It evolved for 
situated communication between humans using a narrow bandwidth 
channel, not for specifying meanings for use by an inference process, 
and the evolutionary pressures often went in divergent directions; eg 
English is ambiguous, lexically overloaded, contextual, tensed, and 
full of allusions, ironies, metaphors, poesy and other stuff which 
delights the human left temporal lobe but which is nightmarish in a 
specification language. So using English as a grounding for meanings 
is like building on mud.

>Long answer:

[ Most of the comments to which are written (before the above) from 
the AI/KR perspective on 'RDF meaning', where it means 'expressible 
in RDF', not your full meaning. ]

>On Wednesday, May 29, 2002, at 03:43 PM, patrick hayes wrote:
>
>>>----- Original Message -----
>>>From: "Brian McBride" <bwm@hplb.hpl.hp.com>
>>>To: <timbl@w3.org>
>>>Cc: "RDF Core" <w3c-rdfcore-wg@w3.org>
>>>Sent: Tuesday, March 26, 2002 1:38 PM
>>>Subject: help wanted: RDF issue rdfms-assertion
>>>
>>>
>>>>  Tim,
>>>>
>>>>  The RDFCore WG seeks your help with an RDF issue, rdfms-assertion:
>>>>
>>>>     http://www.w3.org/2000/03/rdf-tracking/#rdfms-assertion
>>>>
>>>>  [[
>>>>  Summary: RDF is not just a data model. The RDF specs should define a
>>>>  semantics so that an RDF statement on the web is interpreted as an
>>>>  assertion of that statement such that its author would be responsible in
>>>>  law as if it had been published in, say, a newspaper.
>>>>  ]]
>>>>
>>>>  The WG believes that this issue originates with you.
>>>>
>>>>  I would like to clearly establish what it is that you would like from us.
>>>>
>>>>  A number of concerns have been raised about this issue:
>>>>
>>>>     o RDF is just one of several specifications that are 'in play' when an
>>>>  RDF statement is retrieved from the web.  What is the minimum the RDF
>>>specs
>>>>  must say to achieve the effect that you want.
>>>
>>>I think that it should say that the predicate determines the meaning of any
>>>statement.
>>
>>? What does that mean?
>
>[See below**]
>
>>  (I can only interpret it as something that is obviously false, so 
>>I must be misunderstanding it.
>
>Thank you.
>
>Suppose a document in RDF parses to the following statements:
>
>_:b dc:title "Moby Dick".
>   _:b dc:creator  _:c .
>   _:c  contact:email <mailto:phayes@ai.uwf.edu>.
>
>People actually write documents which parse to statements like that. 
>Libraries work only because people accept that such things have 
>meaning.

Yes, *people* accept that, and libraries are used by people. But that 
isn't the point here. The point is what *software agents* can 
understand, right?

And for the record, and speaking now as a person, I wouldn't have 
read that RDF to mean that I was the author of Moby Dick; I would 
read it as saying something like "if you want to find out more about 
the author of Moby Dick, then send Pat Hayes an email". (It seems odd 
to refer to people by their email boxes: what about all the lucky 
souls who don't have an email account? How would you say that 
Melville wrote Moby Dick?)

>These statements are taken to mean that you are creator of something 
>called "Moby Dick".  Leaving aside niggling over details, time, etc, 
>you have to go along with that.

Who says I do? Even as a human being, on what basis must I go along 
with assuming that this RDF means the same as your English gloss of 
it? I don't find that at all obvious, and it certainly does not 
follow from the RDF spec, or from any of the conventions outlined in 
the RDF spec. (It might be possible to extract it from the code of 
the library system that used it, by noticing that it - the code - 
drew certain conclusions that only made sense under that assumption. 
Under those circumstances I might agree with the claim, but only 
because the code is now part of the specification of the meaning of 
the RDF, which is stretching the point, but not intolerably. But to 
claim that a piece of RDF means something just by fiat seems silly.)

>If you are, they are true; if you are not they are false.
>
>If, for example, I accept the assertions of a library card to this 
>effect, then to be simple I now know you wrote such a thing.  To be 
>complicated about it, the possible worlds which I can  consider this 
>world as being among have been constrained to those in which you did 
>write such a thing.

Its not clear that this semantic way of talking makes sense in this 
context. It would if we had a model theory for English, but 
incorporating one of those would make RDF into a *much* more 
complicated kind of beast.

>  (I am sure one could be much more complicated - but that is not the 
>object of the exercise!))
>
>Now Peter's RDF engine will of course not know this, as you can't 
>describe creatorship in RDF from scratch, and he's  not prepared as 
>calling peter:RDF anything which involves inference using anything 
>other than the RDF spec. Which is limiting, and not what RDF is for.

I thought that this was exactly what RDF was for. I have never heard 
or read anything that suggests otherwise.

>Peter's interest in the set of inferences you can make from a 
>statement is of course useful, but saying that there is only one set 
>is not.

Useful or not, it is true; and follows in fact from the RDF specs 
themselves. Well, to be exact, there is one set of RDF-valid 
inferences you can make. Making other inferences from something is 
*possible*, of course - generating random RDF graphs and calling them 
inferences is possible - but its not RDF, any more than inferring "Je 
suis faim" from "Tengo sed" is English.

>In fact, they hard fact of life on the web is that you learn stuff, 
>and some people know more than others, and some machines have 
>greater capabilities than others.

Of course, but that is irrelevant to the point here. The issue is 
whether that stuff that you learn is written in RDF or not, and 
whether those capabilities are sanctioned by the RDF specs or not.

>Let me show you what I mean in another way-- in the negative -- what 
>I want to exclude.
>Above, dc:creator is the predicate.  It is defined, (say) by the dublin core
>that the meaning of a statement x dc:creator y is that x wrote, painted or
>otherwise created a work y.

Wait. HOW is is so defined? If the dublin core just say this in 
English then they are only defining their intent, not the actual 
meaning of the RDF terms. The only way to define meaning in any 
formalism is to write expressions IN THAT FORMALISM which capture 
that meaning by restricting the space of allowable interpretations. 
If one wants to invoke other machinery - as for example is done in AI 
robotics, where sensory inputs are related directly to the physical 
surroundings of the machine - then those 'grounding' links to a world 
need to be specified as part of the semantic account of the formalism 
itself, There are no magic routes to putting knowledge into machines.

>Now suppose I define the resource  w3c:tim  in a namespace I control, as
>follows:
>1. w3c:tim is a person, with email address <mailto:timbl@w3.org>
>2. w3c:tim is defined such that any statement of the form  w3c:tim 
>dc:creator :y  means that Pat Hayes should immediately send me a 
>crate of claret.

I'd like to see the RDF graph that says this.

>This would mean that anyone who uses the dublin core vocabulary to 
>describe me would end up, by my definition of the term which I have 
>introduced, stating that you should send me some wine.
>
>What's the problem?   Informally, it violates the actual practical 
>way RDF works

What actual practical way? Seems to me that there is hardly any 
actual practice to appeal to, and that in fact this kind of thing is 
going to happen as soon as RDF is widely deployed, since there is in 
fact absolutely no way to prevent anyone writing anything using any 
vocabulary they like. I can write all sorts of misleading things in 
my RDF graph using your vocabulary, and how can you possibly stop me 
doing that? After all, you *published* the terminology. I think the 
first amendment gives me the right to *say* whatever I like using it. 
All you can hope is that a third party will take what you say as 
having more authority than what I say, since the terms are yours. But 
that seems like a slender reed to base a theory of meaning on, if 
definitions can be outvoted.

>, and in fact english too.  The verb defines the meaning of the sentence.

?? I really fail to follow you here. How does a verb *define* the 
meaning of an English sentence?

>  In fact, a huge amount of what we do we use rules which select on 
>the predicate, and the idea that there be some subject or object out 
>there which feels it can override the meaning of the predicate would 
>cause everything to fall down.

Well, tough. Earthquakes happen.

>Now most of the meanings of Properties ar currently defined in english.

Sorry, I deny this. They are NOT defined in English. The only way to 
define meaning for RDF  (DAML, OWl, KIF, ....) is to write RDF (DAML, 
OWL, KIF,...). The English commentaries and comments and glosses are 
just that: comments and glosses. They no more define the meaning of 
RDF than comments in Java code define what happens when the code 
runs. They may well express the intentions of the human writers of 
the RDF, but that is irrelevant to any software which uses the RDF 
(unless the software can read and understand the English, of course; 
but that isn't RDF inference.)

>The exceptions may become a formal derivation of numbers, but I 
>don't think even then that will be used in practice.
>
>In a level where you are not looking at what information comes from 
>where (you have no quotation) and the only rules are the ones from a 
>fixed set of specs, this of course does not apply as you are not 
>actually saying anything about the real world or using any real 
>world classes or properties.  And then when you slip into using RDF 
>to talk about the real world, you are so used to looking to the 
>predicate of a triple for meaning that you don't even realize you 
>are doing it.  But we do have to formalize it so that it is possible 
>on the sweb for someone to introduce a term and define it.  Even 
>though the logic doesn't have separate language for "is defined to 
>be".
>
>>>It should specify in the specific case of predicate rdf:type that the
>>>definition of rdf:type is that the object determines the meaning of the
>>>statement.
>>
>>It cannot say that, because that is either false or meaningless.
>>  Rdf:type simply asserts that something is in a class; it does not 
>>define "meaning" (either of the term denoting the object or the 
>>expression denoting the class)
>
>The way I am using "meaning" here, neither of these have it. Only 
>formulae have meaning (or, loosely, documents which parse to 
>formulae).

?? Well then, how does a class name (the object of an rdf:type) 
determine meaning?

>
>>  and it doesn't really "determine" anything, since at best it can 
>>only be said to *constrain* possible meanings, rather than uniquely 
>>determine a meaning.
>
>
>
>>>It should then hand off to the URI spec to say that "determines" above means
>>>that those publishing issuing or owning terms are the ones who definitively
>>>define (through specs etc) what they mean.
>>
>>But that is impossible in RDF, since the full 'meaning' of a term 
>>depends on the total graph of which it is a part, and this may have 
>>been assembled from a variety of sources. So these sources all 
>>contribute to the 'meaning' of the term; it cannot be said to 
>>derive solely from any one of them.
>>
>>>  Issues of
>>>ownership, and dereference are covered not in the RDF spec but
>>>directly or indirectly in the URI spec.
>>>
>>>>     o Whilst the RDF specs might say what a statement means, that meaning
>>>>  might be modified by its context.  For example, what about an RDF graph
>>>>  entitled "Myths about Namespaces".  Would the publisher of that graph be
>>>>  asserting the statements therein?
>>>
>>>*** The role of the RDF spec is to state what an RDF document means. ***
>>
>>What the RDF spec says is that the meaning of an RDF graph is 
>>expressed by the RDF model theory, and what that means is, roughly, 
>>that the meaning of an RDF graph is expressed as a constraint on 
>>the world being described, that it must make the graph true. Each 
>>document defines a graph.
>
>Saying that the meaning of the graph is expressed by the MT does not help me.

But that is what the RDF spec says the meaning is. I don't see how it 
could say anything else, in fact: what is it going to say, that the 
meaning of the RDF is whatever anyone says the meaning is? That 
hardly reads like a specification.

>Not when the document parsed to form  the graph is a check (cheque) 
>and the bank says it doesn't mean anything.
>
>In the long term, bits of MT will no doubt be added which relate a 
>check to other terms in useful ways, but we have to start (and end) 
>with english definitions of key things.
>
>>If you have something more in mind by 'state what an RDF document 
>>means', then please tell us what it is. If by 'meaning' you mean 
>>something like a single unique meaning that can be determined 
>>computationally, then it is impossible for any spec to provide it. 
>>That is not a reasonable expectation for any formal specification.
>
>Yes, you cannot determine or express the meaning of dc:author 
>computationally unless you just link it to other terms which are 
>just as impossible.

No, things are not that bad. Its true that any description needs to 
be grounded eventually, but one can do a lot is a reasonably 
expressive ontology language. Quite a lot of content can be expressed 
in a computationally useful way. Seems to me that is the main point 
of having the SW at all, to make some of this machine-usable content 
usable by web engines.

>>>The role of SMTP spec to say that a message delivered under certain
>>>circumstances is
>>>a message from one party to another.
>>>
>>>In other words, other protocols deal with the question of who is asserting
>>>what.
>>>Typically these things are complex and recursive, but the common point of
>>>reference is the meaning of a document.
>>
>>I really think it would be more useful if you didn't take this 
>>line, as it doesn't lead anywhere. There is no such thing as THE 
>>meaning of a document, particularly of a document in a formal 
>>language.
>
>(Speak for your own documents! ;-)

Well, apparently your documents are susceptible to multiple 
interpretations, since I seem to have misunderstood them. That seems 
like the normal situation: we can't always say everything we mean. 
Documents have many possible meanings, usually.

>It is curious that above you ask me, "? What does that mean?"  of a 
>document I wrote.  It looks as though you would like there to be a 
>meaning.

I was speaking as one human being to another (and also informally, 
rather than as someone trying to produce an overarching theory.) The 
semantic web, as I understand it, is supposed to consist largely of 
software agents communicating with one another. They won't be able to 
understand English any time soon. So I don't really care about any 
'meanings' that are invisible to the bearers of the information. I 
want to know what *they* know about what it means, since it is what 
they are inferring and deciding to do that I have to worry about.

>RDF is not just a formal language.  It has ground terms which are 
>grounded in english (etc) prose which relate to the real world. That 
>is how it works. 

I'll accept that idea when you (or someone) comes up with at least a 
beginning of an account of what it means for something to be 
'grounded in English prose'. Years in AI have left me with a very 
cynical view of aspirations like this, which are usually based on 
delusions of grandeur about what formal languages actually mean.

>That doesn't invalidate the logical operations.

Well, it might. That is part of the problem: if you allow meaning 
specifications this broad and underspecified, then anything is 
possible. I could say in a comment that <ex:foo> means childhood on 
Tuesdays but aspidistras on Thursdays.

>>  There are several precisely defined variations on 'meaning' that 
>>you could use: for example, we can say what it means to draw a 
>>valid conclusion from a document, or what it means for two 
>>documents to be consistent with each other, or what it would mean 
>>for a document to be true; but we cannot say what a document 
>>'really means'.
>
>I want to say what a document means.
>You say I can say what it means for a document to be true.
>I think that would be the same thing.
>I think to say what it would mean for the fact that a document is 
>true to be true would mean the same thing.
>
>So, maybe your philosopher's fear of the word "meaning" would be 
>averted if you consider "what a document means" to be a shorthand 
>for "what it would mean for a document to be true".

That would certainly avoid a host of philosophical-logic 
complications, so is a step in the right direction. However, bear in 
mind that truth is a relationship between a document and a *possible* 
world. Its kind of hard to say what the *actual* world is.

>>
>>>
>>>>     o Some on the WG do not believe that the WG is empowered to make law;
>>>>  that is a matter for the lawyers, governments, parliaments and the like of
>>>>  the many countries of the world. Different countries may make different
>>>laws.
>>>
>>>They are right, RDF Core cannot determine the punishment to meted out to
>>>an individual who makes a false statement in  given case and
>>>a given jurisdiction. However, it is vital that RDFCore explain concisely
>>>and
>>>unequivocally the algorithm for  determining the meaning of an RDF document
>>
>>?? What algorithm for determining meaning? (Do you mean, algorithm 
>>for checking validity of inference? We can do that.)
>
>
>
>>>so that legal folks have a sound base for their own arguments, but no
>>>basis for wriggling out between the specs.
>>>
>>>Note that RDF specs are referred to by XML specs (via the namespace)
>>>which are referred to by the MIME registry which is referred to by the HTTP
>>>spec which is referred to by the TCP port registry, which is referred to
>>>by the TCP spec, which you effectively agree to when you get an IP
>>>connection.
>>>So there is a well accepted and important chain of delegation, in which
>>>RDF plays a role of one link.
>>
>>Until you get to RDF, this is all to do with computable operations 
>>over computable domains, so has well-defined notions of meaning 
>>based on fixed-point semantics. RDF is where it starts talking 
>>about the wider world outside the recursive universe of 
>>computational processes, and that is where 'meaning' suddenly gets 
>>far more difficult to pin down.
>
>No, it starts before RDF.  An SMTP message, to TCP port 25 on an 
>internet host, saying "From: xxx"  MEANS that there follows a 
>message from party xxx.  This is a real world connection.

Doesnt it actually mean that a certain account on a computer has sent 
the message? If someone sneaks into my office and sends an email on 
my machine, it will say "From:phayes@ai.uwf.edu", but it wasn't me 
hitting the keys. Seems to me that the entire apparatus of 
SMTP/TCP/FTP is entirely inside what might be called the global 
computational domain. (Once we have webcams plus facial recognition 
software, things might get genuinely real-world, for example.)

>  The machinery communicates my indent to address you with a message, 
>and society will hold me to having done that.  The meaning of the 
>message is normally human-readable, but in the case of an OFX bank 
>statement download, it is machine processable and yet defined in 
>english.

I'd say that it was defined by the code that processed it, 
ultimately. Any claims about meaning that are not somehow embodied in 
the code are just that, claims. And they are false claims.

>
>>  The universe as a whole does not satisfy the second recursion theorem.
>>
>>>
>>>(See my www2002 keynote)
>>>
>>>>     o Do you expect us to define exactly what an RDF statement means?
>>>>
>>>>      _:b <rdf:type> <foo:Liar> .
>>>>      _:b <foo:email> <mailto:bwm@hplb.hpl.hp.com> .
>>>
>>>
>>>Yes. By delegating to the specification of the Properties and Classes
>>>used as predicate and (in the case of rdf:type predicate) object.
>>>
>>>>  What chain of evidence would be required to prove that this is  a
>>>>  derogatory statement about me.
>>>
>>>The chain would be  that I mentioned above showing that the
>>>definitions of foo:Liar and foo:email define the meaning of the document.
>>
>>But there are no definitions in RDF.
>
>The definitions are almost completely outside RDF.  The DAML+OIL 
>spec for example has some definitions of DAML+OIL terms. They are 
>definitions in the sense of authoritative statements in that they 
>are made by the owners of the terms and published as such.

They define the meanings *in DAML*, not in RDF. DAML and RDF are 
different languages. (This is just normal usage of this kind of 
terminology, right?)

>>  So this can only mean, at best, that there are some RDF assertions
>
>no some english

English isn't RDF, so if you are saying it in English then you aren't 
saying it in RDF. Come on, this is just good usage of terminology. 
Its ridiculous to say that anything that can be said in English is 
"in RDF". RDF is a formal language for machine use, with a tightly 
specified syntax and model theory. Given that specification, I can 
PROVE that not everything that can be said in English can be said in 
RDF. You can't say "P or Q" in RDF, for example. It doesn't matter 
how much English you write about it; if the English says that the RDF 
expresses disjunction, then the English is just plain wrong.

>>(in a graph somewhere) which are sufficient to constrain the 
>>possible interpretations to those worlds in which Brian is, in 
>>fact, a liar.
>
>yes.
>
>>  And that in turn requires that the concept of 'liar' is somehow 
>>expressible in RDF, which is a pretty ambitious claim to make.
>
>which is why i'm not making it

But it seems to me that you are. That is what it means to say that 
some RDF expresses this content. If it can't be expressed in RDF, 
then its not in the RDF. You can't have it both ways. As Peter said, 
this isn't RDF, its RDF+ (mean what I say). Of course you can express 
anything in RDF+ MWIS, but the RDF part isn't contributing much to 
the mix.

>>  Suppose Brian sued me and I said in response that the term 
>>'foo:Liar' was not intended to express the derogatory English 
>>meaning of the English word "liar", and challenge him in response 
>>to show how any conclusion that would be harmful to him could be 
>>derived as an RDF-valid entailment from my RDF graph. Would that be 
>>a reasonable defense, in your view? I would find it convincing, 
>>myself.
>
>The conclusion that he is a liar is damaging.  The foo spec states 
>that that is what the x rdf:type foo:Liar means.

OK, I concede that this might stand up in court, but only because a 
*human* reader of the spec and the RDF could come to this conclusion. 
But then if this is the criterion for meaning, then meaning on the 
semantic web is trivial. We can just send numbers to one another, and 
my spec will say "15" means that Brian is a liar. If I then publish 
"7+8", can Brian sue me?

>
>>>To then show an HTTP response from server for foo, which has
>>>been, though established social procedures and technical specs of DNS been
>>>demonstrably
>>>delegated the ability to publish information by the owner of the foo.
>>>That response could contain information in a suitable language
>>
>>What does 'suitable language' mean? Does it have to be suitable for 
>>use by RDF reasoning agents?
>
>No.  There are more things in heaven and earth, Horatio, than can be 
>dreamed of in RDF.

Well then, why did you make it the base layer of your famous diagram, 
that has been giving us all such a hard time? Many people take this 
to mean that all the stuff on top has be encoded in RDF.

>No wonder folks have trouble layering DAML+OIL on top of RDF -- 
>sounds like a problem using RDF for any meaning at all.

Several of us have been wondering about that, indeed.  (Now, if RDF 
had been, say, FOL, then we might have had a fighting chance.)

>
>>>which
>>>indicated
>>
>>Indicated to what/who? To a human reader, or to a software agent? 
>>(Does the software agent only know RDF, or does it also know DAML 
>>or OWL?)
>>
>>>that
>>>foo:Liar was a class of people who were liars, and that foo:email was
>>>an emailmox which a person used, then the chain would be complete
>>>about the meaning of the document.
>>>
>>>There is a simple step to show that no one else has your mailbox.
>>>
>>>Now suppose that document were published by sending it to
>>>a public email list.  There is an indisputable body of history which
>>>accepts that such a message is considered a public assertion by the sender.
>>>So you could sue.
>>
>>Yes, but you would be suing because it was a public assertion *in 
>>English* to *human readers*, which has got nothing at all to do 
>>with RDF.
>
>I am exactly saying that it has.

Then I really fail to see what your vision of the semantic web 
amounts to, or how it differs from the existing web. Its just more of 
the same, right? Its content distributed on websites written by human 
beings for use by human readers, perhaps after a bit of processing to 
make it look prettier. What is the RDF *for*, if it means the same as 
the English? Why not just put the English on the web page? Surely the 
idea is to make some of the content accessible to machine use. That's 
the part of the 'meaning' that is relevant to the SW.

>  While our logic may be nice for defining numbers, it can't define 
>and shoes and ships and sealing wax. (Though no doubt some dream...)

It can't define them, but a good KR formalism can describe them in 
enough detail that one can recognize what is being described. Which 
is all that we can do in English, in fact. You can't define natural 
kind terms in *any* language; its nothing particularly to do with 
logic. (I find that logic often gets a bad press here because it was 
originally designed by mathematicians who were indeed interested in 
defining mathematical concepts. But that was in the 1890's; we've 
gotten past that long ago.)

>
>>The same slander case would probably work if RDF wasn't involved 
>>anywhere, and you just had the character string 'Brian McBride est 
>>un fichu menteur' on the web page. (Notice the use of quotation in 
>>the previous sentence to mention, rather than use, a character 
>>string.)
>
>Yes.
>
>>>  You couldn't if the document were sent in an attachment
>>>as attachments break the chain, unless there is a something in the cover
>>>note
>>>(e.g. "I agree with the enclosed") to connect the chain of assertion.
>>>
>>>It is arguable what happens if it is published
>>>on a website.  Normally it is clear (for example though links from someone's
>>>home page) which documents published are deemed to be asserted, and which
>>>are archive copies of other people's things, for example.
>>
>>Sure, but here you are talking about human assertions, right? That 
>>is, assertions made in the context of human society and human 
>>discourse, using human language. RDF isn't a human language; it's a 
>>new kind of thing: a formalism for use by software agents which is 
>>also public in a human world. I wonder if the courts are ready for 
>>this; I suspect they will have to deal with a whole new set of 
>>issues that have never arisen before.
>
>They will have to deal with (1) the ownership of terms being rather 
>well defined, and less easy to argue about, particularly because if 
>you don't like foo:Liar you can go define pat:Liar in your own 
>space; and also with (2) some small aspect of terms being 
>representable in formal axioms.  Here daml:transitiveProperty  is a 
>happy exception, as its axioms leave nothing really to be said in 
>addition.  Or it will be an exception when you get a complete 
>axiomatic definition when you look it up on the web.
>
>These two changes will make automation and validation and stuff 
>simpler in a lot of ways. It still won't stop people arguing about 
>what "fair use" and "in good condition" mean.
>But the MT only helps with (2).  It is (1), the ability to introduce 
>new terms, which allows the use of RDF and the layering upon it.

Perhaps you could explain that point in a little more detail? That 
is, I don't think the rest of us know what you have in mind here, and 
we are floundering trying to make sense of 'layering'.  I don't see 
how the ability to define new terms helps with layering at all. The 
central issues seem to be to do with semantics and syntax, not with 
the terms involved. Can you give a simple (toy) example to illustrate 
the point?

Pat Hayes

-- 
---------------------------------------------------------------------
IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
phayes@ai.uwf.edu 
http://www.coginst.uwf.edu/~phayes
Received on Friday, 31 May 2002 14:53:45 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:48:17 EDT