Re: simplified datatyping proposal

On 2002-02-22 1:16, "ext Pat Hayes" <phayes@ai.uwf.edu> wrote:

>> On 2002-02-20 19:41, "ext Pat Hayes" <phayes@ai.uwf.edu> wrote:
>> 
>> 
>>>  Can I ask y'all for some clarification. Do people want to support
>>>  BOTH in-line and bnode forms at the same time? That is, should the
>>>  following mean the same thing and be affected in the same way by a
>>>  drange assertion on ex:age ??:
>>>  (1)
>>>  person:Jenny ex:age "10" .
>>>  (2)
>>>  person:Jenny ex:age _:x .
>>>  _:x rdfs:dlex "10" .
>> 
>> Yes.
>> 
>>>  As things are at present, (1) means that Jenny's age is a character
>>>  string, no matter what else you say, whereas (2) says her age is
>>>  something that can be described by a character string, so can be
>>>  modified by other datatyping. We can change this, as I say, but only
>>>  at a cost.
>> 
>> It depends on how much of the datatyping interpretation is
>> intended to be captured in the graph.
>> 
>> If we agree that a literal denotes a literal always, and at
>> some level above the graph, we may determine based on the
>> combination of a literal and a datatype that the literal is
>> string equal with a lexical form that denotes a value, great.
>> 
>> But we don't then have to say that the literal node *denotes*
>> the value. It still denotes the literal.
>> 
>> Datatyping interpretation can happen above the graph. The
>> knowledgeg necessary to make those interpretations consistently
>> and unambiguously is captured in the graph. And in the graph,
>> a literal always denotes a literal.
>> 
>> Where is the problem?
> 
> The problem for me is that none of this makes the any sense at all. I
> have no idea what you are talking about.

It wouldn't be the first time ;-) and it's surely my inablity to
explain it clearly enough in some language we both understand...

> 1. If a literal always denotes itself, then datatyping information in
> the graph (in particular, about ranges expressed using rdfs:drange
> for example) cannot influence the meaning or truthvalues of any
> 'in-line' use. That is how my first 'simplified' proposal worked, but
> I gather you did not like that.
> (To emphasize: if "15" denotes "15", then
> 
> Jenny ex:age "15" .
> 
> says that Jenny's ex:age is "15". It does not, cannot, and never will
> say that Jenny's ex:age is 15, no matter what you do above, inside or
> underneath the graph. End of story; nothing more to be said; nothing
> can change it (short of re-writing the entire RDF MT from the ground
> up.). )

Then we're agreed. Insofar as the RDF MT is concerned, it cannot
mean 15. That is exactly how it should be -- since it can never
mean 15 in the graph because the knowledge needed to make that
value determination is extra-RDF knowledge, such as the actual
definition of the mappings of xsd:integer, which are *not*
expressed in the graph nor have explicit RDF MT interpretation.


> 2. I do not know what you mean by a 'level above' the graph, and in
> any case that is irrelevant, whatever it means, since we are here
> talking about the graph.

We're talking about the graph, yes, and what the MT interpretation
of the graph is, yes, and I'm saying that insofar as the MT
interpretation is concerned, a literal always denotes itself.

The functional significance of some literal above/outside of
the MT, serving as a lexical form of some datatype, and
having a mapping to a specific value of that datatype, is
defined *outside* of the RDF MT. And that is as it should be,
since we are not defining our datatypes in RDF, we are only
associating datatypes with lexical representations of datatype
values, and needing a clear, consistent interpretation of
that *PAIRING* and nothing more. Nada. Zip. Just the pairing
of liteal and datatype. Everything else depends on extra-RDF
treatment by applications with complete knowledge about the
specific datatype.

This has been the core/hear/soul of the TDL concept from
day one.

All RDF captures is the pairing. Period. And the pairing is
consistent and explicit for applications that know what to
do with it, in order to get some actual value.

Why do folks keep trying to make this so darn'd difficult
by trying to capture the totality of datatypes in the RDF
MT? All we need (all we've ever needed) to capure is the
pairing of literals to datatypes and give applications
clear and consistent instructions on how to recognize
those pairings and which piece of the pairing is the
lexical form and which piece is the datatype.

> 3. I do not know what you mean by the distinction between a string
> and a lexical form. Seems to me that lexical forms *are* strings.
> (They sure look like strings on the page.)

A literal is an RDF literal. It is a syntactic element of the graph.

A lexical form is a member of the lexical space of a datatype. It
is, if you will, a literal with a purpose, a literal with a consistent
interpretation within the context of that datatype.

The fact that both a literal and a lexical form may be represented
as strings does not mean they are the same 'thing'.

> 4. What kind of interpretation happens 'above' the graph? And how can
> it make any difference  to  what the graph means?

C.f. 
  
http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Feb/0595.html

noting the correction in

http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Feb/0598.html

Everything under "Interpretation:" corresponds to non-MT, extra-RDF
application interpretation "above the graph", but based on explicit
rules or guidelines set forth for the consistent use of datatypes
in RDF by whatever documentation we produce.

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 Friday, 22 February 2002 03:35:31 UTC