W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > January 2002

Re: literal value terminology (was: Re: Review of MT)

From: Pat Hayes <phayes@ai.uwf.edu>
Date: Fri, 18 Jan 2002 19:05:07 -0600
Message-Id: <p05101023b86e73f5c51e@[65.212.118.208]>
To: Sergey Melnik <melnik@db.stanford.edu>
Cc: w3c-rdfcore-wg@w3.org
>Pat Hayes wrote:
>>
>>  >
>>  >>>    Or by "literal value" do you mean the member of the value space
>>  >>>    of some datatype?
>>  >>
>>  >>  Yes, that is what I meant.
>>  >
>>  >Good. I had hoped that was the case. What threw me
>>  >was the adjective 'literal' in front of value. It
>>  >seems to suggest that the values are the strings
>>  >(literals) rather than the members of the value
>>  >space of the datatype.
>>  >
>>  >Perhaps you could just say 'value'? and leave the
>>  >'literal' off?
>>  >
>>  >>>    If the latter, then don't we need some treatment of lexical 
>>datatypes,
>>  >>>    value spaces, lexical spaces, and (presumably also) canonically
>>  >>>    lexical spaces in the core MT?
>>  >>
>>  >>  Well, we need it eventually.  But in the meantime, the MT can just
>>  >>  say that literals denote literal values (whatever those turn out to
>>  >>  be).
>>  >
>>  >Fair enough. Though I think it would be clearer, in
>>  >light of the vocabulary of the "foundation" datatyping
>>  >document (sections 1-3 of Sergey's document) to just
>>  >say 'value' rather than 'literal value'.
>>
>>  Hmm. The trouble is that plain "value" could mean anything at all.  I
>>  want to allow the MT to conceptually distinguish values of literals
>>  from semantic values in general, ie resources. (They might turn out
>>  to be the same; but they might not also and I'd like to stay
>>  agnostic.)
>>
>>  How about calling them "datatype values" ? That avoids the use of
>>  "literal" as an adjective and also makes an obvious connection with
>>  datatyping. It also follows the DAML usage, which distinguishes
>>  'object' classes from 'datatype' classes, which are classes of
>>  datatype values.
>>
>>  Anyone got strong views on this? Speak now! Unless there are strong
>>  objections I will make this change.
>>
>>  Pat
>
>Speaking now :)
>
>I don't like the name "datatype values" particularly... I already made a
>suggestion long ago, but let me repeat it here again anyway. For
>orthogonality, I'd rename "literals" to "literal tokens/symbols/etc.",
>and make "literal values" just "literals". So you get
>
>I(resource URI) = resource
>I(literal token) = literal
>
>It just looks more consistent than
>
>I(resource URI) = resource
>I(literal) = literal value
>
>Of course, such change would involve a lot of find-&-replacing both in
>the draft and in our minds, but it does help to avoid confusions
>(Patrick's email is another example). If we leave it like it is now, I'm
>afraid we (well, you Pat) would have to clarify it over and over
>again...

Well, I don't myself use the terminology "resource URI" which seems 
redundant (are there any other kinds of URI??) , and I guess I was 
under the impression that the terminology of "literal" to refer to 
the syntactic entities was established in the wider community, so not 
ours to legislate.

Since this whole "literal" terminology is so confusing, I think it 
would be safest to avoid the use of simple unqualified terms 
altogether. Let me therefore modify my suggestion to the following, 
which is more longwinded (and less 'orthogonal') but has the merit of 
making everything very clear:

I(URI) = I(uriref) = resource  (ie same as present)
I(literal token) = datatype value

This keeps "literal"  completely outside any semantic domain, and 
also emphasizes even to the casual reader the token/value 
distinction; and it has the advantage, already noted, of being 
consistent with DAML terminology at the semantic level.

OK with that?

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 Friday, 18 January 2002 20:05:13 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:43:56 EDT