Re: Denotation of datatype values

On 2002-04-12 13:33, "ext Graham Klyne" <Graham.Klyne@MIMEsweeper.com>
wrote:

> Er, do we have a disconnect here?
> 
> Pat, if you're following this:  I note your document that was at
> <http://www.coginst.uwf.edu/users/phayes/simpledatatype23-02-2002.html> is
> no longer there.  Has it been moved?  It would be good if it were kept
> available for a while, since that seems to be our last published point of
> consensus.
> 
> Anyway, to resume normal programming...
> 
> At 09:53 AM 4/12/02 +0300, Patrick Stickler wrote:
>> On 2002-04-11 18:53, "ext Graham Klyne" <Graham.Klyne@MIMEsweeper.com>
>> wrote:
>> 
>>> At 12:22 PM 4/11/02 +0200, Jeremy Carroll wrote:
>>>> Now we add the range constraint on <age>
>>>> 
>>>> <Jane> <age> "25" .
>>>> <film> <title> "25" .
>>>> <title> <range> <xsd:string> .
>>>> <age> <range> <xsd:integer> .
>>>> 
>>>> We now have the film's title delivered as <xsd:string,"25"> the
>> woman's age
>>>> delivered as <xsd:integer,"25"> and they are different.
>>>> Hence we see defeasible reasoning: in the light of new information we
>> revise
>>>> our knowledge that Jane's age is <xsd:string,"25">, which in turn
>> causes us
>>>> to revise our conclusion that Jane's age and the film's title are the
>> same.
>>> 
>>> My understanding of PatH's last proposal is that this graph is not
>>> satisfiable.  More precisely:
>>> 
>>> [[[
>>> <Jane> <age> "25" .
>>> <age> <range> <xsd:integer> .
>>> ]]]
>>> 
>>> is not satisfiable because "25" denotes a string and <xsd:integer> does not
>>> contain strings in its class extension.
>> 
>> This is true if <range> equates to rdfs:range. I presumed it
>> equated to rdfd:range, in which case, there is no problem.
>> 
>> It really will help, Jeremy, if you use the precise vocabulary
>> that we have come up with, especially if commenting on the current
>> WD, otherwise, we have no basis for mutual understanding. I know
>> that to some extent, you are trying not to beg the question by
>> keeping some terms somewhat ambiguous, but it makes it too hard
>> to know exactly what you mean. If you mean rdfs:range, please say so.
>> If you mean rdfd:range, again, just say so. etc. OK?
> 
> Ummm... if you mean to interpret <range> as <rdfd:range>, then according to
> something Pat said a while ago [1], that has _no effect at all_ on the
> denotation of anything.  That simply describes a syntactic constraint on
> literal labels in the RDF graph (which are satisfied by the above examples
> so can be dropped without having any any further effect on the semantics).
> 
> #g
> --
> 
> [1] http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Mar/0241.html :
> 
> [[
> Right. The point is that rdfs:drange (or whatever we call it) really
> says nothing about the actual range: it ONLY invokes datatype
> checking. Now, one might reasonably expect that the actual range was
> 'in line' with the datatype checking, but that could be
> ]]


But this is precisely what I was trying to say. That rdfd:range
says nothing about the rdfs:range of the property -- BUT it does
provide a datatype context for the interpretation of both the blank
node (if present) and the literal node which (if valid) identifies a
specific datatype value, and which fixes the denotation of the bnode
(if present) to that value.

It may be clearer to say that it is the datatype context that asserts
the constraints on the lexical forms and which values the blank nodes
denote, and all rdfd:range defines is that context. To that end,
perhaps the earlier suggested name rdfd:datatype would be better,
since these same constraints and interpretation are asserted by the
datatype property as well, or rather, those constraints and
interpretation are only asserted by the datatype, and the only real
function of rdfd:range is associate the datatype with the property
to provide datatype context for the property values. (?)

Insofar as what the bnode denotes, we could view the three levels of
interpretation as degrees of datatyping precision:

Level 1: MT (no datatyping)

The bnode dennotes a non-literal resource
(we don't even know that it should be a datatype value).

Level 2: Datatyping

The bnode denotes a single specific value identified by a datatyped
literal pairing (but we don't know which value it actually is, we
only know that there's only one that can be identified by the
datatyped literal pairing we have).

Level 3: Extra-RDF/Datatype aware

The bnode denotes a single specific and known datatype value.




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, 12 April 2002 07:05:19 UTC