- From: Pat Hayes <phayes@ai.uwf.edu>
- Date: Mon, 17 Sep 2001 11:27:31 -0500
- To: Brian McBride <bwm@hplb.hpl.hp.com>
- Cc: w3c-rdfcore-wg@w3.org
>I suppose I think of this a bit differently. > >The way I see it we are discussing two things here: > > 1. when two literals are equal from the point of view of the model > theory > > 2. the matching algorithm an application might use when it does > a query or other operation on an RDF model > >The inclusion of f* mixes these up. > >As I see it, the specs we are writing define equality for the model >theory. We are not defining application behaviour. > >In which case all f* are actually f. That is of course, >unless we want to and can persuade Pat to move to a logic >which distinguishes between 'should be' and 'must be'. >(only joking, Pat :) Well, oddly enough, I did once do some work on three-valued logics, and was thinking about that when commenting on the f*s. But I now think that what that "truth-table" is about is syntactic identity, not equality (ie same referent). So the f*'s are OK as far as the MT is concerned: they basically give some wiggle-room for what counts as the 'same' literal expression. The MT accepts whatever answer is used, and applies itself to the result. In an ideal world, one would hope that if two expressions were in the f* category then a processor that decided they were different expression (members of XL) might at least have the good grace to say that they *meant* the same thing (mapped to the same member of LV). If that isn't the case then the MT might give different truthvalues for the same expression depending how its literals are parsed; but I guess that seems OK to me, under the circumstances. Either way, the MT doesn't break. If we were to decide that the lang attribute is a genuine rdf property of something (of what, by the way?) rather than part of the syntax, then I might have to reconsider. Pat > >An application may choose any matching that is appropriate for that >application; I'm told that Geordie's can have a good guess at >what some Norwegian means, but I don't think we should build that >sort of thing into our specs. > >Brian > > >Jeremy Carroll wrote: > >>>Jeremy Carroll wrote: >>> >>>>There was agreement with the treatment of equality proposed. >>>> >> >>Brian McBride wrote: >> >>>Jeremy, please can you explain why we need f*. Why not just f? >>> >> >>Out of context that could be misinterpreted :-). >> >> >>The argument, which is not bullet-proof, goes like this. >> >>For general purpose applications our analysis suggests f, this is hence >>our recommendation. >> >>However, we do not wish to tie the hands of application developers who >>have specific linguistic needs. Thus the f* can be read as true by an >>application developer who may have a strong default to some given >>language. >> >>e.g. a small company developing tools specifically for the US Hispanic >>market may have a default language tag value of "es-US" (I think that's >>the right one). Then any RDF input which doesn't say it isn't is then >>interpreted as "es-US". >>e.g. in the same scenario, the software tool might need to have a small >>footprint database and when an RDF file is loaded irrelevant triples are >>immediately discarded. These are distinguished by not having language >>tag "es-US". This does seem to give real advantage for f* in this >>scenario. >> >>I don't find this argument convincing; but conversely I am not >>sufficiently persuaded that it is the wrong way to go to want to >>prohibit it. In many ways my argument that we are talking about the syntactic >>equivalence of terms rather than a language processing model rather goes >>against this; & the use of xml:lang="es-US" on the rdf:RDF tag addresses >>the default language issue. >> >> >>A further point, is that in M&S xml:lang processing is optional. f* is >>hence justified by backward compatibility. The * in f* is the difference >>between SHOULD and MUST. >> >>Bill, do you have anything to add here? >> >>Jeremy -- --------------------------------------------------------------------- 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 Monday, 17 September 2001 12:27:27 UTC