RE: Literals (Re: model theory for RDF/S)

>  > >
>>  >Now, granted, a typed data value such as "5" is pretty semantically
>>  >"anemic", and there's probably not very many useful statements that
>>  >one could make about such 'resources',
>>
>>  I'd like to take issue with this often-repeated claim. There are all
>>  kinds of useful things you could say about such things, most notably
>>  asserting that they were in some named classes (such as 'odd-integer'
>>  or 'goal-scores-of-Tottenham-Hotspur' ).
>
>But that would really have to be defined as a more general rule than
>just statments about specific instances of integers, otherwise, we'd
>have to define an infinite number of statements to be sure they all
>were known to any system trying to ask, is this resource "odd", etc.

No, you wouldn't, that's the point. If we can define classes of 
literal values in terms of properties of the literals themselves, 
then we have, potentially, a new way to determine membership in a 
class. Right now, the only way to determine membership in anything in 
RDF is to check to see if there are assertions in the graph which 
entail an explicit assertion that the thing is a member of the class 
(or container, etc.). But to find out if some literal is in 
odd-integer, you don't even need to look at the RDF graph, you just 
need to do divide it by 2 and see if theres a remainder. You can get 
infinitely much assertional bang for your buck.

>I.e., rather than define explicit facts, we would define functions
>from which we could infer the facts implicitly only as needed.
>
>>  ... If RDF had the ability to
>>  assert properties of literals, the expressive power of the language
>>  would be quite radically increased.
>
>Well, I guess I'm not sure that that is the case with literals
>given a URI representation -- as then the literals are no longer
>literals but resources,

No, wait: they are resources, but they are still the values of 
literals, and that is (well, might be) enough to give us a different 
kind of handle on them.

>so how does that actually increase the
>expressive power of RDF, per se -- since the semantics of the
>data typing is in the URI and RDF doesn't understand the semantics
>of URI schemes...?

You keep assuming that literals have already been assimilated to 
URIs, and I'm trying to point out that doing that loses something 
important. Sure, once you've lost it, its not there.

>
>>  >(but for treating two URIs that denote the same "thing" as
>>  equivalent,
>>  >no, RDF is IMO not the right layer, though probably RDFS is)
>>
>>  For the record, I tend to be careless about the distinction between
>>  RDF and RDFS, which isn't particularly well-motivated or worth
>>  fussing about, IMHO.
>
>Eh?  Does that mean that the MT for RDF is really the combined
>MT for RDF and RDFS? (that might explain the confusion about the
>definition of "resource"...).
>
>And isn't it useful to keep very clear and distinct the "raw"
>graph versus (possibly many) "cooked" interpretive layers above
>that graph?

Yes, indeed, and the next draft of the MT document will make that 
layering more explicit. My point was only that the exact dividing 
line between the RDF layer and the RDFS layer seems somewhat 
arbitrary (and some authors of the original specs seem to agree, by 
the way.)  You could take just about any subset of the combined 
RDF/RDFS vocabulary and make it into a coherent 'layer'.

Pat Hayes
-- 
---------------------------------------------------------------------
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 Thursday, 4 October 2001 16:07:47 UTC