W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > March 2003

Re: Social meaning discussion 6th March

From: pat hayes <phayes@ai.uwf.edu>
Date: Tue, 4 Mar 2003 12:40:18 -0500
Message-Id: <p05111b02ba8a669c1c8a@[64.134.139.17]>
To: Tim Berners-Lee <timbl@w3.org>
Cc: w3c-rdfcore-wg@w3.org

>Pat, I think I agree with you more than you agree with me.

I think we actually agree on substance, but not over the choice of 
words. But since most of this storm is actually (IMO) arising from 
mutual misunderstandings, words are kind of important.

>Your message
>http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Feb/0164.html
>I thought was a good summary of the difference between the sorts
>of meaning and the imporatance that any "social" meaning is consistent
>with the formal meaning.
>
>But below you seem to take a rather extreme view.
>I suppose it shows the differences between our backgrounds.
>
>
>pat hayes wrote:
>
>>>I am concerned that you have thrown out the baby with the bathwater.
>>>And still left some bathwater. ;-)
>>>Our views do seem rather different
>>>
>>>What is required, and easy, is to say what an RDF document means.
>>
>>
>>Well, doesn't the MT do this already?
>>
>>>What is not required and a bad idea is to explain how to use it.
>>>
>>>1. The meaning of an RDF document is that of the statements.
>>>2. The meaning of the statement is defined by the definition
>>
>>
>>?What is a definition?
>
>A definition is a text which describes the meaning of a term..

Describes to who or to what? You have to say who (or what) is 
expected to be able to read the text and extract the meaning. All 
this debate turns on the issue of having 'texts' readable by 
software, and what the limits of this are defined to be. Software 
can't read English text, but it can read and use RDF/S/OWL text.

>
>For example, http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/#property
>is (part of) an english definition of a rdf:Property.
>
>I know its a bit ofashock, but we are not being formal here.

I know we aren't being formal, but we do need to be more precise. One 
can be precise using English, believe it or not.

>This definitoin
>of property is a rough and ready english definition. But we get by with it
>and the rest of the stuff about predicates in the document.

Believe me, there are a lot of people in the various WGs who do NOT 
get by with this rough and ready a definition. Hence, I suspect, many 
of the communication problems we are having here.

>
>>
>>>of the predicate, as applying to the subject and object identified by
>>
>>
>>?How do the subject and object identify things?
>
>Um.. by using a URI, where sender and receiver share
>information

And if the sender and receiver are software, what does it mean to say 
that they share information?

>  which restricts

restricts how??

>the assication of the URI to one thing
>(or one thing withiin a given shared context).
>I am not sure what level of answer you are looking for here.

Well, even at the rough and ready level, it would be good to have 
some general guidelines which say how to use URIrefs to refer to 
things. Seems to me there aren't any right now (except for URNs). If 
a URIref is a URL then I can use it to locate a web page, or a 
document if you like. Now, how do I use that document to locate the 
referent? Are there any rules or guidelines about that, of any kind?

>
>Statements which restrct interpretations such that
>within the domain of discourse, for any intepretation,
>any things identified by the URI are equivalent?

Well, that assumes that this is somehow done within a model theory, 
which would be nice, but has its limitations. There are some general 
results limiting the extent to which MTs can possibly restrict or 
impose referents: eg the Herbrand results show that any consistent 
set of statements CAN be interpreted so that the names all refer to 
themselves, so one can make an interpretation entirely out of 
symbols. For reasons like this, one usually expects that a theory of 
reference - of naming - requires something additional and external to 
the MT in order to 'ground' names in the actual world.

>>
>>Neither of these are easy questions to answer and neither of them 
>>has an answer in the current spec.
>
>No, that's good, because the questoin of what is identified by a URI
>is dealt with in URI spec and associated specs.

Not in any Ive read.

>The only question that RDF has to answer (not as part of
>itself, but as part of a duty delegated from the URI spec) is to
>show how, when the URI
>is an identifier within an rdf document  (a la foo.rdf#bar), to show 
>how RDF allows
>the set of things which a URI might by identified to be restricted by
>RDF statements about that thing, or as we say in english, how RDF
>documents can describe things.

OK, that is fine with me. But that way of saying things treats URIs 
as logical constants (ie things that denote whatever the logical 
constraints force them to denote ) rather than names (ie things that 
*have* a denotation to which they just *do* refer, attached to them 
by some extra-logical means, like "Patrick John Hayes" refers to me 
because it says so on my birth certificate.)  The thing is, Im sure 
that most actual uses of URIrefs are more like names than like 
logical constants, in fact; but we don't have any rules for 
specifying how these names get their referents attached to them. 
(For example, does a URL *denote* the web page you get by using the 
http protocol on the URL? Some people assume it does, others make 
assumptions which are incompatible with that, eg Euler. There are no 
rules for this in the URI documents, which aren't worded with enough 
precision to even make the relevant distinctions.)
In normal human society there are all kinds of such rules for 
attaching referents to different kinds of names (baptism, 
registration of a birth, marriage, ship naming ceremonies, whatever) 
and associated knowledge about how to recognize a proper name and how 
to access its referent, if you really want to get at it.

>>>  the
>>>  definition of the subject and object terms.
>>>
>>>That then hands off to the relevant specs the right and the duty to
>>>define their bit.
>>>
>>>Tim
>>>sans chapeau.
>>>
>>>Brian McBride wrote:
>>>
>>>>Sans chapeau:
>>>>
>>>>My bath time this morning was spent thinking about social 
>>>>meaning. I came to the conclusion that 'meaning' is a difficult 
>>>>and slippery a concept that we should try to stay away from, 
>>>>sticking to things that are more concrete.  We should leave talk 
>>>>about 'meaning' to the philosophers.
>>>
>>>
>>>There we differ.  For me, the meaning of a bit-field or a docuemnt 
>>>or a packet
>>>or a message is what specs are for.
>>
>>
>>Where does any spec for packets, mime type, etc., ever refer to 
>>meaning? The very idea of  of 'bit' is rooted in a meaning-free 
>>notion of 'information', for example.
>
>@@@@
>Interrupted by face-face encounter.

:-) (-:

>
>
>>
>>>>Perhaps we can get all we need by describing intended use.
>>>
>>>
>>>That is where you start getting into questionable stuff, necessarily
>>>slanting the use of RDF some way.
>>>
>>>If  my:car :color :blue means that my car is colored blue, that
>>>is what it means, quite independent of context.
>>>The concept of  something having a given color is
>>>defined (and only defined) by the definition of color
>>
>>
>>Bad example, as color terms don't have definitions.
>
>They do. Casesium red is the sprectrum of an excited Caesium atom.
>Some are vauge -- red is a color which has predominatlylonger wavelengths.

OK, true. But there is a sense of 'red' which can only be accessed by 
people who have color vision. Philosophy rears its ugly head.... OK, 
leave aside philosophy (that's one problem with using words like 
'meaning') and we agree, it's fine to leave the definition of 'red' 
to, say, Pantone. The issue for us here is what it means to say that 
Pantone 'defines' the 'meaning' of pantone:red35 , what RDF(S/OWL) 
needs to know about that kind of definition, and whether the RDF spec 
needs to say anything about that.

>>>and my:car only serves to idetify the car
>>
>>
>>How does a uriref identify a car? (Genuine question, not rhetorical :)
>
>Notionally, the URIref identifies the car so long as everyone who uses
>it does soconsistently with it identifying the car.

But on the SW (for the first time?) 'everyone' has to be understood 
as including software agents, and so this begs the question, since we 
are left trying to figure out is how THEY can be said to 'identify' a 
car when given a URIref. I think the best we can do here is to say 
that they can't actually do the identifying, but at least they can be 
required to pass information around in a way that doesn't screw up 
anyone else's identifications. Then allowing the sofbots into the 
social fabric doesnt add anything really new in the way of reference, 
but at least it causes no actual harm.

>Specifically and practically, the semnatic web protocol is that
>a web page in RDF foo.rdf  has a description of something
>of type Car and typically giving a country code and plate number
>as property values.

Right, that kind of answer makes sense. Well, in one reading it does, 
ie if 'description' means RDF/S/OWL/... description. Then the 
formalism links the URIref to some other URIrefs which have socially 
recognized status as 'grounded' in real things like cars. That way of 
thinking is quite compatible with the formal MT for the web logics, 
and neatly separates the MT-handleable issues from the much scruffier 
notion of grounding.

I think many of our communication problems over this issue come from 
confusing that reading with the reading in which 'has a description 
of' means a description in some language (eg English) which a softbot 
cannot hope to do any reasoning with.

Pat


-- 
---------------------------------------------------------------------
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 Tuesday, 4 March 2003 12:40:40 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:56:11 EDT