- From: Pat Hayes <phayes@ai.uwf.edu>
- Date: Mon, 15 Oct 2001 23:34:26 -0500
- To: "Bill de hOra" <bdehora@interx.com>
- Cc: w3c-rdfcore-wg@w3.org
> >BTW: Regarding both this issue, the other issues you raise below, and >any others that come up, I don't necessarily feel strongly about these >things; >>> > >I do feel strongly about this. > >There's this notion floating around the RDF community regarding name and >entity when literals are property values in that properties must always >point to the name. I think Drew McDermott asked this question about >strings being implicated as entities publicly first on rdf-logic (I'll >stand corrected on that), but I believe his point was about the >semantics of properties, not literals. > >Please read a response I sent to Sean Palmer on this same matter: > >http://lists.w3.org/Archives/Public/www-rdf-interest/2001Sep/0050.html You say there: "Clearly in RDF processing, literals are opaque to RDF (i.e. if a literal looks like a URI or more RDF, it is treated as a literal, not as a URI or more RDF). However an application using RDF triples and able to properly manipulate Dublin Core in your example would be entitled to draw the inference that the literal names an entity." I want to take issue with this, because to me it seems to contradict itself. As you say, to an RDF processor, literals are opaque. But you then say that an 'application using RDF triples' would be entitled to draw an inference which requires (?) NOT treating literals as opaque if they refer to the Dublin core. Is this application supposed to be an RDF application or not? If it is, then it is not entitled to make that inference, since there is nothing in the RDF that enables it to draw it. If on the other hand it is able to draw that conclusion, then it evidently is not using information (only) from the RDF triples, so why should an account of the RDF meanings of the triples be concerned with this information? I think this is particularly tricky as an example since the part of the Dublin core that you quote is written in English, so presumably is not fully understandable by any software yet written by anyone. >[Indeed most of the examples I've seen of literal values have literals >naming an entity in a common-sense way. Yes that's folkware semantics >but there's nothing wrong with common-sense just because computers don't >have any. There is if you are touting the formalism as something for computers to use. In fact it is dishonest and foolish, and would be valid grounds for having ones tenure case dismissed at any reputable university department. >In any case it's up to the modeller (in this case, the primer) >to make the semantics explicit. Surely that's what RDF is for?] > >Anyway. There is _nothing_ in RDF to make us think that when a property >has a literal value the property means the literal itself is the entity >and not what the value might denote True, but what it can denote is severely restricted. The model theory at present assumes that literals have a *fixed value*. So whatever a literal denotes, it has to denote it once and for all, globally. It can't denote one thing in the Dublin core and something else somewhere else. Now, that is a very simple and restrictive assumption, and Peter Patel-Schneider wants us to relax it to the extent of allowing datatype schemas for literals. The kind of examples he uses are where "070801" might mean either a date or a string or an integer, and one can determine from things like the rdfs:range information which datatype scheme is supposed to be applied to each literal occurrence. That is the scheme we have now worked out in full detail so that it COULD be incorporated into the MT for RDFS, if we want to do so, though right now its just kind of waiting to be put there. But even with this extension, the range of things that a literal can refer to is somewhat restricted to be the kinds of things that one finds in datatyping schemes. I'm not sure if having a literal like "creator" denote a particular human being would count as a datatyping scheme, but it sure doesn't sound like one to me. > and I don't want the primer to >implicit mandate otherwise. If there's anything in the MT to that >effect, I'd appreciate being told, because I didn't know RDF had >constrained properties in such a way. See above. There is no constraint on properties, but on the XL mapping from literals to literal values. >In Frank's example, without clear semantics for 'creator' there isn't >enough information to make a decision on what's being implied. Right, and indeed that semantic content cannot be stated in RDF. I don't think we should pretend that it can if in fact it cannot. >I suggest making it crystal that the example is to show how intuitive >the triples form. Do this by pulling an example from natural language, >as Frank is, and moving from a NL sentence to an RDF triple. I think we should be very careful not to give the impression that we are saying that RDF can represent natural language meanings. It would be irresponsible, or just plain silly, to claim that existential-conjunctive logic can represent every meaning expressible in natural language. (If you think it can, then try publishing that claim in a refereed journal.) Pat -- --------------------------------------------------------------------- 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 Tuesday, 16 October 2001 00:34:36 UTC