Re: Social meaning discussion 6th March

>Jeremy Carroll wrote:
>
>>
>>tbl:
>>
>>>>>2. The meaning of the statement is defined by the definition
>>>>>of the predicate, as applying to the subject and object identified by the
>>>>>definition of the subject and object terms.
>>>>>
>>>>
>>>>
>>>>
>>
>>Danbri:
>>
>>>>This for me is the crux: do we mean the machine oriented 'definition'
>>>>in RDFS or OWL or N3, or some more rounded/scruffy/social notion 
>>>>of definition.
>>>>
>>>
>>
>>
>>I find Bijan's observation compelling
>>[[
>>But there's no vague, much less precise, definition of "defining 
>>information". And I'm a logical reasoner, will this information be 
>>opaque to me? (Well, if in German, yes, but *all* human reasoners?)
>>[...]
>>So it's formal meaning isn't fixed IN ANY WAY by the "authority"? 
>>And the social meaning?
>>]]
>
>
>There seem to be a confusion here that things have two meanings, a 
>"formal" one
>and a "social" one.    I don't think that is useful.

I think it is essential, although this way of putting it is 
potentially confusing. It might be better to distinguish between how 
much of the meaning is accessible to who and to what. The 'formal' 
meaning is that part which is accessible to software. But even the 
'social' part, ie all the rest, varies from reader to reader. In some 
cases, a reader might find more meaning than the original writer 
thought was in the document.

>  Something has one meaning.

This isn't true even in ordinary human discourse in natural language. 
There just is no such notion of a single 'one meaning'; the idea 
isn't coherent.

>"inverseProperty" can be defined mathemaically, but remember that  the
>mathematical symbols used are probably defined in english somewhere.

That is highly debateable and depends what you mean by 'defined', but 
in any case its irrelevant to the issue here. If your point is that 
*all* meanings are ultimately described in English, that isn't true.

>"color" can't be defined formally in terms of mathemaics, unless you have
>assume a lot of other terms to do with spectral reflectivity and light.

Well, "color" actually can be defined in scientific terms, in fact, 
but you'd be better with an example like "red" which probably can't 
be defined at all. This has got nothing whatever to do with 
mathematics, but it does tend to show that there isn't any single 
meaning to words like color names.

>>
>>Two points:
>>- "whatevers available" is simply not clear enough.
>
>There are a lot of social systems for relating definitoins to terms.
>These include domain name owndership, the Web, etc.
>The web is a big place.  Predciates and terms vary enormously.
>For RDF to be able to describe real things, it is essential that
>some terms be defined in english.

Why English? And why is this true? You can't define "red" in English. 
And more to the point, maybe, what does 'defined' mean here? RDF 
can't use definitions given in English.

>  Look at the cyc ontology.

That is a very bad example for your point: the intended purpose of 
Cyc is precisely NOT to rely on English definitions.  The meaning of 
any CYC term is completely defined by the CYC axioms using that term 
(and all linked axioms, ie ultimately by the whole of Cyc.)  You can 
strip out all the English comments and the meaning is unchanged. The 
same goes for almost all large-scale ontology work, in fact.

>I'm not sure what you are unhappy with, here.
>Are you saying it is not clear enough?

It certainly is not clear enough.

>Are you saying that
>it is not clear what the definitions of the terms are?

It is clear that any English definitions cannot be reflected in any 
normative account of meaning which is reflected in any operation of 
any RDF software. IF RDF tries to incorporate any such notion of 
meaning into its spec, then it has just become a joke.

>Are you saying that the english definitions should not be allowed?

Allowed in what sense? What I am saying is that allowed or not, they 
are not the slightest actual USE. Any sense of 'meaning' which 
depends on them isn't going to influence in any way what any piece of 
software does to the RDF. And since the point of the spec is largely 
to help writers of software, referring to something that is 
necessarily irrelevant is either pointless or actively harmful.

>Or do you want a clean algorithm for determining which
>english documents define a given term, from the web?  (That we could probably
>arrange.)

That would be very interesting. I doubt if this can even be made 
precise enough to be meaningful, let alone provided as an algorithm. 
And in any case, suppose you could. Now, how is my RDF engine going 
to read and understand those English documents?

>>
>>- RDF has decided to avoid the notion of definition for the formal 
>>semantics, we shouldn't then have it in the informal semantics.
>
>Well, every specification upon  which the web has depended up till 
>now, including
>Ethernet and unicode and TCP/IP and HTTP has had the meaning of its terms
>and structures explained in english, informally.  These specs have been used
>to build software, resolve many discussions,  and so on.

Yes, but this reply misses an essential point. The part of those 
specs whose meaning is fixed between software apps is the part that 
can be specified in the specs. None of those specs have set out to 
define a general meaning-carrying representation. In the case of 
ontology languages like RDF, the common part that can be defined by 
the spec is the *general rules* for meanings, ie the semantics, NOT 
the 'meaning' of particular RDF URIrefs. The spec says nothing at all 
about what <ex:myUri> 'means', and if you write a document in English 
explaining what its supposed to mean, then its not the slightest use 
or relevance, since no piece of software on the planet in the 
forseeable future is going to be able to read your English 
'definition'.

>  There are a mass of
>RDF schemas and related documents going to be written -- but it needs the RDF
>spec to pass on the authority to them to define their fields.

I don't see how the spec of a language can, or should, pass on any 
authority to define anything. It didnt have the authority to define 
the meanings of any items not in its namespace in the first place. 
What it can do, and does, it specify how to characterize the content 
of any piece of the language, so that definers of meanings can 
determine how to constrain those meanings using the language. That is 
what the model theory sets out to do.

>Just because *some* aspects of the meaning of *some* RDF terms can
>be expressed formally

THOSE ARE THE ONLY ASPECTS OF MEANING DEFINED BY THE SPEC. If you 
want the spec to define other aspects of meaning, please tell us how 
to write it (the spec) so as to refer to those other aspects of 
meaning. Its not good just using words like "meaning" and 
"definition" without saying what we mean by them. Words like this 
don't have exact enough meanings to use in a specification.

>   does not remove the duty of the RDF spec to
>say what an RDF document means.

The SPEC cannot possibly say what a particular RDF document means, 
any more than a dictionary can tell a story. It can only give general 
rules for attaching meanings to documents, which is what the 
semantics does.

>The formal semantics cannot define "color".

Right, and "color" can't be defined in RDF.

>Suppose I send you an RDF document syaing (in n3)
>
><http://example.info/ips/gg5#y004> <http://example.com/dsaf#enFap> "176".
>
>How would you know what I was telling you?

I would know that some thing had some property with value '176' (a 
string), and if that's all the RDF I can see, that is ALL I know. If 
you want me to know more, you had better send me some more RDF.

>How would someone who had not heard of RDF before?
>The mime type would take them to the RDF spec and -- then what?

The above is what I would learn from the RDF spec. Of course the RDF 
spec can't tell me what you mean by 
<http://example.info/ips/gg5#y004>; and you might tell ME what you 
mean in English, but (this being the semantic web) that's largely 
irrelevant; the question at issue is what some piece of software 
acting on my behalf can get out of it. If its written in English, the 
answer is, nothing.

>>For me, either of these is fatal. This cat has had its nine lives.
>
>Fatal for the idea of defining what an RDF document means?
>How sad.
>In that case, I suppose we had better start all over again, as
>we have ended up with a languge of meaningless documents.

You can start over all you want, but you will not get anything much 
better than this (except in the sense that OWL is better than RDF, 
and full FOL would be better than OWL). To get better than this you 
will need to create a web of movie-style Artifical Intelligences, and 
you won't get that done by a W3C working group. All languages - even 
human languages like English - are 'meaningless' in some very strict 
sense. Their meaning is what a cognitive agent can get out of them, 
and RDF agents - in fact, any software agents that we know how to 
build -  have pretty limited cognitive powers.

>If  RDF is only be to be used to encode mathmeatical
>formalisms,  and not information about the real world,
>do we need another langauge to express data?

This discussion has nothing to do with mathematics versus the real 
world. Model theory is about worlds, including the real world. The 
point at issue is HOW MUCH INFORMATION is encoded in some RDF; and 
the answer is, rather little. But we knew that up front, before we 
started. It is obvious that RDF cannot encode the kind of information 
that humans can send to one another using languages like English, in 
a form useable by software agents. But that's not a failure of RDF: 
*nothing* can do this. To do this would require us to be able to 
provide software with human-level cognitive powers.

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 Sunday, 2 March 2003 00:32:04 UTC