- From: Tim Berners-Lee <timbl@w3.org>
- Date: Wed, 12 Mar 2003 16:24:10 -0500
- To: pat hayes <phayes@ai.uwf.edu>
- Cc: Public W3C <www-archive@w3.org>
On Tuesday, Mar 4, 2003, at 12:40 US/Eastern, pat hayes wrote: [...] >>> >>> ?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. > No, this debate does *NOT* turn on the software reading the specs. To situate RDF and OWL within the real world, you rely on particular vocabularies which are processed by software which has been written by a human being who has read the spec. Open Financial Exchange bank statements are generate inside a bank by a programmer who has read the OFX spec and understands what the fields mean. On the consumer's side, on your desktop, the document is read by software (such as Quicken) which was written by people who read or even wrote the OFX spec. (OFX is actually a SGML application but it could be an RDF application and the RDF mapping is straightforward) If you as a use RDF rules to make a USA income tax return from that data, then you generate info in in a vocabulary of IRS Form1040 line numbers. The meaning of these fields are defined in a human-readable document which is online. The rules which you might use to classify your spending and income maybe written in OWL and the data may be processed by an inference machine. Specification-wise, the inference engine is only authorized to make those inferences because the OWL predicates, when looked up, point to the OWL spec. The inference engine was not written by a computer program, it was written by a person who read the english OWL spec. >> >> 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. Well, the english definition of the property is what we have. It includes reference to some mathematical stuff in the spec,but i'd note that the model theory is invoked by the english, when you look at how this spec gets its authority, not the other way around. > >> >>> >>>> 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? For formal stuff, there is a mapping from ?x to ?x.log:semantics which is common (modulo real world effects such as power outages, lying and cheating, etc) to both users. For most software today, such as Quicken or Microsoft Money or Apple iCal, the spec has been read by a programmer who made the code. Actually, this applies to OWL inference engines. They can be considered, from the web point of view, just RDF systems which have been programmed to have an inherent knowledge of the meaning of certain terms. This allows them to do certain things on my behalf. >> 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? Well, my Stack article outlines them. They are in fact defined by a rather large pile of specs. RDF's job is only to be a relatively simple link in the chain. They haven't been written up formally, but in the special case of an RDF document, the RDF spec should tell you what an RDF document tells you about the referent. >> >> 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. Well, the MT, while central for you, is in fact a rather peripheral (though indeed useful) part of all this. The RDF spec should tell me to go look in the spec of the predicate to find out what p owl:inverse q means. I go and look up the owl:inverse, get eth OWL spec. It is a bunch of english and RDF which refer to each other, and the english bits refer to the MT. A programmer can then write code which will output a p b given b q a because he understood the spec with the help of the model theory. That's the state of the art. When we can pick up (in the RDF bit) axioms for the new terms, then the state of the art will advance a bit, and some of the functionality of the OWl terms will be directly loadable by a more general reasoner. > >>> >>> 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. Clearly not to your liking, and not really to mine, or we wouldn't have a bunch of TAG issues on the subject. But the URI specs are the documents which define that, in as much (a) you can understand what they mean and (b) your philosophy allows for specifications at all of anything. > >> 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.) Whether something is a constant or a name then depends on whether the identification is "extra-logical", which depends on the boundary you throw around some stuff you call your logic. For the OWL MT by itself they are just names, while for the whole semantic web they would be more like constants? > 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.) Voila. Hence the TAG issue. My own view is clear. http://www.w3.org/Designissues/HTTP-URI > 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. > Indeed. It is simpler on the web. It may be the first time one has been able to formalize the process. >>>> 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. The RDF spec only has to hand off authority to the pantone spec to define the actual relation identified by pantone:color. >>>> 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. > Yes, we're not looking to a bot (in general) for an inherent understanding of redness. (In fact we can build software which will tell you whether a picture of something is red. But we don't expect an OWL engine for example to be able to figure things out. You could actually write a level-breaking rule which told you whether a one-pixel GIF was red by allowing log:contents and some string matching expressions. But that is very much a corner case!) >> Specifically and practically, the semantic 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. We will work in a world in which robots work with a subset of the knowledge, but are better at handling that subset than we are. > 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 Wednesday, 12 March 2003 16:24:06 UTC