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.

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

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.

> It is important to the intended mode of use of RDF

There is *an* intended mode of use? 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.

> that any social meaning applied to RDF usage at least be *conformant*
> to the formal meaning.

But what does it mean to conform? How much does social meaning get to 
determine that conformance.

As I recall, the section roughly specified that the formal inferences 
specified by RDF Semantics were social meaning preserving. 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).

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

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

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

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

Eh. How so?

I *really* worry about this with all the loose talk about expressivity 
(anything about anything, etc.), partial understanding, and "picking 
your schema"/style of inference. Right now, RDF doesn't tell us how to 
indicate that we're using a non-standard form of reasoning. Heck, it 
doesn't really tell us how to get out of assertional mode!

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

Ah! good example.

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

Interesting. Hmm. Need to think about this.

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

Ok. Hmm. Isn't my scenario above where you may not be committed to the 
"tricky" implications of your claims an example of a conformant system 
that doesn't transmit social meaning across RDF inference? Retraction 
could be in terms of the entire document, so no nonmonotonicity in the 
reasoner (I think).

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

I'm still a bit unclear on what the constraint is. Also, I suspect that 
many will claim (and working under Jim Hendler, I know at least one 
person who *will* :)) that the putative strength of RDF is, or ought to 
be, being able to *handle* that corrupting effect. Or, if not of RDF per 
se, of the semantic web. Now, whether imposing your constraint counts as 
properly handling it, well, I doubt that many such folks would find that 
satisfactory.

While a great believer in formal systems, and a lover of FOL, I think 
it's a *tad* rash to force things here.

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

Yick. Yes. Bad, that's bad.

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

In other words, formal meaning constrains social meaning. But no way. 
Not if social meaning is as broadly "not defined" as its been in this 
discussion. How can your spec contrain the *legal significance* of the 
implications of a licence expressed in rdf (see Creative Commons). Or, 
why *would* I be insulted by an implication that the original asserted 
didn't forsee?

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

Clearly there are *many* cases where this is fine and exactly what's 
wanted. Exhibiting such cases in an informative section would be, done 
right, a service and a good idea.

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

But is the retailer bound by that? Perhaps, perhaps not. They often 
aren't bound by errors, and, arguably, if they didn't *mean* for this 
implication to follow, that's an error.

OTOH, yeah, we typically want people to conclude such and retailers to 
go with it. This seems obvious.

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

The last is very, very true :) But that doesn't seem to be what sec 4 is 
getting at. Even if so, I don't see how that's something that needs to 
be *specified*, rather than just explained. *I* might be able to figure 
that out in my own little organic skull using the same valid formal 
inference process. Does anyone *really* think that it happening in my 
skull changes the "affective" meaning or social intent from what it is 
when processed by a program? Uh? Do we accept arithmetical calculations 
of sales tax by computer? Yes :)

If so, what does this have to do with formal meaning? Hmm. I mean, is it 
the *mechanical* use blah blah that is purported to kill the social 
meaning?

Hmm. I know some folks who think that it *should*, see:

	http://www.xml.com/pub/a/2002/05/29/perry.html

Now, Perry is something of a nutter, but his view is worth considering. 
I tried to analyze his argument and suggest that Semantic Web envisioned 
tech might help address his concerns:

	http://groups.yahoo.com/group/xml-politics/message/4

(The subsequent discussion is largely worthless, imho, alas) However, 
*certainly* the current langauge would inflame his worries (and make me 
agree with him :)). I'd be a lot *less* worried if it were 
non-normative, more of "results undefined" plus "one major intended 
use...".

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

Hmm. Not entirely clear to me.

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

Me too. "Black and white" indeed. Bah.

I did claim that getting the specification of the relation between 
"social meaning" (and gosh, wouldn't that vary with social system? 
internationalization just got much, much harder :)) is hard, and that 
the scope of section 4 was beyond that which was appropriate for a W3C 
working group. I mean, *prima facie*, sec 4 feels like an afterthought 
in this document. It seems like it would need a working group all on its 
own *at least*. Given that few, if any, members would pony up for such a 
group suggests to me that this is not the right place to do ti.

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

That's not my objection. My objection was that the scope tread into 
areas 1) outside the core competence of the group, 2) where the W3C, or 
the WG, have no proper authority, 3) there isn't enough time to do it 
right.

Something much more modest, along the scope of one aspect of what you 
proposed, seems reasonable. But, then it doesn't seem like it *is* 
normative.

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

Well, if we're talking about the current spec, I don't see reference to 
2119, so don't know how to interpret the appearances of those terms in 
the text. (This is a pretty large flaw, imho.C&AS is feeling more like 
M&S all the time :()

So, if this section were weakened to informative, I might not worry as 
much. If the normative claims were weakened sufficiently, I might not 
object. I'm not convinced that there *is* a sufficiently correct, 
substantial normative claim that reasonably satisfies the various 
interested parties and can be incorporated into this document in the 
time frame allowed. Your take is a much more plausible candidate, being 
fairly modest, but it still feels like it needs a bunch of time and 
discussion.

I worry about ending up with another dog like reification, frankly, even 
aside from the people who just can't live with  social meaning section. 
Where are the test cases? Where are the real world, non toy examples? 
Where's the analyses of actual practice? Etc. etc. I want to have 
confidence in the language before I admit it as a constraint.

Cheers,
Bijan Parsia.

Received on Wednesday, 26 February 2003 10:36:05 UTC