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

The answer to the question "What is a 'value' to RDF?" is
given at the end, after some general replies to Pat's comments...



> >But you have to have a conversation about both.
> 
> Thank you for your instruction in how to hold a conversation. I will 
> try to bear it in mind in future.

Come on now Pat, I was not being condescending here. You were
saying that the conversation should focus only on topic A and I
was saying that it should include both topics A and B, if
the goal for having the conversation itself is to be reached.
 
> >
> >I take your statement to mean that the question of what literals
> >ARE correlates to lexical space and what the literals MEAN correlates
> >to value space
> 
> OK so far, though I'm not sure what "correlate" means as a 
> verb; but....

See the ontology that I sent you both last Friday as well
as to the group yesterday.

http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2001Nov/0358.html

> >Most RDF classes denoting data types
> 
> Well hold on. It isn't clear that there are any RDF classes denoting 
> datatypes, at present. In the S proposal, for example, datatype names 
> are RDF property names, not class names. So I do not know from what 
> population you are getting 'most' here.

Right. I stand corrected. I should have stated "Most RDF resources 
denoting..."
 
> >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.
 
> >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?

> or was identical 
> to something else. 

Again, how could it do that without *parsing* it?

> The potential uses of information are many and 
> various, and are not restricted to checking conformity to a data 
> model for some typed application.

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

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. 

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

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. 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. It's
completely outside the scope of RDF.

Eh?! Right?! 

******************************************************
*** This is gonzo important! Please folks let me know
*** if you don't get it.
******************************************************

> The various proposals 
> answer that question differently.

My proposal is that we shouldn't try to answer that question 
at all!

In RDF, a value in a value space is denoted by a pair of
constructs: (1) a lexical form encoded as an RDF Literal,
and (2) a URI denoting a data type which defines a lexical
space and a value space.

Here are 4 representations for this pairing:

1. A URV is a one representation of this pairing, where
   the URI of the data type is indirectly associated via
   the URV scheme.

2. A qualified anonymous node with an rdf:value property
   having the lexical form as its value and an rdf:type
   property having a data type URI as its value is another 
   representation of this pairing.

3. A X graph statement in which the subject is an LNode 
   with the lexical form as its label and the
   predicate is a UNode with the label rdf:type and the
   object is a UNode with the data type URI as its
   label is another representation of this pairing.

4. An unqualified literal as the object of a statement
   where the predicate has defined for it an rdfs:range
   constraint is a *suggestive* pairing where the data
   type URI is inferred from the range value.

In all cases, it is the pairing itself that denotes the
value, and the mapping from lexical form to value is
APPLICATION SPECIFIC, and outside the scope of RDF proper,
and constrained by the definition of the lexical and value 
spaces of the data type.

All rdfs:subClassOf relations defined between data types
apply only to intersections of value spaces, not of lexical
spaces and this means that one may define a "abstract data
type scheme" which only defines a value spaces and which serves
as an upper-level taxonomy for the interrelation of "concrete
data types" for which are defined both value space and
lexical space.

At least that's my take on the matter ;-)

Cheers,

Patrick

Received on Wednesday, 14 November 2001 07:39:09 UTC