Re: Social Meaning Boston 6 March

>Pat,
>
>Thanks for this. Jim had forwarded it to me sometime earlier, but it 
>was good to look at it again. Replies are interspersed.

Quick responses on a few points below.

>
>[snip]
>>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.
>
>How about the documents?
>
>>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.
>
>Well, perhaps. Standards are social constructs and an awful lot of 
>the work of standardization is seting norms of use, legal 
>obligations, etc. (Of course, there's the interesting feature that 
>W3C *recommendations* aren't standards, and the W3C itself isn't a 
>standards body.)

:) It is de facto, though. The standards bodies aren't set by God, 
after all; they are just as much upstarts, whose social authority is 
provided by de fact social recognition (and after some contact with 
the ISO, just as much 'industrial consortia' and governed by silly 
internal politics) as the W3C is. And the W3C has the nice feature of 
doing most of its work firmly in public, conspicuously unlike the ISO 
and the IEEE.

>  Where the Social Meaning section goes *beyond* the norms of even standard
>
>>3.  Even though social meaning cannot be defined precisely,
>
>Slide. Social meaning may admit of all sorts of precision, but 1) 
>not using the same exact tools of RDF like formal meaning and 2) not 
>by working groups of industry consortia.
>
>I think legislatures, courts, contract lawyers can bring a 
>considerable range of precision to these matters. I'm not sure 
>precision is even the issue. Indeed, it might be that normative 
>sections of standards documents are typically *overprecise*, e.g., 
>the constrain where they should be looser.
>
>Also, there is a difference between defining 'social meaning' and 
>giving a more or less formal mechanism for determining the 
>particular social meaning of an expression in a context of use, etc. 
>etc. etc.

I quite agree. I wouldnt even attempt to define it. I wouldn't 
attempt to define 'tree' either, but I have no problem referring to 
trees.

>I don't think the *former* has even been sufficiently crisply 
>defined (at the *very* least, in this document) to admit of very 
>much useful normative pronouncement. I don't think people even know 
>what they want to *accomplish* with such language, much less *how* 
>to accomplish it.
>
>>it can be
>>referred to; and there is a need to refer to social meaning,
>
>By the specification. I'm skeptical. With normative force? To what goal?
>
>Heck, we've not even got a clear account of how uris acquire 
>reference, and *that* is likely to be amendable to formal methods.

Totally agree, and would like us to get started on that.

>There is significant disagreement in the *expert* community, afaict, 
>as to whether the reference of an URI is fixed by stipulation (of 
>whom!), partially by definition (in formal onologies), by use, by 
>reference to natural language definitions, etc. --- settling this 
>usefully and sanely is the easier task!

Right.

>
>Ok, I exaggerate, somewhat. :)
>
>>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.
>
>This, to me, is an argument to be silent. A priori specification is 
>dangerous, and, actually, conflicting with the thrust of W3C process.

Whats the harm in saying something about what its intended to be used 
for? Even normatively? Its not like this makes non-normative use 
somehow criminal or dangerous. A spec's "normativeness" is just a way 
it has to say that some matter is seriously intended to be part of 
the spec.

>
>>It is important to the intended mode of use of RDF
>
>There is *an* intended mode of use?

Yes.

>  To the degree that this is made specific enough for me to believe 
>that we can make sensible claims about the needs of social meaning, 
>I tend to doubt that it actually the "defining" use of RDF.
>
>Even if it is the *intended* mode, so? The thing about language, 
>specs, etc. is that intentions (particularly of a relatively small 
>body of folks) don't dominate. We should *expend* that unintended 
>use will be the dominant use. Or, at least, we should be prepared 
>for that.

It might indeed; but that is irrelevant to the issue of making 
something normative *in the spec*. OK, people might turn out to 
ignore this and use it in some non-normative way. Anything MIGHT 
happen. But we can at least try to toss the damn ball in our intended 
direction., surely?

>
>>that any social meaning applied to RDF usage at least be *conformant*
>>to the formal meaning.
>
>But what does it mean to conform?

BE such as would be preserved under valid (according to the MT) entailments.

>How much does social meaning get to determine that conformance.

Thats a social question: but we give them the formal tools to do so.

>
>As I recall, the section roughly specified that the formal 
>inferences specified by RDF Semantics were social meaning preserving.

Right.

>But social meaning can vary greatly depending on whether it's 
>implicit or explicit, or an obvious or nonobvious implication. It 
>seems to be a perfectly sensible social norm to give people a chance 
>to retract or deny extremely disobvious or "distant" implications of 
>their assertions (properly formulated, I suspect this could be 
>formalized in a relevance logic, at least when dealing with the 
>justificatory explosion due to asserting a contradiction).

Well, the condition would rule that out. (Sorry, it really is a 
nontrivial constraint, which is why it needs to be said.) And there 
are good reasons to rule it out on the SWeb, right? Largely, you have 
no way to access the uses that produce the remote implications that 
you might want to retract, so you CANT retract them, its physically 
impractical to do so. So you had better not make them, if you don't 
want them out there causing trouble.  So although that might be 
social norm in human society, there are technical reasons why you 
can't rely on using it in the SWeb. So, as they say in my country, 
think on.

>
>>  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.
>
>Or take another example. Suppose there is a widely used, but buggy, 
>RDF reasoner (ok, take some stronger system, like OWL lite). People 
>work around the bug or work *with* the bug, expecting its behavior, 
>and accepting the social commitments produced by accepting the 
>social meaning of the (buggily) inferred statements.

Thats an interesting and awfully plausible example. I think that this 
would be a case where the actual use really did not conform to the 
spec., however. NOw, this could indeed happen: but why does the spec 
need to not at least TRY to make it clear that this is NOT the 
intention?

>Now, Joe Weasel knows this, and uses that expectation to get out of, 
>say, a payment because according to conforming reasoning, those 
>inferences don't hold.
>
>I'll bet that a court would find Joe Weasel in the wrong.

Probably.

>Or, at least, that holds with my current, shallow, understanding of 
>US law. Of *course* that law could change...do we want the RDF 
>Concepts and Syntax document to lead to that sort of change? Or be 
>used in support of that? Without having even talked with relevant 
>experts?

The wording was checked by legal guys in the W3C and they were happy 
with it. But I don't see the issue here. In your scenario, the spec 
says something, but the world ignores it. Then the world is on its 
own and the spec is irrelevant. OK, so why are you barking about the 
wording of the spec, in this case?

>
>>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.
>
>Is connotation a kind of meaning? That's typically not preserved. 
>Speakers meaning? (Is *that* a kind of meaning?) All this begs the 
>social meaning of formal entailment itself (as i said above). Of 
>course, that's sorta what you're trying to *establish*.

Right, exactly. We are making a golf club. Formally, this has a 
certain length, mass, strength, shape, etc.. BUt we would like to 
also say that it's supposed to be used to play golf with. Whats the 
harm in saying that? Even if people use it to mow their lawns 
instead, in fact?

>
>Hmm. Is concrete denotation presevered? Why? One thing that an 
>unexpected, unwanted consequence might cause us to do is change the 
>assigned denotation of the original expression. 6
>
>>  "Should" here means that any other
>>assignments of meaning are disavowed by the spec as inappropriate,
>
>How about just not covered? "results are undefined" (a standard 
>standards trope!)
>
>>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.
>
>That seems sensible to claim. Note that that's *WAY* weaker than 
>anything claimed in section 4. Sec4 says that you *cannot* make such 
>assignments.

In reading a spec, that is all that "cannot" can possibly mean, seems 
to me, ie "if you do, then don't blame us when it breaks: we told you 
couldn't do that". This isn't a Federal law we are writing, after all.

>This says that if you make such assignments, there's no spec-based 
>promise that things will work out "right". Caveat assigner.

Right, exactly. That is the nature of all specs, and all that 
'normative' language can possibly mean.

Lots more to say, but gotta run. See you in Cambridge??

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 Wednesday, 26 February 2003 19:16:28 UTC