Re: help wanted: RDF issue rdfms-assertion

Pat,

Again, I'm seeing this "formalism vs implementation" thing throwing up 
dust.  I think I have an inkling of what Tim is suggesting, and I don't 
think it contradicts the formalization of RDF.  I don't know if I have the 
clarity of vision or command of language to explain this, but I'll give it 
a shot.

In one sense, the RDF model theory (MT) doesn't actually tell us what any 
bit of RDF means:  that's handed off to a separate set of definitions - an 
Interpretation - and (in general) many interpretations are possible for any 
given piece of RDF.  Rather, the MT says something about the range of 
possible interpretations (possible worlds) corresponding to a given piece 
of asserted RDF.  The model theory also gives us a well-founded notion of 
entailment, which in turn underpins some valid rules of 
inference.  Further, as you have shown with the RDFS-entailment, if one 
restricts the form of interpretation considered then a greater number of 
inference rules can be supported.

I think that Tim is referring to the use of external (i.e. 
extra-RDF-formal-system) definitions of intended interpretations, and 
putting in place some (non-RDF-formalized) framework for establishing the 
actual interpretations to be used in some assertion of RDF.  So when I 
publish RDF that offers a service for $100, you can't claim that I really 
offered it for 100 cents because some different interpretation was in 
effect.  And intuitively it seems to me that under some constrained 
interpretations additional inferences can be drawn;  e.g. an interpretation 
that constrains the terms "dollar" and "quarter" to be the monetary amounts 
familiar to most Americans would be able to infer that 4 quarters are OK 
for settling a dollar debt.  This can't be formalized in RDF, but I think I 
think the consequent relations can be taken as axioms under interpretations 
that are suitably constrained.

I think these mechanisms for defining or constraining interpretations 
clearly lie outside the scope of the formal RDF semantics, but that they 
are still important.  I suspect we're never going to be able to formalize 
everything about RDF usage, so we need to be thinking about how to make the 
formal and informal aspects play together.

(There's some other stuff in Tim's work, such as the inference mechanisms 
in cwm, which don't seem to be handled within the RDF formalization we have 
so far.  I don't see that as a major problem, provided that it is clear 
which parts of some expression can be treated according to RDF semantics, 
and which can't.  Which I think echoes your thoughts about "dark triples" 
or similar mechanisms.  But I think that's another discussion.)

#g
--

At 02:43 PM 5/29/02 -0500, 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? (I can only interpret it as something that is 
>obviously false, so I must be misunderstanding it.)
>
>>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) 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.
>
>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.
>
>>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. 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'.
>
>>
>>>     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. 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. So this can only mean, at best, that 
>there are some RDF assertions (in a graph somewhere) which are sufficient 
>to constrain the possible interpretations to those worlds in which Brian 
>is, in fact, a liar. And that in turn requires that the concept of 'liar' 
>is somehow expressible in RDF, which is a pretty ambitious claim to make. 
>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.
>
>>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?
>
>>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. 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.)
>
>>  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.
>
>>  In other cases,
>>there is explicit link from elsewhere -- such as a chumping in IRC which
>>agrees with the doc.
>>
>>>  The current model theory WD
>>>
>>>     http://www.w3.org/TR/rdf-mt/
>>>
>>>  in section 1.3 states:
>>>
>>>
>>>     [[Asserting an RDF graph amounts to claiming that it is true, which is
>>>  another way of saying that the world it describes is, in fact, so arranged
>>>  as to be an interpretation which makes it true.
>>>     ]]
>>>
>>>  Is this sufficient to meet your needs?
>>
>>No.  I would not want the above to be dependent on the Model Theory at all,
>>but asserted in the RDF spec.
>
>But the spec says that the model theory defines meanings. That is what an 
>MT is *for*, to define meanings.
>
>>The model theory does not as far as I know have such a spec hand-off, which
>>is essential to the meaning of RDF.  It only considers things you can know
>>by only taking into account the RDF spec, and so, while it gives a mapping
>>of RDF into set theory
>
>That isn't right. It doesn't map RDF into set theory or indeed into 
>anything else. It gives a mathematical account of the *relationship* 
>between RDF and possible ways the world could be. It uses set theory to 
>describe the world in mathematical terms, because its a mathematical 
>theory; but it treats RDF simply as RDF.
>
>>, it does not as far as I could see explain what an
>>RDF document means.
>
>Without a model theory (or some kind of semantics) it doesn't mean 
>anything. As far as I can see, this is the ONLY way that one could explain 
>what it means.
>
>>  (Maybe I am wrong and I missed it).
>>
>>>  Other means would be needed to
>>>  establish that a statement was about the world we live in and that it was
>>>  being asserted.  It seems that such claims could only be established from
>>>  the context in which the statement was used.
>>
>>So RDF for those claims relies on other specs which invoke RDF.
>>The RDF Core group should just define the meaning of an RDF document.
>>
>>>  The RDFCore WG has discussed other possible statements that it might
>>>  make.  The following text, which might be included in the primer,  was
>>>  suggested for discussion:
>>>
>>>  [[
>>>  Assertions made in RDF are analogous to assertions made in any other
>>>  language. The author and/or publisher of these assertions is responsible
>>>  for these assertions. It remains the responsibility of courts to determine
>>>  legal responsibility considering the effects of context and other factors.
>>>  ]]
>>
>>I think reference to the other specifications which invoke RDF is more
>>useful here.
>>It is *NOT* a good idea to give the slightest indication that you leave to
>>the courts
>>any discussion of the connections between IP, TCP, SMTP, MIME, XML and RDF
>>specs.
>
>Sure, because these are all technical matters than can be determined by 
>computers. But there is a final step, between RDF and the *actual* world 
>that it is supposed to be talking about, that is suddenly not computable, 
>and ultimately will, I suspect, have to be determined socially; that is, 
>by the courts, in the final analysis.
>
>>  > Brian McBride
>>  > RDFCore co-chair
>>
>>Tim Berners-Lee
>
>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

-------------------
Graham Klyne
<GK@NineByNine.org>

Received on Wednesday, 29 May 2002 17:00:56 UTC