W3C home > Mailing lists > Public > www-webont-wg@w3.org > February 2003

Re: Social Meaning Boston 6 March

From: pat hayes <phayes@ai.uwf.edu>
Date: Fri, 21 Feb 2003 16:14:45 -0600
Message-Id: <p05111b3dba7c1bfdbd85@[]>
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.


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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:56:51 UTC