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

>  > >What I'm not clear on is what you feel is being lost by using
>>  >a URI to represent a typed data value rather than a literal.
>>  >I.e., how does using an approach such as '#a #b int:5 .' lose
>>  >anything in comparison to '#a #b "5" .' per se?  Does not the
>>  >URI form provide greater potential for defining or inferring
>>  >knowledge about the value?
>>
>>  ... My understanding of the
>>  proposal was that the syntactic encoding of, say, integers implicit
>>  in the notion of literal was to be abandoned and replaced by an
>>  assertional encoding in RDF triples.
>
>But there isn't any "syntactic encoding of integers" for any particular
>data type, right? That's where I'm getting confused.

I think I am more confused than you are, my friend. I have this 
sinking feeling that I have been singing in the wrong key altogether, 
and not fully understanding what y'all mean by 'literal'. I took this 
to mean something like 'a name from which one can compute its 
meaning', eg a numeral in a given base, a quoted string, etc. . But I 
now think that in this forum , the term has a much more exact and 
more limited meaning. Maybe I should just shut up and let the experts 
work out the syntactic details. Whatever y'all decide, I undertake to 
fit a model theory to it.

>I see that the
>use of a typed data value URI in place of an untyped literal string
>neither increases or decreases the knowledge at the RDF level

Not that encoded in the RDF triples, no. But the utility of literals 
has never been fully captured in the triples themselves: that's the 
point, If you know that some property value is the literal '5', you 
don't need any more RDF triples to tell you what '5' means. If you 
had to do that, you might as well have used a blank node instead of 
the literal in the first place.

>  -- since
>RDF at that level treats both URIs and literals as opaque. And if one
>goes to interpret those labels, only the URI has inherent data type
>knowledge. I don't see how there is any "implicit" knowledge about
>integers in a given literal string "5". Sure, you can associate a
>type via a typed anonymous node, but that is completely external
>knowledge insofar as the literal is concerned. Or am I completely
>missing something? (again ;-)

I think (?) that you are assuming that everything that is known about 
the things mentioned in an RDF graph has to be encoded in triples in 
the graph. I always thought that the very point if literals was that 
they provide a way to put information in a graph that is not 
explicitly encoded in triples (eg that '5' means 5.) But I confess 
that I havn't checked that understanding with the rest of the RDF 
core group, so don't take it as definitive.

>
>>  That may be a good idea, but it
>>  does potentially throw away a lot of valuable properties implicit in
>>  the syntactic typing of literals.
>
>I guess I don't really follow what you mean by syntactic typing of
>literals

I meant being able to tell just by looking at the literal itself 
whether one had a numeral (in some base) or a string (in some 
language) or whatever, as opposed to the URI case, where all one has 
is the knowledge that it refers to something; if you want to find out 
any more, you have to go looking for assertions about it.

>and what that buys us, in general. I may just be looking
>to closely...
>
>>  >Granted, in order to have "extra" knowledge about the actual
>>  >data type used, we need to either interpret the URI scheme (which
>>  >is outside the scope of the MT) or employ mechanisms such as
>>  >the (now unfortunately deprecated) rdf:aboutEachPrefix, e.g.
>>
>>  If aboutEachPrefix was only used in this way it wouldnt be so bad,
>>  but it got all mixed up with containers.
>
>Could not one decouple its troublesome use with containers yet
>retain it for useful stuff like making statements about all instances
>of a given URI scheme?

Yes, though just as a political/pedagogic point it would probably be 
better to trash it and invent a new name for that use.

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 Friday, 5 October 2001 17:36:18 UTC