Comments on ioctl (was: Re: big issue (2001-09-28#13))

>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