Re: Denotation of datatype values

On 2002-04-19 0:29, "ext Pat Hayes" <phayes@ai.uwf.edu> wrote:


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

And here is where we dance around with words. For the MT to identify
a specific datatype value is not to assign that value to any node
in the graph. It may also do that, as in the case of the lexical form
and datatype property idioms. But in the case of the inline idiom,
it does not. Yet it still provides an unambiguous interpretation of
all of the idioms which identifies a specific datatype value, and
that is the utility of RDF Datatyping for users and applications.

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

Firstly, I don't agree with your summary of what the text-markup
users need (being one of them myself). To constrain strings to
the lexical space of a datatype is to assert that their proper
interpretation is in terms of that datatype (or they are insane).

Secondly, Dublin Core would only ever use the datatype triple idiom,
or not do datatyping at all. Because DC does not impose any particular
datatype interpretation on its values. Users may only express how
*they* are intending their values to be interpreted, by use of
the local datatype property idiom, but to assert a datatype association
with a DC property is to say something about DC that is not specified
by the DC standard.

Granted, a given system could do so, to indicate those datatypes it
can handle, using errors to filter out unsupported content, but
that's a special case.

The rdfd:datatype assertion is intended for Ontologies where the
datatypes for the properties are part of the formal specification,
and thus, are imposed on all usage of the ontology, even if users
specify local datatyping.

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

That is *one* of our jobs, or one possible (narrow) interpretation
of what our job is. I disagree insofar as how that should be
accomplished and at what scopes of precision. That's not to say that
a solid MT is not *part* of our job, but it is not *all* of our job.

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, 19 April 2002 03:42:57 UTC