Re: 2001-09-07#5 - literal problem

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 :)

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
> 
>

Received on Monday, 17 September 2001 09:41:20 UTC