- From: Pat Hayes <phayes@ai.uwf.edu>
- Date: Fri, 5 Oct 2001 11:51:25 -0500
- To: Jan Grant <Jan.Grant@bristol.ac.uk>
- Cc: w3c-rdfcore-wg@w3.org
>I've been thinking along very similar lines. See >http://ioctl.org/rdf/literals >which has a mix of related ideas, some good, some bad, some wrong. Let me pick up on one of them and chew on it: the idea that a literal is a self-denoting entity. This is a very appealing idea, and it works for strings, but I don't think it can be made to work (without modification) for any other kinds of literal. In particular, one of your examples is 'the number 12'. But numbers are denoted by numerals, not numbers; numerals, not numbers, are the syntactic labels that we use to label graph nodes. So I take it that the intention in treating '12' as a "literal number" is in fact that the *numeral* '12' is the literal, and that its interpretation is fixed to be the number 12 (that is, the number whose prime factors are 2,2 and 3; the square root of 144; denoted variously by the numerals '12' in decimal, '1100' in binary, and '14' in octal). But in none of these cases is the numerical literal *identical* to its interpretation. I think that the only kind of literal for which this can be asserted is a string, in fact; that is, assuming that we think of the syntactic labels as themselves being character strings. (Well, if we used unary arithmetic then the numeral for n is a character string of n 1's, so maybe in that case....) Even the language tagged examples don't seem convincing, eg the meaning of the literal langstring("oui", "fr") ought to be the French word 'oui', not that literal itself. (Just see how far you get in Paris saying "langstring .... quote fr unquote" at people.) However, what I think IS characteristic of all kinds of literal is, that they bear a very close kind of relationship to their denotations, in that one can *compute* the denotation from the literal. It wears its meaning on its sleeve, as it were. You don't need to go off looking for assertions *about* its meaning; you can tell just by looking at the literal itself what its denotation is (maybe using some literal-defining conventions , e.g. knowing that it is a decimal numeral written from left to right, but those are fixed outside the assertional language and are considered part of the lexical definition of the vocabulary.) Obviously, being its own denotation is a particularly simple case of that, but its not the only possible case. So Id suggest altering this to: a literal is a name whose denotation can be computed from the name alone Ie without using any linguistic context. Not so pithy a slogan, sorry, but I think it captures more centrally the *utility* of literals. If you've got a class called 'odd-integer' then to specify its contents you either can write set out to write infinitely many rdf triples (assuming we could put literals in the subject), or you can say: "look at it, divide by 2, if the remainder is 1 then its in the class." The latter is infinitely more compact. ----- Another comment: "...isnt a URi a resource? No.....a URI is just used to label a resource. " Well, yes and no. I think its perfectly OK to say that *anything* is a resource and therefore URI's must be resources. But I agree with your thought to the extent that when one of these (rather special) resources called URIs is being used as a URI, there are two resources involved: the URI itself and the resource it is being used as a label of, and we have to be careful not to get these confused. I think people often use 'resource' when referring to a URI to mean the URI itself rather than the resource it labels, or use the term 'resources' to mean URIs in general. ----- Can a literal label an arc? Well, that is up to the Arc Police, ie us; but, *could* a literal label an arc? Yes, as far as the model theory is concerned, though that would have some fall-out in the treatment of literals in RDFS. Right now the MT tries hard to keep literals at a safe distance, as it were, since their status is cloudy, and to maintain that hands-off style while also allowing literals as subjects or arc labels would be tricky. But if we were to take some kind of Big Decision to allow literals to be more closely integrated with the things URIs denote, then the MT would actually get easier. Easiest of all from the MTs point of view would be to just toss URIs and literals all together and give them a uniform semantics That might have repercussions for other languages such as DAML+OIL which need to assume a tighter syntactic distinction. However, I think that more liberalism on our part can do no real harm. The only result of RDF(S) being more liberal would be that extensions like DAML+OIL would have to take on the responsibility for making distinctions that RDF ignores, which seems to me to be a reasonable request; after all, we don't expect an RDF parser to check DAML+OIL syntax, right, only to let it through the gate as legal RDF. There already are plenty of RDF graphs that are not legal DAML+OIL, and if we allowed literals in subject position and on arc labels then there would be more of them. Tough. ------ More later, gotta go to a meeting. Pat PS. That link you have hreffed from 'difference between objects and indiscernables' I think is a bit misleading. The distinction is OK, but: "A structure of particular importance to programming is the list. Lists are not objects for the same reason that the mathematical entities are not. Many languages, including all the logic-programming languages, and all the pure functional languages, do indeed treat them as indiscernables. This can be seen by the way these languages handle equality. A list's identity is determined only by its value, so two lists should be equal if and only if they have the same value: and this is the way equality works in all the logic-programming and pure functional languages we know." Hey, take a look at the granddaddy of them all, LISP, which has BOTH senses. LISP lists *are* objects in his sense: they have a state, can be changed while retaining their identity, and can be copied. LISP wouldn't work otherwise. LISP uses 'equal' for the indiscernable sense (identity of abstract structure) and 'eq' for the object sense (same actual datastructure). The equal/eq distinction is central to understanding LISP and using it properly. Maybe the author would say that LISP with 'eq' is not a "pure" functional language; OK, my reply: point to any programming language in actual use that is purely functional. All real programming languages are concerned with state, because computation itself is all about transformations of states. I think that (like a lot of programming language theoreticians), this guy wants programming languages to be more like logic and mathematics for the wrong reasons: he wants them to be Platonically beautiful. This is like wanting to make shovels out of spun glass so they will shine better. (BTW, he talks about the Leibnitz principle, often called the identity of indiscernables. Just for the record, the MT has an implicit denial of this principle (for properties) built into it as a basic assumption, in the use of extension mappings. Two properties may agree on every single thing in the universe - have the same extension - yet not be identical.) -- --------------------------------------------------------------------- IHMC (850)434 8903 home 40 South Alcaniz St. (850)202 4416 office Pensacola, FL 32501 (850)202 4440 fax phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes
Received on Friday, 5 October 2001 12:51:29 UTC