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

Bill:
> ***the purpose of 'should not' is to allow applications some flexibility
> on dealing with language tags. That is, when a literal is equal to
> another but only one has a lag tag, they can be considered equivalent,
> which might be sufficient for some applications to make a match.


Pat:
> I find this odd. Why not let them be equal in this case? Omitting the 
> language tag presumably means that no language information is being 
> supplied. But in that case, there is no need to reject a match with 
> an identical literal which does have a language tag, is there?


I agreed with Bill earlier, and continue to do so.

The purpose of defining equality is that in the model theory we are
talking about a graph, which is a set of edges. We need to be able to
tell whether one edge is the same or different from another edge.

We are not trying to define a processing model for language aware RDF
processors.


I think the graph constructed by

_:a <rdf:value> ("Roma", "it").
_:a <rdf:value> ("Rome", "en").
_:a <rdf:value> ("Rome", "fr").
_:a <rdf:value> ("Roma", _ ).

is different from 

_:a <rdf:value> ("Roma", "it").
_:a <rdf:value> ("Rome", "en").
_:a <rdf:value> ("Rome", "fr").

If the literal ( "Roma", _ ), i.e. with no language specified, is the
same as ("Roma", "it"), i.e. in italian, then the two graphs are
identical.


Now, suppose we have a language aware graphical information system, and
a user whose preferred language is "fr-ca" (French Canadian) comes up. I
have quite deliberately not tried to specify which label goes onto the
big city half way up italy.

Such an app may be clever enough to decide that "fr" is a better match
to "fr-ca" than _ but maybe not.

A different application, may always read a pair ( "string", _ ) using
the currently set default language; while that certainly should not be
the default case, I wouldn't want to rule it out as a way of processing
RDF.

Jeremy

Received on Friday, 14 September 2001 05:56:13 UTC