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