Re: help wanted: RDF issue rdfms-assertion

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

Long answer:

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.

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.
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. (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. 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. 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.


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.

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.

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, and in fact english too.  The verb defines the meaning of the 
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.

Now most of the meanings of Properties ar currently defined in english. 
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).

>  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. 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.


>> 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! ;-)

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.

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.  That doesn't invalidate the logical operations.

>  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".

>
>>
>>>     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.  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.


>  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.

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

no some english


> (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

>  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.

>> 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.

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

>> 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.  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...)

> 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.

Tim