Re: Answer to the question: What is a "value" to RDF

>....
>>  >This means that, whether a given RDF class denotes both
>>  >a value space and a lexical space, or only a value space, any
>>  >inferences about the valid membership of a given typed value in
>>  >a superordinate class has only to do with value space.
>>
>>  No. If a class *denotes* a lexical space, then membership in that
>>  lexical space will be relevant, obviously.
>
>Relevant when parsing the lexical form and mapping it to a value,
>yes, but not necessarily relevant to operations taking
>subClassOf relations into account.

No, really. If a class name denotes a class consisting of lexical 
forms, i.e. if lexical forms are in the class extension, then lexical 
forms are what determine class membership and subClassOf relations. 
It would be the same if you substituted 'chickens' for 'lexical 
forms'.

>  > >This then means that lexical space is only relevant when actually
>>  >parsing the RDF encoded literal in order to actually map it to
>>  >an internal value in a given system/application.
>>
>>  No, that conclusion is unwarranted. The lexical space might be
>>  relevant in many circumstances, eg it might enable a reasoner to
>>  conclude that the literal value was in some class,
>
>How could it do that without *parsing* it?

Eg by simply doing string matching on the Unicode character 
sequences, as Dan C. suggested in a recent posting. (Maybe I don't 
know what you mean by 'parsing' here? I wouldn't expect an RDFS 
literal to get parsed at all in any significant sense of mapping it 
to something other than what it is already.)

>....
>True, but apart from *parsing* the lexical form in order
>to map it to a value, membership of a literal in a given
>lexical class has, as far as I can see, no other
>significance.
>

I think our responsibility is to not make any guesses about what 
significance pieces of data might have for users, however.

>Thus, I assert again:
>
>>  >All other
>>  >logical operations based on type, subClassOf, subPropertyOf
>>  >and range need not worry about lexical space AS LONG AS when
>>  >the time comes to interpret (i.e parse/map) the literal by
>>  >an application, it knows the lexical space for which it is
>>  >defined.
>
>Eh?
>
>>  >
>>  >>  >
>>  >>  >>  >So just how does a system *know* how to interpret
>>  >>  >>  >'0x12' as an xsd:integer?
>>  >>  >>
>>  >>  >>  It doesn't, probably. Look, I'm not expecting miracles to
>>  >>  occur. All
>>  >>  >>  that the MT extension can do is to make sure that datatyping
>>  >>  >>  information is tallied up with literal labels in a
>>  sensible way.
>>  >>  >
>>  >>  >Right. I agree. The key is to bind the data type class with
>>  >>  the literal
>>  >>  >in a persistent fashion (this includes both local and
>>  global typing)
>>  >>  >and make sure that the application which interprets the
>>  literal gets
>>  >>  >all the information it needs.
>>
>>  Wait: up to 'and make sure' then I agree, but that particular kind of
>>  application is only one possible use for information encoded in RDF,
>>  not the only possible use. Some applications may not 'interpret' the
>>  literal at all, but still may depend for their operation on the
>>  particular literal string. Cwm is an example.
>
>It is true that some operation may use a literal as an opaque string,
>but in such a case then, its lexical form is irrelevant.

Why? It can still be used to determine identity, for example.

>After all, URIs are just opaque strings for most RDF operations,
>even if a given application might choose to parse and interpret
>its lexical form in some case.
>
>If at any point, the literal is treated as anything but opaque,
>then IMO the lexical space is entered.

OK, maybe we are saying the same thing in two different ways. My 
point is only that the lexical form plus the datatype fully 
determines the value (by which I mean the denotation) and that this 
value may be significant in some reasoning involving class membership.

>  >
>>  >  >
>>  >>  Right. But once that binding is done successfully, should
>>  we say that
>  > >>  the literal refers to itself, or to the value assigned to
>>  it by the
>>  >>  datatyping scheme to which it is bound?
>>  >
>>  >Not at all. The binding, if it is based on the interpretation of
>>  >subPropertyOf and subClassOf relations, is between a property and
>>  >a literal (syntax) not between a concept and a value (semantics).
>>
>>  Part of the very idea of a literal (as opposed to a uriref) is that
>>  its semantic value depends only on its form and the datatyping scheme
>>  in use, and not on other aspects of the RDF interpretation.
>
>What I said above does not contradict that.
>
>>  So if the
>>  literal itself is 'bound' to a datatyping scheme, then the semantic
>>  value of the literal is established.
>
>Yes, but it is not the literal that is denoting the value, but the
>pair of literal plus data type that denote the value. If that binding
>is ever broken or lost, then the literal does not retain any inherent
>denotation of the value.

I wouldn't express it quite that way, but I agree. (A literal always 
denotes a single value *in a given interpretation*. The 'inherent' 
part means that it denotes the same value in every satisfying 
interpretation, which it may well not do if insufficient information 
is present, as you note.)

>
>And in the case of non-locally typed literals where type is inferred
>by range definitions on properties, that binding can be lost.
>
>>  Now, the question arises, is
>>  that semantic value a string or (say) a number?
>
>But the question is irrelevant within the scope of RDF! The
>representation of the semantic value is undefined.

I am not asking about a representation, but about the value itself, 
the denotation of the representation: what kind of thing does the 
literal mean/refer to/denote.

The question is not irrelevant; it is central to the model theory. 
This entire debate has to eventually get cashed out in a model theory 
for this language.

>All that
>is defined is a lexical form and a context (a data type)
>by which the value has denotation. It's representation by
>any given system may differ.
>
>One application may map the literal "000010" to a sequence
>of binary digits. Another may map it to a canonical lexical
>form "10" and deal with it as a string. It's not for RDF to
>say what representation of a value a literal maps to.

I agree, but I wasn't talking about that.

>It's
>completely outside the scope of RDF.

The semantics of RDF is not, however, outside the scope of RDF.

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 Wednesday, 14 November 2001 14:49:08 UTC