Re: RDFCore WG: Datatyping documents

On 2002-02-04 22:45, "ext Peter F. Patel-Schneider"
<pfps@research.bell-labs.com> wrote:

> From: Patrick Stickler <patrick.stickler@nokia.com>
> Subject: Re: RDFCore WG: Datatyping documents
> Date: Mon, 04 Feb 2002 22:03:06 +0200
> 
>> On 2002-02-04 20:43, "ext Peter F. Patel-Schneider"
>> <pfps@research.bell-labs.com> wrote:
>> 
>>> From: Patrick Stickler <patrick.stickler@nokia.com>
>>> Subject: Re: RDFCore WG: Datatyping documents
> [...]
>>> Date: Mon, 04 Feb 2002 20:18:24 +0200
>>> The problem mentioned above has everything to do with the
>>> denotation of Unicode nodes, and nothing to do with multiple or
>>> non-canonical lexical forms.
>> 
>> Fair enough. I take this to mean that whether or not the mapping
>> from a Unicode node to a value is N:1 or 1:1 is irrelevant so
>> long as it is not N:N or 1:N, right?
> 
> I guess not, but I'm not sure what you are getting at.   In a single
> datatype the mapping is N:1 or 1:1, but with multiple datatypes it would be
> N:N, which is the problem.

Hmmm... I think you may be thinking of a broader scope than
I was.

If you have multiple datatypes relevant to an interpretation,
e.g. if you have multiple range constraints, then each
combination of datatype and literal is a separate TDL
pairing and for a given TDL pairing there is one and only
one value.

Thus, within the context of a particular datatype, the mapping
from the lexical space of that datatype to the value space
of that same datatype is N:1.

It is true that a given literal (unicode node) may have
more than one interpretation (be considered to denote
more than one value) but that does not mean that there
is an N:N mapping for any specific datatype.

Right?
 
> 
> [...]
> 
>>> Well, yes, and that may be consistent with the diagrams in the TDL
>>> document, but the diagrams don't really say how any of that works, so we
>>> are left only with the model theory.  A simple example of how TDL works in
>>> practice, with an example like
>>> 
>>> age rdfs:range xsd:integer .
>>> John age "10".
>> 
>> In this example, which is using the global/implicit
>> idiom, you have a literal "10" which may be interpreted
>> as a member of the lexical space xsd:integer. Thus,
>> we have a TDL pairing ("10", xsd:integer). This pairing,
>> given the MT definitions of datatypes -- namely that
>> a datatype has a lexical space, a value space, and an
>> N:1 mapping from the lexical space to the value
>> space -- unambiguously denotes the mapping ("10", 10).
>> 
>> Now, if we take the local/explicit idiom
>> 
>>    John age _:1 .
>>    _:1 rdf:value "10" .
>>    _:1 rdf:type xsd:integer .
>> 
>> again we have the literal "10" and again the same TDL
>> pairing ("10", xsd:integer) which denotes the mapping
>> ("10", 10).
>> 
>> Insofar as the graph syntax is concerned, "10" is just
>> a literal (a Unicode node). It is the context of the
>> datatype, provided by the global or local idiom, that
>> defines the TDL pairings that are the basis for
>> interpretation.
> 
> Yes, but what *is* the interpretation?

The TDL pairing ("10", xsd:integer) denotes the
integer 10.

> I've been expecting something like:
> 
> In TDL a single URL is used to refer to a datatype.  Bound up in
> the datatype is a mapping from lexical forms to their values.

Correct. An N:1 mapping from lexical space to value space.

> The meaning of a Unicode node in TDL is a data value, as above, not a
> lexical form.  

Yes, but only within the context of a datatype, or rather only
when paired with a datatype URI.

The Unicode node itself denotes nothing. It is the TDL pairing
that denotes the value.

Without any datatype context, a Unicode node is just a Unicode
node.

Perhaps it is reasonable to say that the meaning of a Unicode
node in TDL is a data value within the context of a specific,
known datatype. Eh?

> The data value for a Unicode node is, however,
> determined by a mapping for some datatype.  The datatype mapping to
> use comes from ..........

From either the global/implicit or local/explicit idiom.

> One way to determine the datatype mapping used is by the ``global''
> idiom, usually using rdfs:range on a property, as follows

[actually, always using rdfs:range on a property]

But correct, the global and local idioms tell us the datatype context
within which to interpret the Unicode node -- it tells us which
datatype the Unicode node is a lexical form of.

> age rdfs:range xsd:integer .
> 
> which specifies that objects of age triples in an RDF graph are to
> be given meaning according to the mapping from Unicode strings to
> integers defined by xsd:integer (the XML Schema integer datatype).

Right.

> Thus
> 
> John age "10" .
> 
> taken together with the above statement, means that the age of John
> is the integer 10, and not the Unicode string "10", or the pair
> <"10",10>, or some other thing.

Right. Exactly.  But only when the TDL pairing is taken together.

But that's exactly the way TDL works (or rather should work ;-)

> The MT for TDL reflects this
> directly, not through any indirection.

You lost me there, but I'll take your word for it ;-)

> Now I'm not saying that the wording above can actually be turned into an
> actual datatype scheme for RDF.  I'm just saying that the TDL document
> desperately needs something like this to give some intuitions to the
> pictures and model theory.

Well, I kinda thought that's what it said ;-) but of course
being so close to it, I may be leaving alot implicit that is
clear in my own head. And of course, the benefit of the MT
is that it can get clear in others' heads besides my own.
And I will admit that there is some small amount of rub
between the general verbage and the MT verbage.

In general, though, I think you've described TDL exactly.

The remaining challenge, one that I humbly and honestly admit
I'm not up to, is to distill all that verbage about the
underlying concept of TDL into a decent (or at least
acceptable ;-) MT.

> [...]
> 
>>> If you do not,
>>> then I expect you to retract the TDL document as it now stands.
>> 
>> Although I sincerely value your opinion and input a great
>> deal, even if I did not agree with you (which I think I do),
>> I would not have retracted the TDL proposal, per se, but rather
>> continue to support the refinement/correction of its MT.
> 
> The trouble is that the TDL document is very specific in what it says.
> (And, by the way, that is one of the reasons to have a MT or other
> well-specified semantics.)

I don't fail to appreciate the benefit of a good MT.

> Right now the document says that the meaning of
> Unicode nodes are pairs consisting of Unicode strings and data values.
> Without quick, clear, and forceful statements to the contrary, TDL will be
> inextricably associated with this meaning,.

Fair enough.

Perhaps you would like to offer the underpinnings of an MT that
you feel more precisely captures the fundamental intent of the
TDL pairing model. It would be welcome, I'm sure.

Insofar as I am able to assist you, I will do so gladly.


>> All of the proposals are works
>> in progress, and all have issues to be addressed. We are not
>> allowing only "perfect" and "pristine" proposals to remain on the
>> table for discussion and consideration. RDF Core is after all, a
>> *working* group, no? ;-)
> 
> Yes, but that doesn't give anyone license to contradict themselves and thus
> confuse others, which is the situation that I think you are finding
> yourself in.  (Yes, not by intent, and maybe unknowingly, but I think that
> readers deserve to be told what is going on.)

Of course.

The "discussion" process regarding datatypes has been, well, ahem,
an experience I will long remember...  ;-)

>> Cheers,
>> 
>> Patrick
> 
> Peter F. Patel-Schneider
> 
> PS:  We all are guilty now and then of emitting statements and/or documents
> that give others false impressions of our stances.  However, I believe that
> we should all take extraordinary efforts to fix such false impressions.

Agreed.

Hopefully my comments have helped to do so.

I also expect that the TDL proposal will be corrected, clarified, and
refined as much and quickly as is possible. Input from you and others
is very beneficial and much appreciated.

Cheers,

Patrick

--
               
Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com

Received on Monday, 4 February 2002 16:21:11 UTC