W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > April 2002

Re: Denotation of datatype values

From: Pat Hayes <phayes@ai.uwf.edu>
Date: Thu, 18 Apr 2002 16:29:34 -0500
Message-Id: <p0510152fb8e4e8acf6ab@[]>
To: Patrick Stickler <patrick.stickler@nokia.com>
Cc: w3c-rdfcore-wg@w3.org
>On 2002-04-18 19:20, "ext Brian McBride" <bwm@hplb.hpl.hp.com> wrote:
>>  At 20:16 16/04/2002 +0300, Patrick Stickler wrote:
>>>  On 2002-04-16 20:03, "ext Brian McBride" <bwm@hplb.hpl.hp.com> wrote:
>>>>  At 16:33 15/04/2002 -0400, Pat Hayes wrote:
>>>>  [...]
>>>>>  I don't want to be a party-pooper, but I honestly feel that having an MT
>>>>>  and sticking to it is one way to get past this kind of half-formalized
>>>>>  (and rather confusing) kind of discussion. I do not know what these
>>>>>  'levels' are supposed to be, or how to recognize them, or how to evaluate
>>>>>  talk about them, etc. etc. . Why not stick to the syntax and the MT, and
>>>>>  just talk about that? Then everything is clear. What an application wants
>>>>>  to do with an RDF graph is up to it, not up to us. All we can do is to
>>>>>  provide application writers with a gold standard for meanings, and leave
>>>>>  other 'layers' to them.
>>>>  I agree.
>>>  That's a pity, because there are lots of users of RDF who can't
>>>  read or understand the MT. So...
>>>  There are many different kinds of "customers" who will read the
>>>  RDF Datatyping specification, and we need to be sure that it is
>>>  clear and approachable -- and ultimately *usable* -- to them all.
>>  Yes, I think I am persuaded of that.  The trick might be to have a clear
>>  distinction between the formal specs and more tutorial oriented text.
>I'm not yet convinced that we need a completely separate tutorial.

I agree.

>I see two primary issues with the present WD:
>1. The use of the "datatyped literal" terminology. I am quite happy
>to remove that and try to capture the significance of the association
>of the literal with a datatype in some other way.
>2. Whether the inline idiom, the combination of literal and globally
>asserted datatype, identify/express/communicate/whatever a datatype
>value. I say it does. Pat seems to say it doesn't. I consider the
>MT to say it does. Pat seems to say the MT doesn't say that.

Well, the MT certainly doesn't say that; it is careful not to. It 
refers only to a lexical form being in a the domain of the mapping, 
not to the value of the mapping.

>If it is the consensus of the WG that the datatyping MT does *not*
>say that, then I strongly assert that it should.
>The debate seems to border at the RDF/extra-RDF boundary, as to
>what is or is not denoted explicitly in the graph or what RDF
>can or cannot say about a given lexical form.

That might well be true.

>I get the impression that Pat and I are simply viewing the issue
>from different perspectives. I'm focusing on what we need RDF
>Datatyping to accomplish, and trying to fit those needs/expectations
>into the present definition,

And my concern is that by doing this, Patrick is imposing one 
particular viewpoint of how RDF is to be used. My concern when 
designing the datatyping model was to allow for a number of different 
such viewpoints to all coexist. There were more than I had bargained 
for, and its not easy to satisfy them all. The needs of a 
database-modelling user community and those of a text-markup user 
community are quite different. We should not pre-judge what our users 
want to do, particularly when that would violate the norms of 
existing user communities like Dublin Core. There are several 
different big pictures here.

>  and the application of the present
>definition to the "big picture", including considerations that
>lie beyond the graph. Pat seems to be focusing on the
>minimum of what the MT says, and strictly at what is explicit
>in the graph.

Right, and I think moreover that we are mandated and required to do 
exactly that. That is our job, to make the RDF graph as unambiguous 
and useful as possible, and to state *exactly* what is the 
information content of the graph, no more and no less.  I think it 
would be a serious mistake to do anything else.


IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
Received on Thursday, 18 April 2002 17:29:48 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:53:57 UTC