- From: pat hayes <phayes@ai.uwf.edu>
- Date: Fri, 21 Feb 2003 16:14:45 -0600
- To: Brian McBride <bwm@hplb.hpl.hp.com>
- Cc: Graham Klyne <Graham.Klyne@MIMEsweeper.com>, jjc@hplb.hpl.hp.com, pfps@research.bell-labs.com, las@olin.edu, timbl@w3.org
(I'm sending this to two mailing lists by BCC to avoid cross-posting.) >At 11:16 18/02/2003 +0000, Graham Klyne wrote: >>At 10:43 PM 2/13/03 +0000, Brian McBride wrote: >> >>>At 21:32 13/02/2003 +0100, Jeremy Carroll wrote: >>> >>>>I am posting this message to three lists, sorry for duplicate copies. >>>> >>>>There has been a significant discussion on the social meaning >>>>parts of the RDF Concepts Last Call. >>> >>>Really! Where? >> >>There's been some discussion on WebOnt, starting here: >> http://lists.w3.org/Archives/Public/www-webont-wg/2003Jan/0280.html >> >>Also, it doesn't count as discussion, but I indicated a position here: >> http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Jan/0228.html >> >>But I'll agree with you that there's not yet been sufficient >>discussion to see where this is going. > >Thanks Graham, the pointers were very useful. > >Jeremy is suggesting - lets see if we can find a form of words that >satisfies everyone. I'm hoping that doesn't mean fudging the issue. >I'm also very concerned that you won't be present if there is a f2f >discussion at the tech plenary. Maybe we should be thinking about >dialing you in? > >I'm also wondering about laying some of the groundwork. I'm seeing >a lot of very unstructured discussion, and I fear there is great >risk of confusion clouding the discussion. > >Do you and Jeremy have any ideas on how we might best >prepare/clarify the question. Here's my 2c worth. I really think this a basically a matter of getting the wording straight. -------------- Summary. 1. In order to achieve conformity to the RDF (and other) specifications it is sufficient to refer solely to the formal semantics as described by the specification documents (and the syntax, etc., of course.) Nothing in what follows implies that there is any requirement that RDF conformity of any RDF parser, editor, reasoning engine, etc., can depend on anything other than the formally defined syntax and semantics. 2. Using Lynn's terminology, (http://lists.w3.org/Archives/Public/www-webont-wg/2003Jan/0301.html) RDF assertions in actual use on the Web are intended to be part of larger 'systems' of meaning in at least two senses: a formal system of meaning, defined by the model-theoretic semantic specification(s) of RDF and any semantic extensions (such as RDFS and OWL) which may be in use, and a social system defined by norms of use, legal obligations, and generally by what Lynn calls "affective semantics, ie what work the terms can do in the world". Clearly, the latter does not admit of the kind of mathematical description that is available to define the former, and also unlike the former, cannot itself be constrained or even precisely delineated by any working group or standards body. 3. Even though social meaning cannot be defined precisely, it can be referred to; and there is a need to refer to social meaning, particularly in view of this intended usage of content-bearing formalisms in a public setting (as in the SW vision) being relatively new and untested. It is important to the intended mode of use of RDF that any social meaning applied to RDF usage at least be *conformant* to the formal meaning. This is a very weak constraint, but it is not entirely trivial, and it may be relevant to writers of other software which is intended to use RDF-encoded information or to interface with RDF-conformant reasoners. 4. The nature of this 'formal meaning conformity' is that *any* meaning assigned to RDF, in *any* system of meaning, *should* be such as to be preserved under any formally valid RDF entailments, and be recognized as being so preserved. "Should" here means that any other assignments of meaning are disavowed by the spec as inappropriate, and if they are imposed on RDF, then even conformity to the formal meaning part of the spec will not be sufficient to guarantee that the RDF machinery will not change that assigned meaning inappropriately. This is not a formally exact constraint since its scope is too wide to admit a formally precise statement, but it is both reasonably precise (IMO) and an accurate statement of the intentions of the designers of the language for its intended domain of use; and, it is important for interoperability that the RDF spec clearly state that this is intended to apply to all intended uses of the formalism. 5. An example of the need for this statement arises when considering the problems which could arise in interfacing RDF produced by an RDF-conformant piece of software with another piece of software which performs inferences which are not RDF-valid. If the second, non-conformant, software performs inferences which are valid *relative to RDF interpretations satisfying extra semantic constraints* (eg an OWL reasoner) then the overall system satisfies this requirement of 'formal meaning conformity'. But if it performs inferences which violate the basic RDF semantic requirements, eg non-monotonic inferences in the RDF vocabulary, then the overall system may not be conformant. While any non-RDF engine is not, of course, required to conform to the RDF specs, the difference between these two conditions, when considering global interoperability and the possibly corrupting effect of invalid inferences elsewhere on the Web, is sufficiently important that it seems appropriate to draw attention to it; and the general notions of interpretation, entailment and validity are sufficiently precise and also in sufficiently wide use (ie not RDF-specific) that the constraint can be usefully understood and applied. 6. More broadly, there is a possible misunderstanding about 'formal meaning' that needs to be explicitly addressed in the specs, to the effect that formal meaning is socially meaningless, and therefore any formally derived conclusions can have no affective semantics. It is important to explicitly deny this misunderstanding, since this false assumption would render the intended uses of RDF impossible. The denial really amounts to little more than the observation any affective semantics assigned to any RDF should also be understood as thereby assigned to any formal conclusions drawn from that RDF; but, vide 1. above, this is not the claim that such affective semantics is in any sense contained within the formal meaning, or in any way influences the formal validity or otherwise of any inferences. 7. The last point can be illustrated by a simple example in which a formal RDF entailment is used in a setting which clearly is intended to convey a social meaning. Suppose a retailer A publishes an RDF-marked-up online catalog in which the products are named as RDFS classes for use by automated RDF reasoners, and the website asserts in some HTML-encoded text that "Frobs are available for delivery in two working days". Suppose a customer's RDF reasoner uses the published RDF to conclude that something is in the appropriate class: Part#345 rdf:type A#Frob . The 'formal meaning conformity' condition would say that the customer was justified in concluding that Part#345 would be delivered in two working days. This is not derivable from the published RDF alone,is probably not formally derivable by any piece of software, and is not actually stated as such in the catalog (which does not mention Part#345): but what is formally derivable is that the Part in question is in the class concerning which the retailer socially, ie publicly, gave an assurance of service; and the formal meaning conformity condition requires that the formal conclusion be suitably interpretable in the meaning context of the assertion from which it was derived. The mechanical use of a valid formal inference process does not automatically erase the normal social intent of a promise of delivery, or somehow cancel any affective meaning attached to the class name. In contrast, and to illustrate that this condition is nontrivial, note that it would clearly be irrational to require the use of an invalid inference process to preserve such social meanings. ---- If Ive got anyone's viewpoint expressed wrongly, please correct. More contentious opinion: It has been claimed that *any* reference to social meaning should be expunged from the normative text of *any* specification document, on the grounds that social meaning has no precise definition, and that specifications should be concerned solely with the 'black and white' issues. This opinion is open to debate - I for one would disagree - but it is not valid as a technical objection, since specification documents are written in natural language, and routinely use terminology (such as 'intended use') which is widely understood but admits no precise formal definition. By the way, the use of normative language from RFC 2119 is intended, according to its author, to be appropriate whenever it significantly contributes to interoperability; which seems to me to be clearly the case here. So I don't consider it inappropriate to have normative parts of the spec referring to this issue. Pat Hayes -- --------------------------------------------------------------------- IHMC (850)434 8903 or (650)494 3973 home 40 South Alcaniz St. (850)202 4416 office Pensacola (850)202 4440 fax FL 32501 (850)291 0667 cell phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes s.pam@ai.uwf.edu for spam
Received on Friday, 21 February 2003 17:15:29 UTC