- From: Pat Hayes <phayes@ai.uwf.edu>
- Date: Fri, 5 Oct 2001 16:35:58 -0500
- To: Patrick.Stickler@nokia.com
- Cc: www-rdf-logic@w3.org
> > >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