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

> -----Original Message-----
> From: ext Pat Hayes [mailto:phayes@ai.uwf.edu]
> Sent: 14 November, 2001 21:49
> To: Stickler Patrick (NRC/Tampere)
> Cc: w3c-rdfcore-wg@w3.org
> Subject: 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'.

I think we're speaking different languages again... (maybe)

A data type, as I define it (and as I understand XML Schema to
understand it) can have either only a value space or both a value
space and a lexical space.

I'll define the term "concrete data type" to denote a data type
that has both lexical and value spaces, and "abstract data type"
to denote a data type with only a value space.

All lexical forms in the lexical space of a data type denote
values in the value space of the same data type, but are not
themselves members of the value space.

The subClassOf relation only applies to value spaces of data
types, meaning that a member of the value space of a subclass
data type is also a member of the value space of the superclass
data type.  But it does not define a relation between lexical
spaces, meaning that a member of the lexical space of a subclass
data type need NOT be a member of the lexical space of the superclass
data type.

If you include lexical spaces in the subClassOf relation, 
then one cannot relate data types which denote properly
intersecting value spaces yet have (for practical reasons)
incompatible or non-properly intersecting lexical spaces.


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

But such a string comparison would only be useful IMO if
the lexical space in question was a canonical lexical space.

Otherwise the test "000006" =? "6" would fail, yet these
are both lexical forms that map to the same integer value.

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

I agree.
 
> >>  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.)

Right. (Hey! We're beginning to sync... ;-)

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

Do you mean, does the literal represent a value or a string
that represents the value?

I'd say that it represents the value, within the context of
a data type.

> >It's
> >completely outside the scope of RDF.
> 
> The semantics of RDF is not, however, outside the scope of RDF.

Of course not. I think I misunderstood your question to
be asking what the lexical form denoted, not what the
literal denoted.

I.e., an RDF literal denotes a lexical form, which when paired
with a data type denote a value in the value space of the
data type.

Or are we now out of sync again?  ;-)

Patrick

Received on Wednesday, 14 November 2001 15:51:05 UTC